Linked by Thom Holwerda on Tue 18th Jan 2011 22:18 UTC, submitted by alinandrei
Ubuntu, Kubuntu, Xubuntu De kogel is door de kerk. After years of focussing entirely on Gtk+ and GNOME, Ubuntu will finally start evaluating Qt applications for inclusion in the defaukt Ubuntu installation. Mark Shuttleworth announced the policy change on his blog today.
Thread beginning with comment 458947
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Talk about arrogance
by plague on Tue 18th Jan 2011 23:45 UTC in reply to "RE[6]: Talk about arrogance"
plague
Member since:
2006-05-08

So the general problem here is different settings backends. Well Qt apps use QSettings that has different backends for different platforms, so on Windows it will use the registry, on Mac it will use plists, and on linux it will use .ini. KDE has a separate class that adds more features, called KConfig.

So the solution is not to add yet another class for dconf support. The correct answer is to work with KDE to either extend KConfig to allow using a dconf backend that will be transparent to the developers, or agree on a new interface that will support both backends.

I admit, I don't have any knowledge about the inner workings of QT/KDE/GNOME/GTK+/dconf, etc, so this may sound like a stupid question.. But If QT apps use QSettings, that itself has several different backends for different platforms, and the apps themselves work automagically with each backend, wouldn't it be easiest and best to simply create a dconf backend to QSettings?
Maybe that's exactly what you meant by extending KConfig to allow using a dconf backend?

If this can be done, I see absolutely no problem with it, even if a "better" solution is to be introduced later on.

Reply Parent Score: 4

RE[8]: Talk about arrogance
by Carewolf on Wed 19th Jan 2011 17:20 in reply to "RE[7]: Talk about arrogance"
Carewolf Member since:
2005-09-08

KConfig is an order of magnitude faster than QSettings, and a couple of orders of magnitude faster than DConf. The suggestion of merging configuration backends have been suggested before, and the result was:

* GNOME solution is not good enough for KDE
* GNOME refuses to use the C++ implementation, KDE uses
* KDE doesn't care to port a C++ implementation to C, just because GNOME are being silly

Of course now that GNOME are starting to use C++ through Qt, the pedantic argument that has previously prevented any KDE technology from being adopted by GNOME could finally go away.

Reply Parent Score: 4

RE[9]: Talk about arrogance
by vivainio on Wed 19th Jan 2011 18:36 in reply to "RE[8]: Talk about arrogance"
vivainio Member since:
2008-12-26

KConfig is an order of magnitude faster than QSettings, and a couple of orders of magnitude faster than DConf.


Citation needed. Note that this is dconf, not gconf.

Reply Parent Score: 2

RE[9]: Talk about arrogance
by Richard Dale on Wed 19th Jan 2011 19:35 in reply to "RE[8]: Talk about arrogance"
Richard Dale Member since:
2005-07-22

KConfig is an order of magnitude faster than QSettings, and a couple of orders of magnitude faster than DConf. The suggestion of merging configuration backends have been suggested before, and the result was:

* GNOME solution is not good enough for KDE
* GNOME refuses to use the C++ implementation, KDE uses
* KDE doesn't care to port a C++ implementation to C, just because GNOME are being silly

Of course now that GNOME are starting to use C++ through Qt, the pedantic argument that has previously prevented any KDE technology from being adopted by GNOME could finally go away.


KConfig is pretty hostile in terms of non-C++ language bindings. It uses method overloading on const-ness which no language other than C++ supports. It exposes C++ smart pointers in the public api, when they should only be in the private d-pointers. The KConfigXT api exposes references to primitive variables which must be passed to the methods. This is a nightmare for language bindings and applications like Plasma which have to jump through some incredibly complex hoops in order to get something which should be really simple to actually work.

The Ubuntu dconf Qt bindings are QML based and just mean setting properties on a QObject which is way easier to implement in non-C++ language bindings. I don't know if it is possible to map the full complexity of KConfig onto a QML based api, but I do know that the Plasma team are starting to do that. So what I would like to see is a QML api that sets properties on instances in the same way for both KDE and Ubuntu settings.

Reply Parent Score: 4