Wed 16 Jul 2008
Flames Welcome (Is a Qt GNOME Desirable?)
Posted by J5 under Gnome , Freedesktop , Standards , usability , communityWe’ll I’m going to dive into the deep end (flames welcome) because I have been talking to people about the Qt “possibility” since Nokia bought Trolltech and GNOME was considering what to do for the future of its toolkit. I can see the headlines of yet another GNOME developer advocating using Qt4 as the basis of future releases but this simply is not the case. It is, in its basic form, an exercise in “what ifs?” and an iterative process of looking inward at our ecosystem and seeing the pros and cons of certain directions we could take.
Is this going to happen?
First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move. We are not going to turn our back on the great work the GTK+ teams are doing and most certainly the base libraries we use such as GStreamer wouldn’t change.
What are the possible advantages?
- Less confusion for the non-insiders on what to learn and program for
- We can get rid of the whole Freedesktop common widgets talk (e.g. Print and File dialogs) which is nonsense and a distraction anyway
- Hopefully less bickering in the community meaning a more unified and focused front against larger threats
- Focus can move from the lower toolkit layers to the higher level desktop layer which really define the value differences between GNOME and KDE
- Easier technology sharing
Note that these are all only possible advantages and may not even happen even if there was a move.
What are the possible disadvantages?
- More bickering on how to write applications (who’s approach to usability wins out?)
- Less focus and a return to writing applications without a shared guideline (just look at old XLib interfaces - almost like snowflakes)
- A loss of identity
- Loss of amazing GTK+ developers who may feel abandoned
- Splintering of the community so we have parallel GTK+ GNOME and Qt4 GNOME development
- Screwing ISV’s who bank on GTK+’s stable interface
- GTK+ isn’t just a license - we would be losing a lot by switching away from the codebase
- Falling into the growing pains GTK+ 2.0 brought GNOME and Qt4 is still bringing KDE
- A loss of activity at Freedesktop.org which is actually sometimes useful in producing dialogue and shared practices
- A loss of control over the direction of the toolkit effecting the quality and feel of the GNOME desktop
- Really a lot of development is moving to the web - will toolkits be important enough to warrant the pain of the move
What this wouldn’t be
This wouldn’t be a merging of GNOME and KDE. Each community has a different idea of what constitutes a usable desktop and Qt would simply be an implementation detail bellow GNOME.
Conclusion
This is pretty much a pipe dream. It solves some issues while creating a whole host of different ones. I’m not going to advocate it other than seeing what peoples reactions are. On the flip side if the work was put behind it, the planets aligned, and both communities came to an agreement I wouldn’t object to the arrangement. Needless to say, I’m not holding my breath nor would I be elated or saddened if it did or did not happen. To me it is all what is best for Linux, GNOME, Free Software and the wider market. It is unclear what direction would be best (any claims to that knowledge would be suspect) but honestly and actively looking at the possibilities is a useful activity, however remote. People reading should not put their “hopes and dreams” on this or believe it to be more than it is.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
July 16th, 2008 at 10:06 am
Why is the Qt license such a show-stopper? I understand that LGPL is nice and easy for ISVs to do whatever they want with the software, for example fork it and create a mobile platform or just rename everything to *Sun Java Desktop*. Qt has a dual license with the commercial license available for ISVs, which mostly also want support/training and help with implementation details. GTK-world has imendio, a handful of developers which can’t do the task, so ISVs do everything for themselves in GTK-world. This is different in Qt-world (and also a reason for some big ISVs switch to that framework recently) where Trolltech reacts on customer-whishes (which is often impossible in GTK-world). I think not using LGPL would in fact reduce the forking attitude ISVs have when using GTK. Comments anyone?
July 16th, 2008 at 10:23 am
Qt is such a terrible toolkit from an end user perspective.
It’s like Java Swing. Nice API and nice to develop with, but terrible to use.
I’d have to vote no for Qt replacing GTK+ in GNOME.
July 16th, 2008 at 10:28 am
@montressor:
Do you mean that Qt apps don’t look’n'feel like GTK+ apps? You might want to take a look at QGtkStyle (http://arstechnica.com/journals/linux.ars/2008/05/22/qgtkstyle-makes-kde-apps-fit-in-with-gnome)
which will ship in the next version. Can you give some arguments on that?
July 16th, 2008 at 10:43 am
You know, it could be a lot worse: if you’re going to break Gtk+’s API, you may as well look to see if you could write that new API as a C wrapper around Qt.
I think Qt has a lot of modernising to do as well, and the issue of control/development decisions and licensing is pretty important, but fundamentally, Qt is a lot further ahead than Gtk+ is in many important respects.
It really is worth thinking the unthinkable here. Maybe Gtk+ can be just extra Qt widgets/higher level stuff which makes more sense in GNOME?
July 16th, 2008 at 10:45 am
I recommend moving the discussion onto gnome-devel-list, I just started a thread there (gnome-devel-list@gnome.org).
July 16th, 2008 at 10:48 am
You have to really ask yourself what advantages Qt brings. You mention some ideas on having only a single codebase, but that’s it.
Qt has a lot of amazing features. Database bindings, built-in WebKit support, kick-ass canvas, etc.
Once you identify all the technological advantages, you then have to ask: which is more work? Rewriting the GNOME desktop on Qt or adding those features to GTK+?
I’m not really sure that the shared dialogs issue is going to go away with Qt. Like you said, the core difference between GNOME and KDE is the design and approach to usability. What makes people think that KDE’s ideal print dialog is identical to GNOME’s ideal print dialog? I mean, that’s the whole point - GNOME does not _behave_ like KDE. I’d imagine that GNOME and KDE — even if both used Qt — would still have a lot of differences in their dialogs, probably sitting in libraries about Qt, thereby reviving things like libgnomeui.
I also disagree with the assertion that the low-level API really matters. Between GTK+’s or Qt’s native API, I’d much rather work with Qt; GTK+ is a pure nightmare to even begin trying to understand, and once you do understand it, it’s a pure nightmare to get anything done with it. However, to be perfectly honest, I don’t want to use Qt’s native API either. I’d much rather avoid both C and C++ and work in a language that lets me get work done instead of making me jump through hoops to get the computer to understand what I want. Once you start getting to the higher level languages, the bindings for GTK and Qt start looking more and more alike.
In the end, I’d honestly state that whichever toolkit makes it easier to implement very simple, obvious, clean, easy bindings to Python, Ruby, C#, Java, or whatever else is hip these days is going to be the toolkit with the best developer API. Common consensus seems to be that GTK+ is the better toolkit in this regard, although that’s certainly debatable.
In the end, I think it goes back to whether it’s easier to rewrite GNOME in Qt or to just add those features that GTK+ lacks (and which even the core GTK+ developers keep complaining about the lack of — canvas, web widget, etc.). Just get those done and the theoretical advantages of switching Qt will mostly melt away.
July 16th, 2008 at 10:51 am
@Sascha - the control of Qt by one entity in order to allow the ability to dual licensing is a put off for a lot of companies. The LGPL has allowed us to work with a lot of companies who have contributed back to the base platform. Like kernel the toolkit is a basic building block for applications ontop of Linux. While one is allowed to develop over the GPL’ed Kernel without having to have a compatible license (provided they are using standard interfaces). With the toolkit this must be explicitly granted which we do with the LGPL which for the most part is unambiguous and an easy choice for ISVs.
“GTK-world has imendio, a handful of developers which can’t do the task, so ISVs do everything for themselves in GTK-world.”
This is so not true I don’t know where to begin. What GTK+ has is a host of expert contractors from Imendio to Collabora and large companies such as Red Hat and Novell to call upon. The fact that there are a number of sources and contributors shows the economic promise of Open Source being fulfilled. ISVs work together and also hire contracting companies for most of their GTK+ work. Nokia’s GTK+ development for instance is in large part done by contracting companies. The LGPL and more over the fact that no one entity owns the copyright to GTK+ means that everyone can contribute on a level playing field.
@montressor:
You are a little harsh. Qt4 is actually a decent toolkit but you are correct in saying it would change the feel of GNOME regardless of QGtkStyle since how a toolkit reacts to user interaction will go a long way in how the user perceives their experience. Putting a skin over a different implementation does not fix this though it does help somewhat.
July 16th, 2008 at 10:51 am
I have yet to see one single actually usable desktop environment that uses QT. One of the reasons behind that might be in QT itself and in the mindset that the developer has to conform with.
Talking of usability, mailing lists are more cumbersome, please never use them for anything important. It is bad for the transparentness.
July 16th, 2008 at 11:08 am
Maybe the true question is on KDE side: “is a GTK+ (*) KDE Desirable?”
(*) or what ever it becomes
Since GNOME is reshaping its toolkit nowadays, assuming KDE is not too happy about Trolltech’s acquisition, then… what about joining forces and experience for a common free UI toolkit at freedesktop.org?
July 16th, 2008 at 11:23 am
@sean
The freedesktop dialog fiasco is mainly because such work should happen in the toolkit not in yet another widget library. Having one code base means we can have the two approaches to dialogs but all that work happens within the toolkit.
The other thing to consider besides features which GTK+ will easily come into parity with Qt4 in time is control of the platform. Havoc has said, paraphrasing here, that Qt got it wrong by going out and producing yet another toolkit with flashy things added instead of rethinking what the platform of the future would be. If we lost control we might not be able to move in the directions we would like to go. So in my opinion focusing on features would be the wrong reasons for choosing the switch. The single platform for ISVs however is compelling.
July 16th, 2008 at 11:39 am
OK, This is an honest question.. Really, truly it is.
Why are things like “Lag” in Gnome not fixed first? Before a rewrite is discussed.
I have been running Fedora/Red Hat with Gnome for years on pretty fast computers and there still is perceptible lag when interacting with the Desktop Environment. You know what i mean… responsiveness etc.
I still haven’t ‘convinced’ my wife to move over to Fedora/linux yet and when I sometimes use her winXP computer ( which is the same hardware as mine), I find her Windows Desktop FAST. That thing reacts Very Quickly to clicks / keyboard interaction, where as I stated earlier Gnome doesn’t.
Maybe the problem is Xorg, or maybe the problem is This or maybe the problem is That. But I’ve experienced Gnome ‘lag’ on all my different computer hardware through the years.
This problem has definitely got better though. I remember on Red Hat 8, populating the Gnome applications menu in the panel was Painfully Slow.
When Gnome developers say that GTK+ 2 has basically gone as far as it can go, i just can believe that there are no way to improve things like “lag” on the current GTK+2 / Gnome.
With Respect,
Frank
July 16th, 2008 at 11:43 am
I may be an oddball case, because I vastly prefer Gnome applications over the KDE equivalents. But as a developer I really love Qt.
The Qt toolkit is amazing. It is well thought out and flexible. All the “next gen” features that Gtk is looking for are already implemented in Qt. Widgets on canvases, stylesheets, etc.
The Gnome application mentality is better for me than KDE. I still haven’t played with KDE4, but will soon.
July 16th, 2008 at 1:55 pm
This is an interesting question, and there are a few interesting points to make.
(1) Qt has moved towards GTK+ by adopting the glib event loop option. This is because Qt is aimed at portability rather than creating an X11 desktop. I.e. Trolltech’s interest is to make Qt work seamless with GNOME/GTK+ - it is their business.
(2) Qt has been designed with portability in mind from the start, meaning that it is easier to move between platforms and devices. I understand it as if this is one of the points that Imendo and Nokia have been making in the ongoing GTK+ 3.0 discussion.
(3) GTK+ has the advantage of C, meaning that it is easier to create new language bindings for it. However, the kross solution seems to work for Qt/KDE.
(4) It would be possible to create a Qt-ish wrapper around GTK+, and possibly a GTK+-ish wrapper around Qt, making most applications moveable between the frameworks. Back in 2004 I played around with a project I called Gt that was a Qt-ish wrapper around GTK+. My biggest problem was that I had to write a new moc, that problem does not apply when working in the opposite direction.
(5) There will be at least three types of desktops for X11 for quite some while. Light-weight (xfce), easy on the user (GNOME) and technically advanced (KDE). These desktops attract different people and thus will continue to co-exist regardless of framework used. Personally, I’m surprised that there isn’t a really big light-weight Qt-desktop around.
July 16th, 2008 at 5:15 pm
what about the long run ? imho it’ll just eventually happen…
on the other hand, we can’t even choose between spaces and tabs, so I would be tempted to ask about the point…what it is ?
July 16th, 2008 at 8:05 pm
A couple of things:
Qt is a pleasure to program with compared to Gtk(GObject).
Qt is scalable from embedded to desktop
Qt is going to be the main UI framework eventually for Symbian and no doubt Maemo.
July 16th, 2008 at 9:18 pm
@Sean,
Fanboying Qt really isn’t helpful or of any relevance to the discussion. One could say Nokia’s control of the platform means competitors will look elsewhere but that is all speculation.
July 17th, 2008 at 5:03 am
> (3) GTK+ has the advantage of C, meaning that
> it is easier to create new language bindings
> for it. However, the kross solution seems to
> work for Qt/KDE.
It being easier to make bindings for C is a complete myth. KDE currently supports:
* C++
* Python
* Ruby
Bindings for C# and PHP are nearly ready, and there’s also quite a bit of work done on supporting Javascript.
July 17th, 2008 at 11:26 pm
As a KDE developer I can say that moving KDE to GTK+ would fly like a lead brick in vacuum. Those are hard words but I think it’s the truth.
Qt is a good, consistent toolkit - in fact, after I have learned C++ (which admittedly takes some time) it doesn’t really bother me to write “medium level”(*) code anymore. Qt does not bother hackers with low-level details or long documentation reading much and you get RAII and other goodies from the language which can be very useful at times.
(*) Medium level code: in this case abstractions plus new details.
Sure, if resource usage is not an issue I prefer Python. But Qt/C++ are also a pleasure to program with *and* you can (can!) get good performance, too.
That being said, I have a lot of respect for C coders and low-level work. However, for some things it’s maybe just not the right fit.
The Gnome hackers could likely get more things done with Qt if they, say, don’t accidentally turn into zombies.
Full community control[*] and licenses -are- an issue and I admit that. Other people have talked about this in a more competent way.
[*] Actually, Trolltech will sometimes do a little something only for KDE. Not the same thing as Real Powah(TM) though.
Forget the red herring about bindings.
Just my thoughts. I’m not even sure if Gnome would actually gain something by adopting Qt due to the porting effort required and (tada!) it won’t happen anyway
Competition is also quite important, if only to make us listen to those damn users more, right?
Still wondering if this will yield a Nobel peace prize or the fanboy of the year award or “I can’t go to guademy 2009 ’cause the police cannot guarantee my safety”
See ya!
July 18th, 2008 at 9:46 am
@Andreas
Nice comment, thanks. I don’t think anyone is going to take a contract out on you based on your opinions
July 18th, 2008 at 7:50 pm
[…] John Palmieri explores the unlikely scenario of GNOME using Qt as its toolkit. […]
July 30th, 2008 at 3:48 pm
“the control of Qt by one entity in order to allow the ability to dual licensing is a put off for a lot of companies.”
Not for the companies that matter - the ISVs currently using Qt and paying for what they get out of it. Functionality and features are what primarily matter.
“The LGPL has allowed us to work with a lot of companies who have contributed back to the base platform.”
Unfortunately, they haven’t contributed code and functionality enough relative to other toolkits, and they certainly haven’t contributed what Gnome as a desktop needs from GTK.
“This is so not true I don’t know where to begin.”
It is true. It’s why you have such unbelievable things going on such as libsexy and libegg, and why application developers often copy and paste code into their own applications and then amend it to add the features that GTK currently lacks. That is just unadulterated………horror.
July 30th, 2008 at 4:13 pm
“Qt got it wrong by going out and producing yet another toolkit with flashy things added instead of rethinking what the platform of the future would be.”
That’s a loaded thing to say. They did look to the future, and they saw resolution independent devices and competitors doing more visually with the devices available to them. If rethinking the platform of the future consists of banging away on blogs back and forth with nothing being written, I don’t really want to hear about it.
“If we lost control we might not be able to move in the directions we would like to go. So in my opinion focusing on features would be the wrong reasons for choosing the switch.”
That, as Yoda might say, is why you fail. Features and functionality are why people use a particular desktop and a set of applications in the first place. It’s *the* reason to exist. If you’re sacrificing that central tenet for an idea of control then you’re never going to get anywhere.
Control is also a fallacy as well. Control is what has held GTK back. Currently, GTK development is controlled by a group of companies, newer ones such as Imendio, but especially Red Hat. Imendio is currently focusing on their own specific niche with no real care for Gnome at all, and Red Hat doesn’t want to put in the resources needed to update GTK because they see absolutely no return on investment in it - quite sensibly.
The question then becomes (deep breath), how do you create a return on investment to make the toolkit viable to put in the features and functionality needed to create the kind of desktop that you want and that people demand to get it to compete on a level with the proprietary alternatives you want to attract people off? You take all that into account and you come to a decision that the KDE developers made twelve years ago.
July 31st, 2008 at 10:28 am
@Segedunum:
I’m just going to leave it at your assessment of GTK+ (and tool kits in general) is wrong in many ways but not worth arguing because “I like my toolkit more than yours” is not really a productive line given the subject. If you want to debate the merits of why we need the LGPL then fine just leave the fanboying at home.
July 31st, 2008 at 11:55 am
“I’m just going to leave it at your assessment of GTK+ (and tool kits in general) is wrong in many ways but not worth arguing”
That’s your prerogative………..
“because “I like my toolkit more than yours” is not really a productive line given the subject.”
That’s not what was argued at all. You’ve been given an itemised list of what is currently wrong and what could be improved, and when you look at trying to compete against proprietary alternatives and convincing developers, and indirectly users, to use your software, some of them are *huge* problems that make any licensing and control issues pale into daft insignificance.
“If you want to debate the merits of why we need the LGPL then fine just leave the fanboying at home.”
It’s not fanboying, and I’ve itemised why worrying about the LGPL, everybody developing for ‘free’ and control have become insignificant problems when trying to keep up with the competition.
I’m be quite surprised if you weren’t upset a bit over that though.
Using the LGPL assumes that the software project is self-sustainable enough and has enough code going into it that ensures that it can keep up with the competition and the features demanded of it by developers and users indirectly. It also assumes that there is enough of an incentive for various people to contribute to it significantly to achieve that goal. Developing tools for developers to create applications for end users is probably one of the hardest things in software.
Unfortunately, GTK and Gnome’s other development tools just don’t have that and aren’t keeping up.
August 2nd, 2008 at 7:31 am
[…] [↩]cfr “Antonio Aloisio: Qt 4 Maemo: the new experience“ [↩]cfr “Flames Welcome (Is a Qt GNOME Desirable?)“ [↩]OOXML OpenSolaris Open source OpenSUSE Ottimizzare Oxygen PackageKit Parigi […]