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 458938
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Talk about arrogance
by leos on Tue 18th Jan 2011 23:18 UTC in reply to "RE[5]: Talk about arrogance"
leos
Member since:
2005-09-21

Why is that not a valid approach? What does KDE have to lose if Qt devs implement dconf suport?


The power of Qt (and KDE to a lesser extent) is that the same developers interface will have different backends on different platforms, so the developer doesn't have to worry about it.

This is extremely powerful in allowing developers to concentrate on features in their applications, rather than worrying about exactly how to interface with the local libraries that perform task X on whatever platform they are on.

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.

Adding a DConfConfig class to Qt and asking all app developers to add support for it is totally backwards. Any even somewhat competent developer can tell you that. Hopefully that is not what Shuttleworth is actually suggesting and it will be clarified.

Edited 2011-01-18 23:19 UTC

Reply Parent Score: 9

RE[7]: Talk about arrogance
by plague on Tue 18th Jan 2011 23:45 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[7]: Talk about arrogance
by ndrw on Wed 19th Jan 2011 06:22 in reply to "RE[6]: Talk about arrogance"
ndrw Member since:
2009-06-30

> KDE has a separate class that adds more features, called KConfig.

Ubuntu is not targeting KDE apps, not at the moment at least. What they want to do instead, is to make Qt applications feel native on the Ubuntu desktop.

Qt apps use QSettings, not KConfig, hence modifying the latter would largely be irrelevant to Ubuntu goals.

I'm happy with this move (see http://www.osnews.com/permalink?446284). Qt is a extremely developer friendly toolkit, yet lacking in areas related to user experience. If Ubuntu can iron out some of these (relatively minor) wrinkles it will be a win-win game for all parties involved.

Reply Parent Score: 2

RE[8]: Talk about arrogance
by segedunum on Wed 19th Jan 2011 14:18 in reply to "RE[7]: Talk about arrogance"
segedunum Member since:
2005-07-06

Ubuntu is not targeting KDE apps, not at the moment at least. What they want to do instead, is to make Qt applications feel native on the Ubuntu desktop.

KDE applications are the biggest open source Qt using applications around. If he's not at least thinking about them then one can only imagine he's going to get Canonical to write a lot of Qt applications, from somewhere.

Qt is a extremely developer friendly toolkit, yet lacking in areas related to user experience.

Is it? Wow.

Reply Parent Score: 3

RE[7]: Talk about arrogance
by Soulbender on Wed 19th Jan 2011 09:08 in reply to "RE[6]: Talk about arrogance"
Soulbender Member since:
2005-08-18

Why? It's not about KDE apps, its about QT apps. One could actually question why KDE is not using the existing QSettings stuff but instead went their own way.

Reply Parent Score: 3

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

Why? It's not about KDE apps, its about QT apps. One could actually question why KDE is not using the existing QSettings stuff but instead went their own way.

If you read Mark's post he talks also about KDE apps in a possible future.. aaanyways.

As I explained in the other message, QSettings is quite limited, and the usage of its API is anot as nice as it would be, for sure not as nice as the rest of Qt API (actually it's one of the things I miss more when I have to write Qt only code)
KConfig support of things like fallback to system wide config or nested groups is a bit better (tough improved a bit in qsettings lately), tough one quite significant architectural difference is the type safety and configuration hange that in KDE is possible to have.

Reply Parent Score: 2