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.
E-mail Print r 2   · Read More · 93 Comment(s)
Thread beginning with comment 349479
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

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:

- file picker:

- system tray:

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