[Digikam-devel] state saving and restoring for GUI elements

[Gilles Caulier]

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 <languitar at semipol.de>:
> 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
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>