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 458930
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Talk about arrogance
by segedunum on Tue 18th Jan 2011 23:03 UTC in reply to "RE[3]: Talk about arrogance"
segedunum
Member since:
2005-07-06

You're reading this completely differently. He is advocating caution and already has some criticisms of how this is being presented:

finally, the suggestion in Mark's blog entry in quite literal terms is to use dconf within KDE. that may be a good idea, it might not be. holding out a "you can be included in $TARGET_OS" trinket as a mechanism to sway such decisions is not a useful approach no matter the validity of the suggestion.

Reply Parent Score: 5

RE[5]: Talk about arrogance
by Thom_Holwerda on Tue 18th Jan 2011 23:05 in reply to "RE[4]: Talk about arrogance"
Thom_Holwerda Member since:
2005-06-29

You're reading this completely differently. He is advocating caution and already has some criticisms of how this is being presented:

"finally, the suggestion in Mark's blog entry in quite literal terms is to use dconf within KDE. that may be a good idea, it might not be. holding out a "you can be included in $TARGET_OS" trinket as a mechanism to sway such decisions is not a useful approach no matter the validity of the suggestion.
"

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

Reply Parent Score: 1

RE[6]: Talk about arrogance
by leos on Tue 18th Jan 2011 23:18 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[6]: Talk about arrogance
by segedunum on Tue 18th Jan 2011 23:25 in reply to "RE[5]: Talk about arrogance"
segedunum Member since:
2005-07-06

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

That's an odd slant you've put on this. Qt developers haven't decided anything. You're rather jumping ahead of yourself here.

It won't be Qt developers implementing this. It's being done by someone, in a fork for the timebeing, in a way that has already been decided. I don't get the impression many people have been consulted. I suggest you read Mark's post. No one apart from Ubuntu has decided that dconf is even the right direction to go in.

Oh, and probably because it's the same approach Shuttleworth has generally used over the years, and he's always ended up being wrong and hurting everyone in the process? Shuttleworth, Canonical and Ubuntu don't exactly have a track record of being right.

Let's not be naive here. Shuttleworth and Ubuntu have been dragged kicking and screaming into accepting Qt. The only way this will work for them is if they end up with some applications they can use, and they don't get to decide that.

Reply Parent Score: 2

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

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

The admirable target of this move is to add more unification and consistence...

...what it would do in reality is adding more fragmentation, having just another API for a configuration system doesn't really add value but confusion.
Also, expecting developers to "write applications for Ubuntu" is not quite realistic. Most Qt-only applications are targeted to the most wide target platform (especially Windows and Mac in primis) so expecting them to target a specific Linux distribution (with the hope some other distributions will adopt it, but i wouldn't hold my breath) instead seems not realistic to me.

Now, writing it as a QSettings/KConfig backend is another story and makes more sense for sure, this is what i fully support (where the best case scenario is having a backend for both, with the KConfig one as the fully functional one, see below).

Now, probably QSettings itself is a bit too limited and I'm not sure it's possible to have a full support to dconf with its API.
Different discourse for KConfig, (that btw has good reasons to exist and to be sed in place of QSettings, we didn't write it just because we were bored) it adds things like better groups nesting support, system/user config fallback, type safety, change notifications..
all things that are necessary to represent 100% of dconf

Reply Parent Score: 4

RE[6]: Talk about arrogance
by molnarcs on Wed 19th Jan 2011 13:59 in reply to "RE[5]: Talk about arrogance"
molnarcs Member since:
2005-09-10

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


In theory, technically nothing. But KDE is not simply a sum of all KDE software. It's a fairly open community willing to work with anyone on common standards. Mark's post is a little bit arrogant in that it suggests the adaptation of something they developed in-house, instead of really working together with the community to solve common problems. This might be actually a good strategy sometimes, but not in KDE/QT's case. Those are not difficult people to work with, KDE adopted and collaborated on dozens of freedestkop.org standards. Anyway, I really really recommend reading Aaron Seigo's blog. In is usual lucid style he very clearly highlights the "problem" ;) That guy should be a PR expert or something (while Mark is obviously not ;) )

http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-next-colab...

Reply Parent Score: 5