Actually move the kde files that were renamed in the last commit

1 files changed, 0 insertions, 91 deletions

diff --git a/kdeui/TODO.xmlgui b/kdeui/TODO.xmlgui
deleted file mode 100644
index 3c3d4f8a4..000000000
--- a/kdeui/TODO.xmlgui
+++ /dev/null
@@ -1,91 +0,0 @@
-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 <faure@kde.org>
-Simon Hausmann <hausmann@kde.org>