Latest revision as of 21:35, 12 February 2012

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.

KConfig x New config as a library support

Replace KConfig with a Qt-only-based config library, with native backends for target operating systems. This new library will even be suitable for Qt-only apps. It will be the equivalent of Solid or Phonon for configuration.

Desired characteristics:

Remove all global config usage (as <KDEDIR>/share/config in Linux). All configs are user based and Kiosk is of course respected, so no user or distro will be affected. (Not sure what this means - is it simply saying that there will no longer be any configuration files installed by vanilla KDE? cf. next bullet point - rg3).

kcfg and defaults would not be deployed anymore as separate files. Defaults should be included in binaries, through headers for example, and are generated on the fly on first run from user. Distros can still have their tree with configs. There should possibly be a tool to generate a description of what configuration files/options are available, for the use of distros and system admins. (Does this mean that the configuration system will still look in /etc/whatever, for example, so distros/sysadmins can change the global defaults? - rg3)

The new library would be written from scratch, and a KConfig compatibility layer would be provided to retain source compatibility. In future, apps should directly use the new library. The KConfig wrapper will be a transitory stage.

Helio wants to try to implement it.

Current pointed implementation issues open questions

Multiple instances of same app and concurrent write/read

We want notifications of changes. Is this available on all platforms?
- dconf has change notification support.
- The Windows registry also does, via RegNotifyChangeKeyValue, for example.
- Mac OS X's NSUserDefaults class also has a notification method, but it is quite coarse (it just tells you that the application's settings have changed) and is also Objective C. The C API does not appear to have notification support.

Migration from kde4 configs. A tool could be written to do this. This is feasible - it only requires writing a parser, but will take some time to write. Using kconfig itself will create an undesirable dependency.

Configuration systems

DConf

DConf as a backend for KConfig would offer some nice features.

Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.

Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.

There are notifications for changes of settings.

It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings. The concept of locking is very similar to Kiosk immutable settings. In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.

There is an existing Qt library: https://gitorious.org/dconf-qt/dconf-qt

Problems could be: There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.

We can't use change notifications as that would assume use of dconf as a backend which makes an application unportable to windows/mac (currently).

DConf stores its config in xdg dirs (.config).

Current state to compile

Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8

Windows Native

Registry? It has change notification support. Probably doesn't have all the types we would want - some encoding may need to be done.

Some sort of tool to convert existing ini configs would presumably be needed.

OSX Native

Mac OS X uses property lists as a configuration format. These are quite Objective-C centric. The OS X Objective C API has an NSUserDefaults class for accessing these, and provides basic change notification support.

The fact that this API is Objective C may prove problematic.

There is also the Core Foundation API. This is a C API, but has no notification support (that I can find).

QDesktopServices

It may make sense to split between application state and actual configuration settings. DConf and other backends could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.

General

Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this. The implementation of a current KConfig backend is far from simple, and banging on current implementation add more code will not help in any thew goals of a new modern configuration system.

What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this ? The short answer is no, most the fact that even Trolls decided not support it anymore, and current KConfig architecture is way to different and for sure we don't want create an Unmaintainable Frankenstein.

@@ Line 3: / Line 3: @@
 = KConfig x New config as a library support =
