Warning, /frameworks/kxmlgui/TODO.xmlgui is written in an unsupported language. File is not indexed.

0001 Bug with toolbars: a->saveState(); delete a; b->saveState(); delete b;
0002 will store wrong positions (index, offset and newline).
0003 When removing an xmlgui-client involves destroying toolbars, we need to save the
0004 whole set of toolbar positions of the mainwindow, into the xmlgui-client.
0006 Data structure:
0007 struct KToolBarPos {
0008    short int index;
0009    short int offset;
0010    bool newLine;
0011 };
0012 typedef QValueVector<KToolBarPos> KToolBarPosList;
0014 API:
0015 KToolBarPosList KMainWindow::toolBarPositionList() const;
0017 The remaining problem is to know when to call it:
0018 * when we know in advance that we'll be able to remove toolbars?
0019   (when creating the client we could remember if we created a toolbar and store
0020    that bit of information, to re-use it when removing the client again)
0021 * when removing the first toolbar (of a given client); then we need
0022 to differentiate between first and following toolbars
0023 * always, if fast enough? With tons of plugins that might not be a good idea.
0025 ========== More long term
0027 Problems:
0028 * No ui_standards.rc merging for parts
0029 * Confusing tag names (MergeLocal vs DefineGroup) for similar features
0030 * Two different merging codes (DOM-tree merging for ui_standards, xmlguifactory merging
0031 between xmlguiclients).
0033 Solution:
0034 * Get rid of the custom DOM-tree merging code from kxmlguiclient (for ui_standards.rc),
0035 use the existing merging code from kxmlguifactory instead
0036 * MergeLocal and DefineGroup are renamed MergeGroup, and append= becomes equivalent to group=.
0037 * Action is renamed MergeAction, and uses a new kind of place holder
0038 (one that matches actions by name during merging)
0039 So ui_standards.rc needs to be turned into <MergeAction>s and <MergeGroup>s only.
0040 * This also means that it will be possible to have only merge tags (and custom items
0041 like separators and tearoffhandle etc.) in a container, in which case it should
0042 not appear in the GUI. For that, ContainerNode must be improved so that it supports
0043 having no real GUI container attached to it.
0044 Big problem here. This means not building a container until we find that it
0045 really has an action (and the other way round: deleting a container when
0046 removing its last action, as we do, but still keeping a ContainerNode around...)
0047 (A ContainerNode is destroyed when its owner guiclient is removed from the factory,
0048 no change here).
0050 * A new XMLGUIClient provides the ui_standards.rc XML. It has the same instance
0051 as the mainwindow's guiclient. It provides no actions. No problems, since it
0052 only has <Merge*> tags.
0054 But that new xmlguiclient will 'own' the containers, so KEditToolbar will
0055 give wrong information.
0057 =====>
0058 This means the following KEditToolbar improvement is necessary:
0059 (it's an almost unrelated and necessary change there anyway, usability-wise)
0061 It would use merging, to present a merged view of the toolbars
0062 When the user inserts an action to a toolbar, we know which client the action
0063 belongs to, so we know which XML file to modify.
0064 BUT if the user adds actions in non-contiguous positions, we need to
0065 create <DefineGroup name="client1_tmp1"> groups, so that the merging actually does
0066 what the user asked for (!!)
0068 This allows to get rid of the "toolbar <client>" combobox stuff, and just have
0069 a list of toolbars there.
0071 Implementation: it can do this by providing its own KXMLGUIBuilder, to a
0072 new factory. The guiclients would be wrapped in a KXMLGUIClientProxy,
0073 which would forward the action() and domElement() calls - because a client
0074 can be in only one factory at a time.
0076 This custom builder needs to know about action plugging too, we don't really want
0077 to call KAction::plug here. So this would be 'virtualized' (new virtual, in a new
0078 interface to keep BC, that by default calls plug, but does something else in
0079 kedittoolbar's builder).
0082 ======
0084 Additional benefits:
0085 * Any XML file can use the new <MergeAction> feature to modify the way a
0086 child client (e.g. a part) is getting merged, without adding group attributes
0087 to the child client (useful for a binary-only one, e.g.)
0089 --
0090 David Faure <faure@kde.org>
0091 Simon Hausmann <hausmann@kde.org>