Linked by Thom Holwerda on Mon 16th Feb 2009 14:07 UTC
Editorial Late last week we ran a story on how the Google Chrome team had decided to use Gtk+ as the graphical toolkit for the Linux version of the Chrome web browser. It was a story that caused some serious debate on a variety of aspects, but in this short editorial, I want to focus on one aspect that came forward: the longing for consistency. Several people in the thread stated they were happy with Google's choice for purely selfish reasons: they use only Gtk+ applications on their GNOME desktops. Several people chimed in to say that Qt integrates nicely in a Gtk+ environment. While that may be true from a graphical point of view, that really isn't my problem with mixing toolkits. The issue goes a lot deeper than that.
Thread beginning with comment 349410
To read all comments associated with this story, please click here.
Neither GTK+ or Qt are a platform
by IkeKrull on Tue 17th Feb 2009 02:50 UTC
IkeKrull
Member since:
2006-01-24

You can't print, get a file picker widget or integrate with the menu/system tray/desktop preferences etc. using either toolkit.

The whole GTK vs Qt thing is pointless because they're both only part of the picture, and simply don't provide enough platform functionality for a full featured app like a web browser.

I mean, firefox on linux has been around for years, and you still can't pick a helper application under GNOME without manually navigating through the incredibly obtuse dumping-ground of /usr/bin. Despite the fact theres a perfectly functional application chooser on the gnome launch menu.

Under KDE, you can't click a link in thunderbird and have it open in your preferred browser.

I havent checked lately, but apps like Eclipse probably still can't print because GTK+ 'doesn't do printing'.

You guys are sniping at each other over GTK vs Qt when the real problem is theres no standards for *anything* in the Linux desktop, and no matter how shiny you make the buttons and windows, until the 'platform' stuff, which exists quite apart from the widgets and window manager gets standardised and adopted cross-toolkit, consistency and usability on Linux will remain a joke.

Reply Score: 1

Delgarde Member since:
2008-08-19

I havent checked lately, but apps like Eclipse probably still can't print because GTK+ 'doesn't do printing'.


Was true once, but not for quite a while. Gtk+ has provided print integration for a few releases now (two, maybe three years ago?), and Eclipse supports it (not sure when support was added).

So if your criticism is that out of date, how about not bothering, maybe?

Reply Parent Score: 3

IkeKrull Member since:
2006-01-24

When I don't have to deal with these stupid inconsistencies, unecessarily duplicated infrastructure, or missing functionality, then i'll stop bothering, maybe.

Reply Parent Score: 1

anda_skoa Member since:
2005-07-07

You can't print, get a file picker widget or integrate with the menu/system tray/desktop preferences etc. using either toolkit.


I am pretty sure this is also wrong for GTK+, maybe someone with more experience in its API can provide the respective links.
It is definitely wrong for Qt

- printing: http://doc.trolltech.com/4.4/printing.html

- file picker: http://doc.trolltech.com/4.4/qfiledialog.html

- system tray: http://doc.trolltech.com/4.4/qsystemtrayicon.html


Under KDE, you can't click a link in thunderbird and have it open in your preferred browser.


Why would that not be possible?
Actually you can have that independent of the desktop environment currently managing the session.

Maybe your source of Thunderbird decided not to use xdg-open to make you suffer?


I havent checked lately, but apps like Eclipse probably still can't print because GTK+ 'doesn't do printing'.


Since real GTK+ applications have been capable of printing for ages, I'd rather guess that Eclipse's SWT did not make this accessible to the application developers and they, for whatever reason, decided that not to use their development stack's (Java) main printing facilities either.

Reply Parent Score: 2