state saving and restoring for GUI elements

[Johannes Wienke-3]

Hi,

for the model view port branch most of the old functionality for saving
and restoring is currently not re-implement or called and that's one of
the tasks that I want to do next. For this purpose I stumbled across
several different approaches how to save and restore the GUI states.
Some classes do this in constructors and destructors, others have
separate methods that need to be called externally. Sometimes these
methods require a KConfig or KConfigGroup object and / or a prefix to
prepend at the entry names, sometimes the object name is used, and so on...

I think this should be unified in some way but I'm not quiet sure how to
do this the best way. Here are some thoughts I had about the problem.

1. We should always consider that one class can be used several times in
the application. So always writing to the same config entries will
result in some kind of race condition on which saving / restoring
results will be used.

2. Always using the same config group for one class may not be desirable
for the same reason as above. If I use a tree view for the left sidebar
I want its state to be stored in the config group for the sidebar. If I
use the same class in the settings for the advanced search, I want the
state to be stored in a config group for these settings. So passing in
the config group to use sounds reasonable.

3. Should state be always stored or only sometimes? In the first case
using constructors / destructors sounds reasonable, else special methods
should be used.

4. I think it would be a good idea to have a special interface (abstract
base class) for all GUI clases, that provide mechanisms to save or
restore state. Automatically using the constructor or destructor of this
base class for saving / restoring will not work because of the
restriction not to call virtual functions in these methods...

So, any more thoughts on how to do this the best way?

Johannes


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

>
> So, any more thoughts on how to do this the best way?

I have the feeling that it's good to give KConfigGroups and do it outside of
the constructor/destructor, though the latter will create a bit of extra work.

A common base class can be difficult because there may be widgets not
inheriting from QWidget but a specialized subclass, and then you can't use
this code. Not sure about this. Is there really so much code to share for
generic QWidgets? Maybe it's easier to collect utility code in common place
for reuse. You will see that better when starting to work on it.

>
> Johannes
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Johannes Wienke-3]

Am 11.12.2009 17:40 schrieb Marcel Wiesweg:
>> So, any more thoughts on how to do this the best way?
>
> I have the feeling that it's good to give KConfigGroups and do it outside of
> the constructor/destructor, though the latter will create a bit of extra work.

Ok.

> A common base class can be difficult because there may be widgets not
> inheriting from QWidget but a specialized subclass, and then you can't use
> this code. Not sure about this. Is there really so much code to share for
> generic QWidgets? Maybe it's easier to collect utility code in common place
> for reuse. You will see that better when starting to work on it.

My idea was mainly about having a unique interface for all classes that
allow state saving. We could use a base class as mixin via multiple
inheritance:

class MySavingGuiObject: public QWidget, public StateSavingObject
{...}

class StateSavingObject
{
public:
     StateSavingObject();
     StateSavingObject(KConfigGroup &configGroup);
     virtual void restoreState() = 0;
     virtual void saveState() = 0;
     void setConfigGroup(KConfigGroup &newGroup);
protected:
     virtual KConfigGroup getConfigGroup() const;
}

Something like this. StateSavingObject could then also handle some
default group handling code if necessary, eg. using a config group
determined by the object name or what ever...

Johannes


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Yes, something like that sound fine.

Take a care to check if all component to store/restore state have a
QObject name defined, else on entry in config file will replace
another one.

A QObject naming convention need to be used everywhere. Write is to
HACKING file later, or in another TEXT file as developer
documentation.

Gilles

2009/12/11 Johannes Wienke <[hidden email]>:

> Am 11.12.2009 17:40 schrieb Marcel Wiesweg:
>>>
>>> So, any more thoughts on how to do this the best way?
>>
>> I have the feeling that it's good to give KConfigGroups and do it outside
>> of the constructor/destructor, though the latter will create a bit of extra
>> work.
>
> Ok.
>
>> A common base class can be difficult because there may be widgets not
>> inheriting from QWidget but a specialized subclass, and then you can't use
>> this code. Not sure about this. Is there really so much code to share for
>> generic QWidgets? Maybe it's easier to collect utility code in common place
>> for reuse. You will see that better when starting to work on it.
>
> My idea was mainly about having a unique interface for all classes that
> allow state saving. We could use a base class as mixin via multiple
> inheritance:
>
> class MySavingGuiObject: public QWidget, public StateSavingObject
> {...}
>
> class StateSavingObject
> {
> public:
>    StateSavingObject();
>    StateSavingObject(KConfigGroup &configGroup);
>    virtual void restoreState() = 0;
>    virtual void saveState() = 0;
>    void setConfigGroup(KConfigGroup &newGroup);
> protected:
>    virtual KConfigGroup getConfigGroup() const;
> }
>
> Something like this. StateSavingObject could then also handle some default
> group handling code if necessary, eg. using a config group determined by the
> object name or what ever...
>
> Johannes
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel