Submitted by 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.
Ubuntu has always had a Gtk+-policy (well, Firefox and OpenOffice were the exceptions), but today, that has changed. On his blog, Mark Shuttleworth has announced that starting with the release after Natty Narwhal, Ubuntu is going to start evaluating Qt applications for inclusion in Ubuntu’s default installation.
According to Shuttleworth, the major issue that needs to be overcome is that Qt applications use a different settings backend than the rest of GNOME. “To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu,” he writes, “We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers.”
He hopes these dconf bindings will also find their way to KDE applications. “I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community […],” he explains, “Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.”
As far as I’m concerned, this is great news. I used to not be a fan of using Qt application in a Gtk+ environment and vice versa, but I think that with enough polishing and backend integration, it should be possible maintain the nice and consistent feel of a strict Gtk+ or a strict Qt environment.
.
He wants Ubuntu to be fully accessible to everybody, so he said. If that’s still true, I hope he’s going to put some resources into making QT apps work with the various accessibility aids in Ubuntu. Otherwise, that makes Shuttleman a straight up liar.
Dammit, does nobody ever read the actual article before they start bashing Shuttleworth? Your answer is right in his blog post:
“In evaluating an app for the Ubuntu default install, we should ask:”…”is it accessible to people who cannot use a mouse, or keyboard?”
People, we are talking about the Ubuntu default install. He makes a difference between QT and KDE. He also even states that there is nothing preventing someone from installing a QT app on Ubuntu.
They just want to ensure that the best software in class is part of the default install and that it acts and looks like all of the other applications that are included by default.
That doesn’t answer the OP’s question.
The OP didn’t ask a question
What is it with {GNOME|Ubuntu|Shuttleworth} thinking that everything has to be done their way or nothing?
Rather than working with the QT devs, the KDE devs, the GNOME devs to find common-ground for storing, accessing, changing settings, Shuttleworth wants to (basically) fork QT, shoehorn in DConf support, and create a bunch of Ubuntu-specific QT apps that use DConf. And, probably, use the glib even loop in QT, and (maybe down the road) just turn around and use GTK to draw QT widgets.
Talk about driving a wedge into the desktop world. I thought we had the freedesktop.org movement to find commonalities and common ways to do things so that each toolkit could work together.
Aaron Seigo published a response that covers it nicely:
http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-next-colab…
Collaboration is needed. Not shoehorning your methods into someone else’s toolkit.
Collaboration is nice in theory, but design by committee is usually mediocre at best and disastrous at worst. If Shuttleworth’s got a clear vision of what his OS should be and wants to drop the manpower into making it happen, more power to him.
Funny how aaron doesnt seem to agree with you.
Where do you get that idea from?
Edited 2011-01-18 22:52 UTC
Mainly because Aaron is not being acerbic and is open for collaboration. Nowhere does he says that this is like driving a wedge in the desktop world, for example.
You’re reading this completely differently. He is advocating caution and already has some criticisms of how this is being presented:
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
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.
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.
Citation needed. Note that this is dconf, not gconf.
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.
What are you trying do. Send us around tree. KDE and Gnome Setting are enough of a headache. Now a third form.
Serious-ally this is not something a distribution should try to solve alone. Instead this should be going through proper standard making process.
We need a proper solution not someone just going Ok lets do this without standard process adding another layer of mess. It is bad enough now.
Ok what about wine integration what about fltk integration and the list goes on. GTK and QT are the major toolkits on Linux but there are quite a few minor toolkits.
If you are talking about constancy of interface you need a standard that covers them all.
Hear, hear!!
And if the existing standards aren’t good enough, then work with the stakeholders to improve them.
Edited 2011-01-21 19:45 UTC
> 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.
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.
Is it? Wow.
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.
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.
Writing a QSettings plugin is not creating a fork.
If it’s being done outside of Qt’s source tree and hasn’t yet been accepted then it’s a fork for the timebeing.
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
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…
I’m afraid that’s a hugely misleading thing to say. Let’s not misrepresent the huge dose of caution Aaron has thrown over this because of past experience.
Did you read the same blog posts I did? Because it sounds like you didn’t.
“Mark suggests that Qt developers should start using Canonical’s Qt add-on libraries for things like dconf so that Qt apps integrate properly with Ubuntu.”
Basically, forking QT, leading to Ubuntu-only QT apps.
“To get applications working together as well as possible, the answer is not to start creating Ubuntu-targeted versions of Qt apps”
Collaborate, don’t fork.
“Solving this means working together, not thinking that we are individually capable of coming up with the best ideas ever and that the world should simply bend to our whim of the day.”
Which is what Shuttleworth is doing, by shoehorning DConf support into a Canonical fork of QT, instead of working together with QT and/or KDE devs to find a solution to the settings issue.
“As more groups warm to the beauty that is embodied in Qt, I hope that the message of working together (rather than dictating, for life or otherwise) also spreads.”
Yes, and world peace will arrive tomorrow.
This is a very good solution, and is not a fork at al – that’s a bunch of FUD bullshit. All this means is giving Qt devs the option of building dconf support into their applications. Said applications will still work fine in any Qt environment, and as such, really can’t be called forks. He’s not forcing anyone, he’s not dictating anyone, he’s just saying: look, we’re hiring a few devs to work on allowing Qt devs to implement dconf support, and if Qt apps want to make use of that, fine. If not, also fine.
Jesus Christ the anti-Shuttleworth and anti-Ubuntu talk is reaching insane proportions around here.
Edited 2011-01-18 23:00 UTC
Hey, we gotta balance out the anti-Apple and anti-MS crowd.
Sorry, but I can only interpret this one way and it’s the same message that Mark Shuttleworth has given for years that has always ended up in nothing of very much significance happening:
What this means is that if a foreign application does things the way that we want in a way that we’ve already decided then we’ll be happy to dangle a carrot of inclusion into Ubuntu.
Not helpful, in other words, because whatever way you choose to see it that is dictation in any language – or at least attempting to dictate.
They’ve obviously now seen the error of their ways over the years with their development platform and path. How much do you want to bet that they end up being wrong over this shoehorned approach until they either change again or go bust?
And this is different to just about any other software collection, how, exactly? Are you telling me KDE doesn’t have rules for inclusion? OpenSUSE? Fedora?
Come on dude, this sounds a lot like trolling just because you hate Ubuntu.
Most (succcessful) software projects formulate their direction for things by including the projects that they hope will buy in and working out the best direction to go in. Those that dictate tend to not be very successful, and Ubuntu doesn’t have the best track record of thinking things through, dictating and convincing people that where they’re going is the right path. They’ve only been dragged kicking and screaming into accepting Qt after seven years.
The only way they’re going to make a success of this is by getting buy in from Qt and the developers of Qt-using applications, such as those in KDE, and he’s not off to the best start.
Sorry sweetheart, no. Ubuntu just doesn’t have track record of getting these things right, that’s all.
I’d appreciate it if you could leave this kind of trolling out of this as well. It kind of makes it look like any criticism of Ubuntu is trolling against it, you know?
They’ve obviously now seen the error of their ways over the years with their development platform and path. How much do you want to bet that they end up being wrong over this shoehorned approach until they either change again or go bust?
I am not an Ubuntu fan or anything, but even I have to jump in here: your comments sound like nothing more than trolling. They are perfectly within their rights to only include applications that work well on their desktop. After all, Ubuntu IS aimed for the desktop and they want to maintain atleast a certain element of quality there. Thus it’s perfectly reasonable to want to only include such Qt apps by default that fill their requirements.
After all, that’s what EVERY single effing distro does.
You can view it in whatever way that you want, but after seven years of steadfastly being hung-up on one toolkit, people complaining that perfectly good applications were being shoved to one side and coming up with some rather strange and very familiar reasons as to why they won’t even acknowledge any other toolkits…….the irony is not lost on those of us who’ve seen what’s happened over the past seven years.
No, outright excluding applications and alternative toolkits in installations based on ill-advised technology preferences is not what every distro does. Only some.
You can view it in whatever way that you want, but after seven years of steadfastly being hung-up on one toolkit, people complaining that perfectly good applications were being shoved to one side and coming up with some rather strange and very familiar reasons as to why they won’t even acknowledge any other toolkits
That’s called “having differing viewpoints and wishes” and, well, they wanted to keep Ubuntu as a GTK+ oriented distro.
No, outright excluding applications and alternative toolkits in installations based on ill-advised technology preferences is not what every distro does. Only some.
I see lots of distros doing that. Some distros ship only Qt apps by default, some only GTK+ apps by default, some ship a selection of both..
It’s ‘having a different viewpoint’ or trolling depending on when it suits and who and what the subject matter is. Frankly, I choose not to be an apologist for things that have happened.
For reasons that have never made any sense to anyone. That hasn’t been a terribly successful strategy, a point that I’ve already made.
I don’t know of any distro shipping only Qt applications and that only installs Qt by default. I know of quite a few that do that with GTK though.
Let’s not be an apologist and call a spade a spade, shall we? You can’t slice and dice this in the way that you want in some ways and then not in others that you find a little sensitive.
Give me an example of a QT only distro please… or even a GTK only distro
Give me an example of a QT only distro please.
I am unfortunately not familiar with Qt-oriented distros as I don’t use Qt.
or even a GTK only distro
Ubuntu, for example.
Im using ubuntu and I have qt
Im using ubuntu and I have qt
*sigh* Reading comprehension..The discussion was about _default install_, no one claimed there is no QT apps or libraries available in the repos.
KDE desktops have pretty good support for GTK applications, including settings.
http://en.wikipedia.org/wiki/GTK-Qt
If Shuttleworth wants to integrate Qt and GTK applications on the one desktop, which is a perfectly reasonable aspiration, why not just use what already works?
That’s a theme engine.
Read the article again. This is about the settings backend. A theme engine ain’t gonna help you there.
It gets you a long way there (although I agree there must be more to it than just a theme engine). On my system, GTK applications look virtually identical to “native” KDE/Qt applications, in that they all use the same Window styles; widget styles; system, window and application fonts; colours; printer settings; language settings; currency formats; etc, etc. Some GTK applications will even support KDE-style dialog boxes.
Surely such an approach is already far less eclectic than some other desktops, such as Windows for example.
Since it already exists, why not just go with that?
Edited 2011-01-19 00:19 UTC
Yer, and? It’s certainly a big help to desktop and application integration – and guess who wrote it? We’ll just paint over that though…….
This is about integrating applications, not purely about some settings backend. A settings backend by itself certainly won’t help you because you’ve got to agree a format with everyone as to what settings will be stored and how they will be used, and everyone has to buy into it for it to work. The article goes into no detail whatsoever there.
Stop telling people to read the article again when you don’t understand the implications within it yourself and Mark Shuttleworth doesn’t either.
KDE desktops have pretty good support for GTK applications, including settings.
http://en.wikipedia.org/wiki/GTK-Qt
If Shuttleworth wants to integrate Qt and GTK applications on the one desktop, which is a perfectly reasonable aspiration, why not just use what already works?
That would mean having KDE as the default desktop instead of GNOME, thus that is absolutely of no help here.
I’d like to find out why. Plasma is after all very “programmable” and configurable, and could probably be shipped in such a way as to look and behave almost exactly like the GNOME desktop you are used to.
Such a GNOME-mimicking KDE desktop would possibly be more like GNOME now than GNOME 3 and/or Unity desktop would be.
I’d like to find out why. Plasma is after all very “programmable” and configurable, and could probably be shipped in such a way as to look and behave almost exactly like the GNOME desktop you are used to.
That would be way more work than just implementing support for dconf. And it would require LOTS of work for everything to work like on GNOME.
How so? Desktop looks and feel is mostly just a set of settings, themes and widgets after all.
As Aaron Seigo points out:
http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-next-colab…
KDE settings and KDE desktop have already gone to extensive lengths to support GTK applications. GNOME has done absolutely nothing to support Qt or KDE applications. There is far less work it seems to me in making a KDE desktop look and behave like the current GNOME desktop than there is involved in making all Qt applications change their code to look at dconf settings.
Why can’t the GNOME world bend a little, just for once? After all, it is the nice suite of Qt-based best-of-breed desktop applications that the GNOME world is after here.
Edited 2011-01-19 01:17 UTC
KDE desktop look and behave like the current GNOME desktop
A desktop environment is much more than just a set of widgets and themes.
Why can’t the GNOME world bend a little, just for once?
Don’t generalize; this is about Ubuntu, not the whole “GNOME world.”
True. There is also, for example, all of the stuff from freedesktop.org implemented in KDE as well:
http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-next-colab…
“We’ve done a lot of work to make Qt and KDE apps work well on all sorts of platforms. This has taken the form of Qt Platform Plugins, porting Oxygen to other platforms, dialog button awareness, Qt’s NetworkAccessManager and much more. Part of the “much more” has also been standardization, of the “weak” sort where it’s more about conventions and sharing than strict ISO/ECMA-style standardization, of tools and protocols in use, often aided by freedesktop.org.”
This doesn’t answer the question.
And don’t forget that GNOME per-se is no longer going to be the default for Ubuntu, that will be Wayland. When that announcement came, I already started looking for an alternative distro for my PCs. Right now I am running Fedora 14 on a test machine and am pretty happy with it. Ubuntu will be replaced on the production machines either with Fedora or, if I just can’t get used to rpm, good old Debian (with GNOME!).
Cookie?
You are confusing Gnome with x.org.
You would be surprised, KDE made netbook desktop in about 6 months. That’s why plasma exists in the first place to be easy and fast to do any type of desktop, mobile, netbook, etc.
You would be surprised, KDE made netbook desktop in about 6 months. That’s why plasma exists in the first place to be easy and fast to do any type of desktop, mobile, netbook, etc.
I didn’t say anything about that. Lemur2 wanted to make a GNOME-like desktop environment out of Qt and that’s what I said would be a lot more work than a simple library for using dconf.
Sorry, from my point of view Lemur2 is saying: Please Qt is crossplatform don’t try to make all QT apps less crossplatform lets try a solution were we all may win. The new kid (ubuntu) in Qt land pops in and says: “Now you all going to do it my way! Were there is valid solutions were everybody wins.
Gnome is not the subject here, we are talking about Unity and QT (Unity is a nail on Gnome coffin not QT), but I was saying that gnome look and feel are easy to implement on KDE because of plasma tecnology. In fact some parts of Gnome 3 are similar to netbook plasma desktop.
Edited 2011-01-20 22:51 UTC
Yes, you have interpretted my position exactly. Thankyou.
Precisely!
the opposite is true as well, the default Qt build supports a theme that paints directly with the GTK engine.
Edited 2011-01-19 10:16 UTC
I think QGtkStyle still uses Qt for painting, Gtk is used to launch system dialogs and fetch the theme attributes & bitmaps for the painter.
the Clearlooks style did that.
QGtkStyle actually uses the GTK engine.
take a look at QGtkStylePrivate and QGtkPainter classes.
does pretty wicked things but works incredibly well
Checked it out, I stand corrected.
That’s the wrong way to be looking at it. It’s really a question of what already works and who’s actually done the work.
In reality though Qt now does a pretty good job of going in the reverse direction of taking on the Gnome and GTK environment.
Why not? Is there a religious reason agaisnt KDE? KDE with plasma could be made to look and feel just like Gnome if is that you want. Or a another type of GUI like Unity for instance.
Just because shuttleworth is letting Qt applications into Ubuntu, it doesnt mean its a good thing for intergration between desktops.
This is what exactly happened:
Qt is now far far ahead of GTK+.
Ubuntu wants to use Qt more.
They do the fastest and cheapest approach, which is also the one that has no cooperation with others.
What happens isnt very sad. We will probably see a few Qt applications which depend on something like libqdconf or something like that.
But the issue is, they could’ve done much more. They could’ve helped on a new standard on FD.o for managing settings. But they decided not to.
Please dont tell me that something designed by commite isnt going to work. FD.o standards have worked pretty awesome in the past few years. Its just that shuttleworth and ubuntu kids want FAST results. which isnt the best possible result.
And this is very very insulting:
You see, KDE people had KConfig which is a pluggable settings system for years. And they consider it as a superior technology. Then suddenly someone jumps inbetween and suggests them to use dconf so they could be more intergrated.
Edited 2011-01-19 09:36 UTC
Exactly. Rather than working within the existing communities (like fd.o), they are going their own way, doing their own thing, with a solution that benefits noone but themselves.
This Ubuntu bashing is petty.
Your mother never teach you not to look a gift horse in the mouth?
You do know there is like a gazillion other distros out there?
Guess its true, nobody hates you like your friends.
Nothing has to be done “their way or nothing”… The beauty of open source / free software is that if you like the idea you can use their software, and if you don’t like it, you can use any of the alternatives that suits your preferences.
Canonical is just putting its money where its mouth is by sticking to a vision and implementing stuff based on it, rather than trying to draw conclusions from discussions at different forums that usually turn into endless (and often pointless) “religious wars”. Whether the vision/idea is good will ultimately be decided by the users. (Unfortunately this doesn’t prevent others from having endless and pointless religious wars related to Ubuntu.)
I’m sorry, but I’m chuckling at how ironic that statement actually is.
All (?) Linux distros have built Qt to use glib for event loop for years. That’s the way to integrate with gnome stuff.
What is needed is *action*, not planning or discussing about planning. For whatever canonical is bashed for these days, you can at least trust that they are *doing*, not debating.
I don’t think it’s beyond the realms of sensibility that getting some buy-in from the developers of the software that you hope to use before hand would be a good idea for everyone.
Canonical has ended up ‘doing’ a lot of things over the years……and not being terribly successful at getting others to join in.
The beauty of open source development is it’s largely an evolution rather than design. For it to work people need to let go of the notion that there’s only one good way of doing things. We need to let people do what they think is the best to do, encourage them to do different thing.
So let Shuttleworth do his thing to Ubuntu. If you don’t like it, you have 9071431 other distributions to choose from, pick the one you like.
Sure. Go ahead. Whatever. Away you go, and write a set of interface binding for Qt apps to be able to query dconf. Fill your boots.
Just don’t expect authors of Qt programs to re-write all their applications (to call those bindings) just to satisfy the Ubuntu desktop.
As this thread title says … talk about arrogance! Sheesh.
PS: I have an alternative proposal for Ubuntu … re-write dconf for Ubuntu to set not only the dconf database but also to make synchronous, sympathetic changes to Qsettings. Integrate Qt applications without requiring any re-write by authors of said qt applications.
Edited 2011-01-19 02:55 UTC
Dude, are you even a developer? I mean, a real one?
if so, what do you do and in what languaje?
Just asking.
MYOBB.
So, you don’t.
Then stop trolling about subjects you don’t even understand.
I didn’t say that … I haven’t done programming for some years now, as I have moved up the engineering structure somewhat since then.
Wrong guess. Entirely.
As I said, MYOBB.
So, you are not in the field, out of curiosity, have you ever programed professionaly in something more than Visual Basic 6?
Although it is NOYBB, I have at different times programmed in various languages, my CV lists 11 (VB6 is not among them). I have also written a couple of interpreters and one compiler (for Pascal).
Edited 2011-01-19 05:56 UTC
So, pascal boy, you are not in the field right? Ever touched a moderm programming languaje or toolkit?
Was that compiler writed in pascal school homework if that’s the case why are you even counting it?
Most recently I have been using Python, Perl, C, C++, Java and PHP, all of which are perfectly current … and so is Pascal BTW
http://www.lazarus.freepascal.org/
What is exactly wrong with you? Has your doctor prescribed something that tastes nasty so you are refusing to take it? Go home and take your medication little man.
Edited 2011-01-19 06:20 UTC
Dude, it is a simple question. chill out. Can you answer it?
Dude, stick you head up your own behind, why don’t you?
Don’t be aggresive, Im trying to be friendly here, come one, answer the question, what can you lose?
Please don’t pollute technical threads with ad hominem bickering.
Was I even talking to you?
No, but these snarky comments are stressful to read even if you are not the target.
No
I rest my case.
I don’t believe you.
You are the only person that has suggested that someone who programs in C# (me) for a living using QT-C# bindings for development instead of Visual Studio. The amount of project risk associated with that is enormous.
No decent educated software developer would recommend that.
Stop trying to respond to this corrosive troll, because that’s all he is.
Says the Visual Basic 6 boy, I haven’t seen any other troll with such a cruch on Mono, Ubuntu, MS, and whatever it moves than you segetroll.
Maybe you should get help before giving such advice.
Actually, you’re the one sounding ignorant. Do you have any idea what is required to write a compiler/interpreter?
Edited 2011-01-19 08:05 UTC
I propose adding an “ignore user” option to OSAlert, and ignoring Hiev as default to show people how it works. OSAlert would be a better place.
Why?, I have so much love to give you to all.
Edited 2011-01-19 15:35 UTC
Because that’s an outright stupid and horrible idea. What next? A configuration merge engine which asks the user in toolkit-independent manner how differences in two supposedly simultaneously managed config backends should be merged?
Yes, I have reconsidered … a better approach is for Ubuntu to write a replacement for QSettings class and qtconfig, such the the replacement libraries run with the rest of Qt only when GNOME runs. This maintains the dconf database as the repository of all GNOME settings, and Qt applications running under GNOME would see those settings translated from the dconf database.
If one also installed KDE on the same machine (perhaps for different users to use as their preferred desktop), when KDE ran the exact same Qt applications they would see the KDE desktop settings for that user, since KDE would be running the default QSettings class and qtconfig settings.
So, I agree, doing it that way around is better.
However, either way is still better than what Shuttleworth proposes, requiring Qt applications to be re-written to run under a Ubuntu-unique version of GNOME.
KDE doesn’t use QSettings.
Oh, wouldn’t something as thoughtful as that be nice to work with?
There just might be hope for humanity yet. Although, I wonder if any Canonical people read OSAlert …
The biggest problem with open-source development is that it’s largely evolution rather than design.
Which is fine, so long as there is a vision of what the end product should look like. Re-doing things every 6 months because it doesn’t work is no way to run a software project. There needs to be some kind of framework, plan, whatever, and not just “try X; fail; try Y; fail; Try Z; mostly works; Try Q; almost works; try A; works; try B; works better” ad nauseum.
Because design-by-committee has been time again shown to be slow and often substandard. Sometimes it works, sometimes not. It’s true that this method rarely fails but it also rarely produces something innovative.
That’s not even taking into account the typical knee-jerk reactions I would expect from the non-Ubuntu people in the open source world (which Ubuntu has plenty of experience with, by the way).
Arrogrant, bloody-minded, dictatorship (I’m purposely exaggerating) can be a good thing.
and never the less, without efforts like freedesktop (that admittely have its share of problems) we wouldn’t even have the same storage for the start menu, the same hints for windows (a panel is a panel in all window managers that wasn’t really true some years ago) we couldn’t see notifications of applications written in the other toolkit…
(to not mention waay wider efforts like uhm, HTML anyone?)
Now, we have gained a significant amount of interoperability over those years, it would be a shame backpedal it.
Things like Ubuntu just proposed, are in the right direction, with the best intentions of the world.
What I say is, be careful of how something is pushed forward, a little “implementation detail”, like it can be the choice of writing backends versus a new api, can have the consequence of having very good or very bad consequences.
And you know how all of this can be avoided? it’s called “working together”, and is what it’s slowly starting to happen. We are talking with them and for this very reason I’m delaying any judging until this thing rolls down.
As collaboration with Ubuntu goes, in the history we have very sore points but very successful episodes as well (for instance the integration of our StatusNotifier protocol with their DBusMenu protocol was a quite good example of working together) so, we’ll see.
What I can say, that from KDE we are always open for collaboration.
anyone tried it on trunk GNOME? seems to fail miserably on x86_64 (core dumps all the time.)
Not surprising. QT apps or not, Ubuntu will still be the crash happy Linux Distro that breaks on every update!
You don’t appear to know what you’re talking about.
offering devs more language options on the ubuntu ‘platform’ can only be a good thing.
I might be jumping a few (lots) of steps, but it could be a decent olive branch to nokia to possibly work closer together in the mobile/linux space
My first thought was Nokia also but of Ovi’s apps being QT based. Potentially, the same app I run on my phone may be natively available to run on a future Ubuntu release (assuming Ovi and/or Ubuntu last long enough).
They’ve eventually been dragged kicking and screaming into doing this after years of the “Oh, we won’t ship Qt or anything that even smells like it’s been near KDE” basically for their own petty NIH reasons – something they were more than happy to accuse others of. Those of us who identified Qt as the right basis years ago are simply rolling our eyes.
To be honest, all this sounds like it’s coming from a company that’s now thinking it has to do something.
All they need now is a desktop environment that works well with Qt and isn’t a tack on, and some actual Qt applications……….. From Mark’s blog postting that sounds like it’s going to be as much of a challenge as getting them to even acknowledge Qt was there. It’s only taken seven years!
Edited 2011-01-18 23:00 UTC
So what was this Kubuntu thing about? This is not about “the right basis”, but about “any basis”. So far they’ve focused on building more-and-more user-friendly systems based on each “basis”. Now they are starting to work on removing this “basis” barrier so that you can use applications with different toolkits in a single system consistently.
I’m not entirely sure what that claptrap is supposed to mean, but:
Which they’ve always been somewhat less than keen to do in the past, leaving it to other people to do in spite of them. Afterall, it’s only taken them seven years.
Edited 2011-01-18 23:37 UTC
As far as I know, most people who work on Ubuntu are either Canonical employees, or volunteers who do it because they agree with Ubuntu’s goals and enjoy working on it… I can only assume that by “other people” you are referring to the large number of volunteers, but I fail to see how that can be a bad thing.
“De kogel is door de kerk”? My sub-standard Dutch translation skills tell me that this means “The casserole is by the church”, which makes no sense. Can someone explain?
Edited 2011-01-18 23:47 UTC
It means “the decision has been made”
I don’t know why Dutch expressions keep being used without any reason or explanation
Hey, I kind of enjoy the foreign idioms. I don’t speak Dutch, so I turned to Google translate which says:
“The ball is cast”
There is an expression in English “The die is cast.” An explanation for how this originated:
http://idioms.yourdictionary.com/die-is-cast-the
So, the decision is engraved in stone.
As for the decision itself, I’m OK with it. Anything that makes my Ubuntu desktop work a little better is a step forward.
Peace.
That’s nice. After utterly ignoring Qt and KDE for many a year, suddenly, just for the sake of the Ubuntu default desktop, all authors of Qt applications must re-write parts of their application in order to be aware of qt-dconf settings, unique to Ubuntu?
I’m so glad you are OK with that. </sarcasm>
Yep, they must. All Qt programmers that do not use dconf will be arrested and executed.
Oh wait, the only downside to not implementing dconf is that you won’t see your application installed by default on the Ubuntu live CD. So no, nobody must do anything.
All Canonical is doing is creating a new piece of software that allows Qt application to integrate better into GNOME and Ubuntu. Yes, not just Ubuntu, this will also benefit other distros that combine GNOME with Qt applications. And everybody is free to use or ignore it.
I don’t get all these comments saying “I have wanted Qt apps in Ubuntu for years, and now they are doing it. Those bastards!”
Oh wait, the only downside to not implementing dconf is that you won’t see your application installed by default on the Ubuntu live CD. So no, nobody must do anything.
Indeed. The library is already being written so an application which wishes to be part of the default installation only needs to add the library and to save/store its settings via that. Not really a big effort needed. And besides, not all apps are going to get on the default installation anyways.
I don’t get all these comments saying “I have wanted Qt apps in Ubuntu for years, and now they are doing it. Those bastards!”
I suppose they were happier complaining than actually getting something. And still, Qt apps have been available in Ubuntu for years, the only difference now is that it’s possible some Qt apps will be included by default.
I’m sorry you missed the sarcasm tag, I actually did put one right there in that post for you.
Anyway, my point is this … why should authors of Qt applications be falling over themselves to re-write their apps just for the “honour” of being included on Mr Shuttleworth’s Ubuntu default install CD?
Why would it be so hard for Mr Shuttleworth to arrange to do the work of integration, if he wants to include these best-of-class Qt applications on his default CD?
There are two methods which come to mind, neither of which would require Qt authors to leap to Mr Shuttleworth’s bidding (for Mr Shuttleworth’s benefit):
1. Ubuntu writes a replacement qtconfig
http://doc.qt.nokia.com/latest/qtconfig.html
The qtconfig tool allows users to customize the default settings for Qt applications on a per-user basis, enabling features such as the widget style to be changed without requiring applications to be recompiled.
and a replacement for QsettingsClass in the QtCore module, both of which integrate with dconf, all other parts of Qt remain untouched,
http://doc.qt.nokia.com/4.6.2/qsettings.html
Detailed Description
The QSettings class provides persistent platform-independent application settings.
Users normally expect an application to remember its settings (window sizes and positions, options, etc.) across sessions. This information is often stored in the system registry on Windows, and in XML preferences files on Mac OS X. On Unix systems, in the absence of a standard, many applications (including the KDE applications) use INI text files.
QSettings is an abstraction around these technologies, enabling you to save and restore application settings in a portable manner. It also supports custom storage formats.
QSettings’s API is based on QVariant, allowing you to save most value-based types, such as QString, QRect, and QImage, with the minimum of effort.
or
2. Ubuntu writes an expanded dconf module which edits both the dconf database and the qtconfig and QsettingsClass storage.
Either way, it seems to me, suddenly Qt applications running on Ubuntu will see the same settings changes as dconf does, without any requirement for said Qt applications to be re-written or even re-compiled.
Surely this is an infinitely better solution for everybody, even for Mr Shuttleworth?
Edited 2011-01-19 09:24 UTC
dconf has technical advantages over flat-file storage, including notice of changes, and a quite fast retrieval/loading mechanism (as it is more likely that settings are read than written).
Having the author of dconf write bindings for Qt, so there is the choice of using it, is a good thing!
But only Qt applications which were re-written to explicitly call those bindings (probably making them a dependency, and also therefore bringing in dconf as a dependency) would be able to work.
However, modifying dconf to also provide a replacement QSettings class and a replacement qtconfig would provide the desired mechanisms for Qt applications running under Ubuntu’s GNOME to use the dconf database WITHOUT having to modify said Qt applications!
Better for everybody!
This would be a bad software design. dconf has a very dedicated purpose, you do not want to complicate it with unnecessary functionality.
Extra functionality (integration of an environment for Qt applications under GNOME) … that Mr Shuttleworth has said he wants for his GNOME desktop … functionality that already involves dconf … why not just do it within the dconf package and be done with it?
Better for everybody.
Edited 2011-01-19 10:42 UTC
Maybe I wasn’t clear: dconf doesn’t aim to do what you’re proposing. It’s clear that adding such a capability would be a bad software design.
Functionality has to be inserted at the right place, dconf isn’t the right place.
Wherever it is in GNOME that acts upon user input to do things such as “set the default system font” … this action should simultaneously set values in both the dconf database and wherever the (modified for GNOME) Qsettings class library and qtconfig store their settings.
dconf itself seems as good a place as any to me, but I am not familiar with the structure of GNOME and its system and user settings … so wherever. The concept is that the Qsettings class library and qtconfig only of Qt is replaced with something that works alongside (and simultaneously with) whatever modifies the dconf database. Simplest solution … provides integration of Qt applications on the GNOME desktop, as desired, makes the least impact changes, does not require Qt applications themselves to be modified and become dependent on dconf. Also allows KDE to be installed on the same machine (with its own unmodified version of QSettings and qtconfig) such that it is independent of the GNOME desktop replacements for same using the dconf database store.
Edited 2011-01-19 11:00 UTC
Wait, I thought the sarcasm tag just applied to that last sentence you wrote. Are you saying it applied to your entire post? So this part:
was sarcastic as well? So you agree with me that it’s not true that all Qt applications must be re-writen and that it will only work on Ubuntu?
Anyway, I think here is where your problem lies:
Seems to me you are just creating this problem in your head. There is no matter of “honour” here. Nobody is being forced to do anything. Here’s how I see it for example:
For years people have been asking for the inclusion of Qt apps in the default Ubuntu install. Canonical didn’t want to do this at first because of poor integration in GNOME. But now it seems they have some room in their budget for helping that integration, making Qt apps in the default install possible. Apart from being good for Ubuntu in the long run, this is a favor for those who wanted Qt apps in Ubuntu. For those that are not interested in this, *nothing* changes.
If you don’t like their dconf solution, that’s fine. Your solution with QSettings sounds good too. Perhaps you should collaborate with Canonical on it, or try to implement it yourself.
But as long as they are implementing something with their time/money – something which has no down-sides because it doesn’t affect anybody that is not interested – than that can only be a good thing in my book. You can say it’s not good enough, but I don’t see how you can view this as a bad thing.
Qt applications must be re-writen under Mr Shuttleworth’s proposed scheme in order to work in an integrated fashion ONLY on Ubuntu. Yes indeed, that is what I meant.
Your misunderstanding, not mine. Indeed nobody is being forced to do anything … so nobody will do anything to make their Qt application depend on Ubuntu. That’s crazy.
So why not simply do it in a way that Qt applications can run in an integrated fashion under Ubuntu without requiring changes to Qt applications? All it requires is for Ubuntu’s GNOME desktop to replace a few small parts of Qt, in a very similar way that KDE desktops currently replace a few small parts of GTK in order to achieve the GTK integration. What exactly would be wrong with doing that? It is no more work for Ubuntu.
Canonical say they have already employed someone to do it the boneheaded wrong way. It won’t work guys, it will fall in a heap for lack of Qt application authors willing to make their applications dependent on Ubuntu’s GNOME.
It is not that so much as that I am making the observation that it could very simply, with a sensible approach, be made a very much better thing for everybody concerned.
Edited 2011-01-19 10:33 UTC
I actually asked whether you agree that that is *not* true. That is what you implied when you said your post was sarcastic. But never mind.
Look, all I’m saying is that I think you’re seeing it all too black and white. You point out some flaws in Canonical’s approach, then you present an alternative which you claim is flawless, then you claim Canonical is just boneheaded for not going with your solution.
There’s just more to it. The flaws you point out are just not as bad as you are trying to make them sound, and I’m sure your solution has problems as well.
But if your solution really is the ultimate perfect approach then I’m sure Canonical is willing to listen if you write them a serious proposal.
Put it this way … one of the primary reasons for writing your application to work with Qt is that Qt promises to give you very easy cross-platform support.
http://qt.nokia.com/
“QT – Cross-platform application and UI framework”
“Write code once to target multiple platforms”
This is the main billing for Qt.
Now Mr Shuttleworth has made a longish speech about wanting to include some of the great best-of-class Qt applications on his default Ubuntu install, and that he has hired a programmer ostensibly to enable this very thing to happen … but then he goes on to explain that the chosen approach would require authors of Qt applications to modify their applications to work with the special bindings just for GNOME on Ubuntu.
So when you listen to Mr Shuttleworth’s proposal, does not that ring a great big “hey, listen to this stupid idea” bell to you? Because it certainly does for me.
Edited 2011-01-19 11:52 UTC
I would be surprised if MeeGo didn’t move to dconf as well, as dconf appears to be the “best of breed” configuration database on Linux right now. Currently meego uses gconf which sort of sucks.
Qt has no dconf equivalent, QSettings is for static configuration data.
I am shocked at aggression and anger directed toward Ubuntu in so many of the comments in this discussion. It seems a small but very vocal minority is interpreting Canonical’s actions in the most negative light possible, and sharing their negativity with the rest of us.
FOSS development, just like practically any field in which people-to-people cooperation is essential, requires people be — at minimum — civil and respectful of each other.
Unfortunately much of the discussion in the last day or two has been anything but civil.
I’m shocked as well. Utterly shocked to my core.
I’m shocked that no-one has bothered to answer the perfectly civil question … “why should authors of Qt applications be falling over themselves to re-write their apps just for the “honour” of being included on Mr Shuttleworth’s Ubuntu default install CD?”.
There is no insult in the question, there are no angry words, no-one is accused of anything, and it is a perfectly valid quetion after all. Why should authors of Qt applications go to all the bother that Mr Shuttleworth is asking of them? What incentive is there?
Why shouldn’t it be a vastly more preferable approach that Ubuntu itself is modified slightly instead, in order to better accomodate Qt applications as they already are?
Hmm?
Why can no-one answer these questions?
Edited 2011-01-20 03:16 UTC
I already gave you two reasons in another thread: dconf is fast, and allows for notification of changes at runtime.
On the second point: being able to receive notification of changes at runtime is not something one can do without changing their source-code. It’s a fundamentally different operation than reading a settings file once.
This is not a reason why all Qt applications should be re-encoded rather than Ubuntu itself be re-encoded to better accomodate Qt applications as they are.
But why is it something that one needs to do? Just make the configuration change, close and re-start any Qt application. Just accept that this is a limitation of Qt applications. They will be perfectly integrated in all other respects, and no Qt applications will require re-encoding.
This way, Shuttleworth will be able to offer the entire suite of Qt applications straight away, with just that minor annoyance of not reflecting configuration changes until the next time the application is re-started. Ubuntu users will enjoy a much wider choice of pretty-well integrated applications than they do currently.
Shuttleworth’s proposed way … no one will bother to re-write their Qt apps for no good reason, and Shuttleworth will get no Qt applications for his default Ubuntu install.
How does the latter scenario help anybody?
Edited 2011-01-20 11:19 UTC
Shuttleworth’s proposed way … no one will bother to re-write their Qt apps for no good reason, and Shuttleworth will get no Qt applications for his default Ubuntu install.
You’re forgetting that there’s plenty of capable people using Ubuntu themselves. It’s quite probable they will write the patches for their favorite Qt apps. Eventually the most popular Qt apps atleast will have dconf support that way.
Sure, it’s not the smartest way of doing things, but atleast the goal is good: to have all the apps feel even just a tad bit more integrated.
Ubuntu developers have completely shunned Qt applications up until this point. Are you suggesting that suddenly they will become Qt experts, and somehow wrest control of Qt applications design aims from the original authors?
Given that the GNOME paltform up until now has treated Qt developers as lepers almost, surely a better goal is to modify GNOME to make it Qt-application-friendly in the form that the Qt applications already exist? The way it is, Shuttleworth seems to be saying to Qt developers: “here you are, former lepers, here is a pile of work you can do so that you may be finally admitted to the halls of GNOME on Ubuntu, to further the everlasting glory of the Ubuntu brand”. Or something like that.
My recommendation: to get along with other people, and join with them in collaboration, at least try to see things from the other people’s point of view.
Edited 2011-01-20 12:34 UTC
Ubuntu developers have completely shunned Qt applications up until this point. Are you suggesting that suddenly they will become Qt experts, and somehow wrest control of Qt applications design aims from the original authors?
No, where the f*ck did I say anything even resembling such? I said there are people using Ubuntu who are well capable of creating patches and submitting them to the Qt app developers. Read, it’s not that hard.
There are a variety of strawman arguments made by lemur2 in this thread. I agree it’s getting hard to carry on when the conversation doesn’t remain consistent.
There are a variety of strawman arguments made by lemur2 in this thread. I agree it’s getting hard to carry on when the conversation doesn’t remain consistent.
That’s his usual “conversational” style: take 2-3 words from the other poster’s comment and then completely twist the whole thing to suit his own agenda.
My “agenda” being to try to get people to see things from a different point of view that others might hold.
Please forgive my evilness on this, it is a horrendous failing of mine.
The result: a ridiculously disjointed conversation. It hurts any person with a logical comprehension process to read such a thing.
And Qt app developers are supposed to be overjoyed with this, and suddenly switch over to dconf, using a new untried API, just for Ubuntu? Why exactly? How do you think qt application authors might feel about it?
http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html
And Qt app developers are supposed to be overjoyed with this, and suddenly switch over to dconf, using a new untried API, just for Ubuntu?
No one is asking them to be “overjoyed” or switch over to dconf. They can use both their old system AND dconf. And why would they care if someone else does all the work for them and just submits a patch for it?