diff options
author | Timothy Pearson <[email protected]> | 2011-11-06 15:56:40 -0600 |
---|---|---|
committer | Timothy Pearson <[email protected]> | 2011-11-06 15:56:40 -0600 |
commit | e16866e072f94410321d70daedbcb855ea878cac (patch) | |
tree | ee3f52eabde7da1a0e6ca845fb9c2813cf1558cf /tdeui/TODO.xmlgui | |
parent | a58c20c1a7593631a1b50213c805507ebc16adaf (diff) | |
download | tdelibs-e16866e072f94410321d70daedbcb855ea878cac.tar.gz tdelibs-e16866e072f94410321d70daedbcb855ea878cac.zip |
Actually move the kde files that were renamed in the last commit
Diffstat (limited to 'tdeui/TODO.xmlgui')
-rw-r--r-- | tdeui/TODO.xmlgui | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/tdeui/TODO.xmlgui b/tdeui/TODO.xmlgui new file mode 100644 index 000000000..3c3d4f8a4 --- /dev/null +++ b/tdeui/TODO.xmlgui @@ -0,0 +1,91 @@ +Bug with toolbars: a->saveState(); delete a; b->saveState(); delete b; +will store wrong positions (index, offset and newline). +When removing an xmlgui-client involves destroying toolbars, we need to save the +whole set of toolbar positions of the mainwindow, into the xmlgui-client. + +Data structure: +struct KToolBarPos { + short int index; + short int offset; + bool newLine; +}; +typedef QValueVector<KToolBarPos> KToolBarPosList; + +API: +KToolBarPosList KMainWindow::toolBarPositionList() const; + +The remaining problem is to know when to call it: +* when we know in advance that we'll be able to remove toolbars? + (when creating the client we could remember if we created a toolbar and store + that bit of information, to re-use it when removing the client again) +* when removing the first toolbar (of a given client); then we need +to differentiate between first and following toolbars +* always, if fast enough? With tons of plugins that might not be a good idea. + +========== More long term + +Problems: +* No ui_standards.rc merging for parts +* Confusing tag names (MergeLocal vs DefineGroup) for similar features +* Two different merging codes (DOM-tree merging for ui_standards, xmlguifactory merging +between xmlguiclients). + +Solution: +* Get rid of the custom DOM-tree merging code from kxmlguiclient (for ui_standards.rc), +use the existing merging code from kxmlguifactory instead +* MergeLocal and DefineGroup are renamed MergeGroup, and append= becomes equivalent to group=. +* Action is renamed MergeAction, and uses a new kind of place holder +(one that matches actions by name during merging) +So ui_standards.rc needs to be turned into <MergeAction>s and <MergeGroup>s only. +* This also means that it will be possible to have only merge tags (and custom items +like separators and tearoffhandle etc.) in a container, in which case it should +not appear in the GUI. For that, ContainerNode must be improved so that it supports +having no real GUI container attached to it. +Big problem here. This means not building a container until we find that it +really has an action (and the other way round: deleting a container when +removing its last action, as we do, but still keeping a ContainerNode around...) +(A ContainerNode is destroyed when its owner guiclient is removed from the factory, +no change here). + +* A new XMLGUIClient provides the ui_standards.rc XML. It has the same instance +as the mainwindow's guiclient. It provides no actions. No problems, since it +only has <Merge*> tags. + +But that new xmlguiclient will 'own' the containers, so KEditToolbar will +give wrong information. + +=====> +This means the following KEditToolbar improvement is necessary: +(it's an almost unrelated and necessary change there anyway, usability-wise) + +It would use merging, to present a merged view of the toolbars +When the user inserts an action to a toolbar, we know which client the action +belongs to, so we know which XML file to modify. +BUT if the user adds actions in non-contiguous positions, we need to +create <DefineGroup name="client1_tmp1"> groups, so that the merging actually does +what the user asked for (!!) + +This allows to get rid of the "toolbar <client>" combobox stuff, and just have +a list of toolbars there. + +Implementation: it can do this by providing its own KXMLGUIBuilder, to a +new factory. The guiclients would be wrapped in a KXMLGUIClientProxy, +which would forward the action() and domElement() calls - because a client +can be in only one factory at a time. + +This custom builder needs to know about action plugging too, we don't really want +to call KAction::plug here. So this would be 'virtualized' (new virtual, in a new +interface to keep BC, that by default calls plug, but does something else in +kedittoolbar's builder). + + +====== + +Additional benefits: +* Any XML file can use the new <MergeAction> feature to modify the way a +child client (e.g. a part) is getting merged, without adding group attributes +to the child client (useful for a binary-only one, e.g.) + +-- +David Faure <[email protected]> +Simon Hausmann <[email protected]> |