KAutoConfig

[Simon Hausmann]

On Sat, Feb 22, 2003 at 11:24:07PM -0500, Benjamin Meyer wrote:
[...]

Here are some more comments:

I believe the current way of adding support for new widget
configurations is unnecessarily complex, and having global
preprocessor macros in our public API that are called 'saveConfig',
'resetConfig' or 'retrieveConfig' is a terrible idea I think.

I think there's a much simpler solution to the whole problem.
Basically the whole reason for the KAutoConfigWidget class and the
ugly macros is to get access to properties using direct setFoo() and
foo() calls. But this is duplicated work. The Trolls and our friend
the moc :) have done all the work for us already, since Qt 2.2: Qt
properties.

Another huge advantage of using Qt properties instead of separate
set/get objects that are special to the widge type is that with
properties you wouldn't need a KURLRequesterAutoConfigWidget class,
with the mentioned dependency problem (where to put it?) .

And the Trolls have done more: The code in the QSqlForm that
utilizes the QSqlPropertyMap class does more or less exactly what
KAutoConfig does, except that the information is stored/retrieved
from a SQL database. (take a look at QSqlForm::readFields and
writeFields, and of course at QSqlPropertyMap :)

So all in all I believe it would be much better if KAutoConfig
would simply make use of QSqlPropertyMap to read/write the
configured properties to the given KConfig object. Making use of the
default sql property map has the advantage that you get the ability
to save/restore the configuration of all the kdeui widget for free,
because David in the past has added code to kapplication to
automatically add entries in the default sql property map for all
those classes like KURLRequester, KSqueezedTextLabel, KDatePicker,
etc.

That would make KAutoConfig a really lightweight class, because all
the mapping logic is already in Qt and the code for reading/writing
the setting exists in the moc generated code as well as in KConfig
already (readPropertyEntry and QVariant writeEntry overload) . So
KAutoConfig would only have to iterate over the widgets that need
persistence in their settings, use the default sql property map to
figure out which property to request for the given widget (by
classname) and call readPropertyEntry/writeEntry.

Simon