config stuff

[Falk Brettschneider]

Hallo,

Bernd Gehrmann wrote:

> On Mon, 11 Sep 2000, Falk Brettschneider wrote:
>
> > Hi,
> >
> > Are there any ideas how to design loading/saving the
> > configuration/session in a distributed app like KDevelop?
>
> *brainstorming*
>
> Would be easier if KDockWidget::readConfig() had useful
> documentation ...
> /me looks for the documentation maintainer ;-)

I should copy'n'paste your sencentes from below. A good summary
somehow... ;-)

>
>
> It seems that in order restore a window configuration
> from a config file, it looks up widgets by name
> (QObject::name) in the childDock variable of
> KDockManager. This list in turn contains all
> KDockWidgets (according to the KDockWidget constructor).
> So in principle, in order to restore a window layout,
> one must first construct all widgets, put each of them in a
> KDockWidget and then call readConfig(). And for all this
> to work, each widget must have a unique name.

Yes. That is what the old ckdevelop.cpp does. It creates a default
object tree of dockwidgets and after that it tries to readConfig and
reparents the default dockwidget-object tree to the read configuration.
The same happened for the switch between debugger-dockwidget-scenary and
editor-dockwidget-scenary. Unfortunately, that reparenting leads to ugly
show-hide-resize effects.
Well, it's now snow of yesterday...

>
>
> The difficult part comes comes from out component
> architecture. Up to now, all existent components (by
> a call to the trader) are constructed on startup. This
> sucks (I'm guilty...). We want to have configurability
> on a per-project level, right? Then we want to store
> the list of components in the project file (more precisely
> in the user project file, which now seems to be separate).
> An initial list of components for a project is generated
> by some app wizard.

Mostly we need at least one of each component family:
- one of the view handlers
- one of the editor components
- one or none of the debuggers
- one or many of the project managers

Startup must test, if a minimum configuration is fulfilled and if they
are compatible.

> Afterwards, the user may add or
> remove components.
>
> Now what do we need to restore a session?
>
> 1. obtain a list of all components to laod from
>    the project management
> 2. load the components
> 3. ask the components to initialize their gui
>    (now a number of embedWidget() calls comes in,
>    where a KDockWidget is created for each of them)
> 4. readConfig()

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.

>
>
> 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.

>
>
> Just my thoughts. If this was completely stupid or
> I missed anything, say so.
>
> Bernd.

Bye,
  F at lk



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com