-Replace KConfig with a Qt only based config library, with native backends for target operational systems. This new library will be suitable for even Qt only apps.
+Replace KConfig with a Qt-only-based config library, with native backends for target operating systems. This new library will even be suitable for Qt-only apps.  It will be the equivalent of Solid or Phonon for configuration.
-It will be a solid/phonon like library for backends
-Among cited characteristics desired
+Desired characteristics:
-* Remove all global config usage ( as <KDEDIR>/share/config in Linux ). All configs are user based and Kiosk is of course respected, so no user or distro will be afflicted
+* Remove all global config usage (as <KDEDIR>/share/config in Linux). All configs are user based and Kiosk is of course respected, so no user or distro will be affected. ''(Not sure what this means - is it simply saying that there will no longer be any configuration files installed by vanilla KDE? cf. next bullet point - rg3).''
-* kcfg and defaults not deployed anymore by a separated file. Defaults can be included in binary through headers for example, and are generated on the fly on first run from user. Distros still can have their tree with configs. Maybe a description generated by a tool to provide automatically which configs are available on the app to help distros.
+* kcfg and defaults would not be deployed anymore as separate files. Defaults should be included in binaries, through headers for example, and are generated on the fly on first run from user. Distros can still have their tree with configs. There should possibly be a tool to generate a description of what configuration files/options are available, for the use of distros and system admins. ''(Does this mean that the configuration system will still look in /etc/whatever, for example, so distros/sysadmins can change the global defaults? - rg3)''
-* New library would be wrote from scratch and a kconfig new code will be as the direct glue to make kde compile it without change current implementations. In future, apps can use directly the new library as kconfig wrapper will not be needed anymore. KConfig will be a transitory stage
+* The new library would be written from scratch, and a KConfig compatibility layer would be provided to retain source compatibility. In future, apps should directly use the new library. The KConfig wrapper will be a transitory stage.
 Helio wants to try to implement it.
@@ Line 20: / Line 19: @@
 * Multiple instances of same app and concurrent write/read
-* Desire of config change notification related to backends, not all can have this available. Since we're not look deep on other platforms config systems, we assume that dconf is the only one that has it.
+* We want notifications of changes.  Is this available on all platforms?
+** [http://live.gnome.org/dconf#Overview dconf] has change notification support.
+** The Windows registry also does, via [http://msdn.microsoft.com/en-us/library/windows/desktop/ms724892%28v=vs.85%29.aspx RegNotifyChangeKeyValue], for example.
+** Mac OS X's NSUserDefaults class also has a [https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/c/data/NSUserDefaultsDidChangeNotification notification method], but it is quite coarse (it just tells you that the application's settings have changed) and is also Objective C.  The [https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html#//apple_ref/doc/uid/20001450 C API] does not appear to have notification support.
-* Migration from kde4 configs. Proposal of a tool to make the process. This is feasible, only will relies on create a parser or use kconfig to read ini files, and will take some time to write. Using kconfig itself will create an undesirable dependency.
+* Migration from kde4 configs. A tool could be written to do this. This is feasible - it only requires writing a parser, but will take some time to write. Using kconfig itself will create an undesirable dependency.
 = Configuration systems =
@@ Line 58: / Line 60: @@
 == Windows Native ==
-TBD
+Registry?  It has [http://msdn.microsoft.com/en-us/library/windows/desktop/ms724892%28v=vs.85%29.aspx change notification support].  Probably doesn't have all the types we would want - some encoding may need to be done.
-== OSX Native
+Some sort of tool to convert existing ini configs would presumably be needed.
-TBD
+== OSX Native ==
+Mac OS X uses [https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/UserDefaults/Introduction/Introduction.html#//apple_ref/doc/uid/10000059i-CH1-SW1 property lists] as a configuration format.  These are quite Objective-C centric.  The OS X Objective C API has an [https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/occ/cl/NSUserDefaults NSUserDefaults class] for accessing these, and provides basic [https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html#//apple_ref/c/data/NSUserDefaultsDidChangeNotification change notification support].
+The fact that this API is Objective C may prove problematic.
+There is also the [https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFPreferencesUtils/Reference/reference.html#//apple_ref/doc/uid/20001450 Core Foundation API].  This is a C API, but has no notification support (that I can find).
 = QDesktopServices =
@@ Line 72: / Line 80: @@
 = General =
-Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.
+* Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this. ''The implementation of a current KConfig backend is far from simple, and banging on current implementation add more code will not help in any thew goals of a new modern configuration system.''
-What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this?
+* What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this ? '' The short answer is no, most the fact that even Trolls decided not support it anymore, and current KConfig architecture is way to different and for sure we don't want create an Unmaintainable Frankenstein. ''