RFC: KConfig XT (KDE 3.2)
bastian at kde.org
Sun Mar 16 16:29:20 GMT 2003
On Sunday 16 March 2003 14:19, Benjamin Meyer wrote:
> After looking at KPrefs I like what it does, but don't think it is needed
> because of what KAutoConfig does and how it integrates into an application.
> As I have been converting applications I have found that in general in a
> window/widget you will have a readSettings() function which will directly
> call readConfig() for the 10 or so settings that are read for that widget.
> That is all that the programmer has to do. The setting of defaults,
> reading, writing, immutability, is automaticly handled by KAutoConfig.
> Thus creating a kpref's class would be kind of silly sense it would only
> used once.
But KAutoConfig only handles the configuration dialog side of things. It
doesn't provide the application itself with anything, does it? I think it is
certainly usefull but I don't think it is sufficient.
> I could add a function to KAutoConfig which will force the output of all of
> the default settings to a file. This function could be called via dcop or
> something and so if for example a kiosk admin wanted to make a special
> settings file he/she could use dcop to spit out all of the default settings
> for examination. The admin could then modify the default config on the
> system (non user writable located in /etc/kde?) and insert any special
> default settings they want. This way developers don't have to maintain a
> default settings file, power users get more fun, and the config files still
> don't grow in size (but shrink as I clean up core libs!), kconfig doesn't
> have to parse extra files, every app that uses kautoconfig would
> automaticly get this feature, kiosk admins get the new functionality
> without any sacrifices by the general user base... hmm this is sounding
> like a really good idea.
It might work but I don't think it's the best approach. Extracting data at
runtime is a hack, the information is there at compile time, one should be
able to access it at that point already. The biggest conceptual flaw though,
is IMHO that the settings are defined as part of the configuration dialog.
That's backwards, the configuration dialog certainly reflects (parts of) the
settings but the settings can exist independent from the configuration
dialog. This becomes very clear in applications who use out-of-process
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
More information about the kde-core-devel