As some of you probably have already seen on Mark Shuttleworth's blog, Canonical is embracing Qt. They have even started developing apps in-house using it, such as Unity-2D, which is great.
Within KDE, we've long espoused the idea that the user doesn't care what tools the developer uses and that we should be working to give them the biggest and best choice of applications that work together well. Seeing others, particularly groups who have historically taken rather heavy-set stances that worked against that, start to come around more and more to the idea is good for Free software and our users.
There is still work to be done, however. 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. This is not that much different from saying that Qt apps should just use Gtk+ for rendering so they fit in better, just doing so at a different layer in the stack.
One of the great strengths of Qt, and something that KDE benefits from greatly, is portability and the wide availability of common infrastructure as a result. 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.
To get applications working together as well as possible, the answer is not to start creating Ubuntu-targeted versions of Qt apps, but to work on the issues below the application developer's line of sight. If settings are an issue, then there are two avenues that should be pursued: identification of which settings ought to be widely shared and identification of management processes that ought to be shared. The former can be approached through standardization if nothing else, and the latter is probably a technology problem.
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. That is a strategy fraught with risk and is socially unrealistic given the number of stakeholders.
There are ways to fill in remaining gaps such as configuration related issues that are well within our combined reach, and which we remain quite motivated to continue to fill in. KDE has led the way in not just helping define standards (including ones Canonical now uses), but adopting ideas from the outside (just look at all the freedesktop.org initiatives KDE Platform 4 uses!), working with others on specs (including things like integrating dbusmenu with StatusNotifiers, something Canonical and KDE worked on together to make happen) and working to improve the mechanisms by which such standardization happens. We're open and wanting to work with others, and Free software users would benefit from as many in the Free software ecosystem adopting a similar approach.
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. That mode of operation is what got Qt and KDE Platform, as high quality developer tools, to where they are today. It is what motivates us to look at the development platforms we build for application developers and ask ourselves, "How can we make this as painless as possible for the developer while giving them access to as many platforms as seamlessly as possible?" It's a way of thinking that helps create a superior result, and we're always looking for new ways to expand the benefits it brings.
Subscribe to:
Post Comments (Atom)
20 comments:
Hmm.
My interpretation of the DConf thing is that Canonical is contracting Ryan to build a Qt based DConf access library.
Which, so I assume, could then be used to build a QSettings backend to read/write settings from/to DConf.
So, exactly as you suggest, below the application developer's level of abstraction.
I'm an avid fan of Qt, KDE, and Linux in general. My love of Qt stems from two main points:
1) It's cross-platform, and it achieves this without taxing developers with a whole load of baggage. Unfortunately, it's not (yet) as compatible between different Linux desktops. Qt apps look terrible in a GNOME session.
2) It's simple to use - both from a developers point of view (clean, clear APIs), but also from a users (apps follow platform styles & guidelines where possible). I haven't looked at the alternatives for a number of years, but have tried using both GTK and wxWidgets in the past. In terms of productivity, nothing compares to Qt.
I'd love to see Ubuntu standardise behind the Qt libraries - apart from anything else, it means Kubuntu might get some love. A working U1 client might be a good start.
@Kevin: "Which, so I assume, could then be used to build a QSettings backend to read/write settings from/to DConf."
currently, Canonical is using libgconf directly in products like unity-2d.
second, KDE apps do not, in general, use QSettings except for a few specific use cases. so even if this was to be put beneath QSettings, we'd still need to figure out a path forward.
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. it is both error prone from a technical POV and socially untenable.
beyond dconf, this approach is the standard operating procedure for Mark and his company. it could use some improvement. the configuration item is just a useful (and the most recent) object lesson at hand from which we can draw these conclusions.
"So, exactly as you suggest, below the application developer's level of abstraction."
but that isn't at all what we see so far.
i think we'd all be better off if people played apologist less often for Canonical and held them to their actual words and actions. it's what happens for most of the rest of us in the F/OSS world and that accountability really helps drive improvement and minimize (though, of course, not eliminate all) problems.
@Thomi Richards: "Qt apps look terrible in a GNOME session."
the #1 reason for that is the GNOME developers and to a lesser extent the packagers who often work on packaging GNOME envs up for their distros. they usually don't care much about anything that doesn't come from their own world. there are exceptions, but they are indeed just that: exceptions. the results are indicative of the mindset, and Mark's blog entry is not far from that status quo approach.
in Qt we've done all sorts of useful things such as the platform plugins for environment dialogs (file, print, etc), theme bridges (so, e.g., Gtk+ can theme Qt), dynamic dialog button re-ordering, etc.
in KDE, we have ourselves worked on extending our "native" look 'n feel over to Gtk+ apps with efforts like the Gtk+ Oxygen theme, Firefox and Open Office bridges, etc.
we've adopted (and participated in) icon naming specifications, etc.
and yet .. it's still so very much a one-way street.
so while a Qt (or KDE) app can look quite good in a GNOME env, it sometimes falls short and is made so much harder than necessary.
it's amazing how much a typical Qt or KDE dev tends to know about the available compatibility efforts versus how much the typical Gtk+ or GNOME dev does. i'm constantly unpleasantly surprised when i find yet another Gtk+/GNOME dev or packager has no idea Qt supports native Gtk+ theming, for instance.
Qt 4.7 is far, far better at this than previous releases, but we need people from outside of the Qt and KDE world to start caring more about the _whole_ experience from the user's POV to make it as good as it could, and should, be.
the hermetic sealing of communities and the approach of "here, just use our stuff we developed by ourselves over here and then there's no more problems!" really needs to stop.
"In terms of productivity, nothing compares to Qt."
agreed :)
"I'd love to see Ubuntu standardise behind the Qt libraries"
again, agreed :)
currently, Canonical is using libgconf directly in products like unity-2d.
I see, I had assumed that would be using the recommended approach (on the GLib stack) and use GSettings.
second, KDE apps do not, in general, use QSettings except for a few specific use cases.
I know, I was focusing on the "Qt application" part. For KDE apps we would be needing a KConfig backend.
Anyway, I was probably too focused on the technical considerations and didn't pay any attention to the baiting and such.
Just saying that having native access to some technology does not imply using it directly. Especially not when usual app developer facing API is designed for using different backends.
@Kevin: "having native access to some technology does not imply using it directly. Especially not when usual app developer facing API is designed for using different backends. "
agreed; when those backends are done reasonably well, it's a terrific thing to have.
Perhaps the work to untangle kde lib dependencies could lead to ubiquity of those libraries across Gnome and KDE now?
@Ville: "Perhaps the work to untangle kde lib dependencies could lead to ubiquity of those libraries across Gnome and KDE now?"
this is definitely one of the hopes: that more app developers will be able to benefit from these libraries.
a lot of them are already 'untangled' (and have been for quite a while), but we need to do a better job in how they are packaged and promoted (iow: mostly public discussion)
i really wonder why they did not use plasma for unity-2d, i mean, they are basicaly reinventing the wheel. Somebody says that that is because they can't have kdelibs + the gnome libs on the same cd, but does plasma really need all of kdelibs? i'm wondering anyway how big that kdelibs is everybody is complaining about.
The problem I have is it's not clear what problem they are trying to solve here. If they want to write an all new desktop with all new apps that only run under their new desktop and only use their chosen settings storage, then they are going about it the "right" way. If they are wanting to solve the problem of apps written in any given toolkit for a particular desktop not fitting in under any other desktop then they are going about it all wrong. We're obviously interested in the latter, the former is something I have no desire to participate in.
What I would like to see is the Ubuntu architecture team produce a document on what they think is wrong and what they think needs to be done to fix it, then invite all the affected parties to discuss the issue. That's what you would do if you were interested in solving the real problem, but I'm afraid Canonical is only interested in locking developers and users into their platform (now, where have I seen that before?).
@Beat Wolf: "i really wonder why they did not use plasma for unity-2d"
control is probably at least part of it.
"i really wonder why they did not use plasma for unity-2d"
well, unity does a _LOT_ less than Plasma Desktop or Plasma Netbook does. it's a rather simpler thing. there is certainly a lot of overlap, though, and it would have been possible to build this with plasma (including using QML).
"because they can't have kdelibs + the gnome libs on the same cd, but does plasma really need all of kdelibs?"
it doesn't use KHTML, but it does make extensive use of much of the rest of kdelibs.
CDs are really quite small in the end, and pulling in the dependencies for a "full featured" kdelibs over and above what GNOME uses is also an issue. the deps are not the same between the two stacks.
"i'm wondering anyway how big that kdelibs is everybody is complaining about."
not big in terms of disk space, but big enough to cause issues if targeting a "all on one CD" distro given everything else you need to cram on there.
> it's amazing how much a typical Qt or KDE dev tends to know about the available compatibility efforts versus how much the typical Gtk+ or GNOME dev does. i'm constantly unpleasantly surprised when i find yet another Gtk+/GNOME dev or packager has no idea Qt supports native Gtk+ theming, for instance.
Aron, this ignorance exits within both camps.
Actually during my day job ignorance is the smallest issue I face. Much more often I see distrust and even plain hate between both camps. Badly needed features not being implemented just because the guy asking for it is from the other camp... Only hurts.
Not convinced mixing both worlds will bring us a better desktop. Too many compromises. Too many hurt feelings. Mediocrity.
That said, it is perfectly possible to write a dconf backend for KConfig that would make all KDE application "eligible" according to Mark Shuttleworth.
Maybe this "shared configuration" issue could be discussed at the next Desktop Summit? If the Gnome and KDE communities will come up with a good and shared solution, I don't see why Canonical shouldn't embrace it.
> Maybe this "shared configuration" issue could be
> discussed at the next Desktop Summit?
Yes please, lets get a common backend for File Open /Print etc dialogs, so that the dialog is based on the desktop which one runs, not on the app opening that dialog.
http://gnuski.blogspot.com/2009/06/two-wishes-for-gran-canaria-desktop.html
@Cyrille Berger:
It wouldn't be as simple as that. The point of dconf (I think) is that configuration changes can occur outside the app, and then the app needs to respond to the signal of the change configuration. It is rather different then KConfig.
@aaron: the hermetic sealing of communities and the approach of "here, just use our stuff we developed by ourselves over here and then there's no more problems!" really needs to stop.
I very much admire QT and KDE and I am truly thankful for all the work people have done on collaboration, standards, shared technologies and so forth. Thank you for your efforts.
I am the developer of a modest application. I work on it when I have time; I have many other commitments. The application uses python, GTK and some Gnome technologies. Even in this "small world" there is so much to keep on top of -- new and improved Gnome / GTK technologies, python multiprocessing instead of threading, better algorithms for the application itself, etc etc. And of course there is a website to be kept up-to-date, documentation to be written, users to be supported, etc.
I just ask to remember that there are those of us for whom it's practically difficult to effectively keep on top of technologies from our various communities. There is a lot going on, with so much complexity to manage and consider! If we fail to do as good a job as we'd like to, it doesn't necessarily mean our motivations are against collaboration or that we think our community is the "best" one, or has "all the answers". It's just that we have limited time and many demands.
Personally I would love it if my program was better able to integrate in with relevant KDE programs, and vice versa. I remain optimistic that FOSS applications and systems can make life better.
Thanks again for all your efforts on the behind the scenes work to make life easier for part-time volunteer developers like myself.
Aaron said: "second, KDE apps do not, in general, use QSettings except for a few specific use cases. so even if this was to be put beneath QSettings, we'd still need to figure out a path forward."
My opinion is that Canonical is NOT making this move towards a GNOME/KDE integration. It's more about attracting developers and new apps, even commercial ones. So this move is not about KDE. It's about adopting a simpler and more modern toolkit for ISVs so they can create apps and probably sell them through the Ubuntu Software Center.
@taschenorakel Aron, this ignorance exits within both camps.
Actually, no it doesn't. If you take a cursory look down the stuff at Freedesktop you'll see most of the work having been done by KDE and Qt developers.
I also think taking the politically correct route of saying that everyone is to blame does a terrible disservice to the people who've put effort and code into things like GTK-Qt and the Qt integration with Gnome, GTK and glib.
There's certainly one camp that needs to be doing a lot better. Maybe this will be the start of something, but it's going to take an awful lot more than a dconf settings backend and a blog posting that says "This is what we're doing and this is how you can fit in".
You will probably also need to standardise on the settings that get put into dconf so applications know what they're looking at and can respond accordingly. That's going to need a mammoth effort with buy-in from everyone. It's not as simple as Shuttleworth is painting.
Is it just me who always gets bad feelings when Canonical is saying doing something for the community?
I have just so many times seen how much negative and very contrary things has happened almost everything what Canonical is doing when it comes to open source world.
Post a Comment