run-time KConfigDialog/KConfigSkeleton

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed February 11 2004 13:28, you wrote:
> I've got a couple of KConfigDialog / KConfigSkeleton questions. At first
> glance these classes appeared to be exactly what I need, but I'm running
> into problems now that I'm examining them more closely.
>
> 1) I don't know what items are available until run-time, while it seems to
> be a requirement for these classes to know them at compile time.

Only if you want to use the kconfig_compiler to populate KConfigSkeleton. You
can create a KConfigSkeleton dynamically during runtime, just look at the
code that kconfig_compiler generates for inspiration.

Likewise you can populate the widget(s) that are managed by KConfigDialog
dynamically during runtime instead of via a .ui file.

See for example kdegames/libksirtet/common/ai.cpp for dynamically generated
widgets.

> 2) Is it possible (haven't examined it closely yet due to the first issue)
> to make sure no file interaction takes place? These aren't options that
> should be stored really, they are just configurable settings for the
> selected game and will often be agreed upon between the players that happen
> to be in that specific game.

No, not really. KConfigSkeleton pretty much wants to write its settings to
KConfig. What you might be able to do is to create a KConfig derived class
that doesn't operate on a file. SlaveBaseConfig does something like that in
kdelibs/kio/kio/slavebase.cpp Or maybe you can use KConfig with an empty
filename, make sure to call setReadOnly(false) in that case, not sure if that
is going to work.

Cheers,
Waldo
- --
bastian at kde.org -=|[ SUSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQFAKioON4pvrENfboIRAoVYAJYiIvMhk4MtsWGckebvMfRbeLkKAKCav+Nn
CxDqmC8OoG9euXisSAamBg==
=biSQ
-----END PGP SIGNATURE-----