config stuff

[Bernd Gehrmann]

On Tue, 12 Sep 2000, Falk Brettschneider wrote:
> 
> As you said, readConfig is based on a hierarchy of object names. I'm not
> sure what happens when one component is replaced/removed/added from
> kdevelop. Somehow there will branches in the object tree which won't fit
> on readConfig(). Likey the default docking will help here... Could
> work... yeah.

Branches in the object tree? Don't know what you mean here.
Regarding removed/added components, the KDockMainWindow
API isn't designed for this AFAICT. You would have to
get a list of all windows that were not 'used' by the
readConfig() call and then do some default action on
them.

> > It becomes more difficult if a components wants to
> > store session data itself. I'm too tired to think
> > about it now ;-)
> 
> Concerning to the dockwidgets, I think the main application must
> writeConfig() the full object tree. I mean not a local writeConfig() for
> each component.
> For other stuff it could be useful, if each component or its family has
> its own section.

Now I remember what was really ugly: KConfig is too primitive
for a component-based application. If you give each components
its own group, then all the component can store is key/value
pairs - KConfig doesn't have nested groups. A workaround is
to use multiple groups (the doc tree view is an example), but
then the whole structure gets lost and the file becomes a
glorious mess (btw the stuff stored by KDockMainWindow::writeConfig()
is already an obvious example of such a mess)

Can't we use XML+QDom for project files? :-)
Then one could replace the setupGUI() to components with the pair

void saveConfig(QDomElement element)
void restoreConfig(QDomElement element)

When a component is added to the project (either by the
app wizard or by the user through a configuration dialog),
one could call restoreConfig() with a null element which
tells the component to create a default gui setup.

Bernd.