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.
Qt does a pretty good job of making sure its applications do not stand out graphically – or better put, it makes sure Gtk+ applications do not stand out in a Qt environment. It’s trivial to make sure Gtk+ and Qt applications mingle nicely without offending one another too much. The problem, however, is that beauty is only skin deep.
When I state that I do not like to mingle toolkits in Linux it has less to do with the graphical side of the coin – the behavioural part is far more important. Consistency in a graphical user interface isn’t merely a matter of using the same theme; it has much more to do with behaviour and layout.
And this is where the problems occur. In general, GNOME developers design the user interfaces of their Gtk+ applications different than how KDE developers design their Qt interfaces. KDE developers value choice, configurability, tweakability, whereas GNOME developers tend to work towards providing the necessities, and leaving out options that they deem confusing or pointless. This is of course a gross oversimplificiation, but the point remains. I’m not trying to say either approach is better – I’m just stating that they are different.
This difference in approach leads to differences in user interfaces. I can tell a Qt application apart from a Gtk+ one from three miles away – even if they replicated each other’s looks perfectly. They arrange their widgets differently, put common options in different places, use different widgets for similar options, and so on, and so forth. The end result is that I have to think about where to find stuff, and I don’t like that.
When I’m using a KDE environment, Gtk+ applications annoy me because they do not behave like the Qt applications I’m currently using. When I’m in a GNOME environment, it’s vice versa; it are the Qt applications that annoy me. This has nothing to do with placing blame or about what toolkit is better; when using environment A, I have certain expectations about where to find stuff – add in applications from environment B, and these expectations are of no use anymore. I find that frustrating.
I can already see several people firing up the comment box, ready to start off about how the situation on Windows isn’t much better – and they’d be right. However, that’s not a valid argument, and it’s totally irrelevant to this discussion. I find this problem just as annoying on Windows as I do on Linux, but at least Linux gives me the ability to stick to one toolkit and have a consistent desktop – whether that be Qt or Gtk+. Windows being a mess in this regard does not negate my problem.
Some people see the competing toolkits as a problem, but I really don’t. People who like consistency and the KDE approach, can stick to a strict Qt desktop, and people who like consistency and the GNOME approach can stick to a strict Gtk+ desktop. People who just don’t give a rat’s bum can use whatever they want. Everybody is happy!
Consistency is a concept that goes deeper than mere looks.
I am not going to comment on your post in general, but one think stuck out. You say:
Qt does a pretty good job of making sure its applications do not stand out graphically – or better put, it makes sure Gtk+ applications do not stand out in a Qt environment.
In my experience the opposite is true. Generally I think it’s the Qt-based applications that integrate better with gtk+ environments, especially given QGtkStyle, which I believe will be the default Qt style in GNOME starting with Qt 4.5.
The GTK-Qt theme engine does not work quite as well in my experience.
That’s why you use QtCurve, which uses a similar theme engine for both GTK+ and Qt and uses the same color and style settings for both. The apps really do look fairly similar. It can even change the ordering of buttons if you are somebody who is anal about that.
If you want desktop consistency get Etoil’e/gnustep. All the apps have that horizontal menubar, and they’re all designed to look/work like mac apps. GTK and kde both have too many apps that deviate from their UI specifications to ever fix the problem now.
Of course you’ll very quickly run into a situation where you need to do something which cannot be done with any of the available gnustep apps. Then you’re left with the choice of writing your own gnustep app, not doing what you where trying to do or accepting a foreign app on your desktop. The first two options won’t appleal to most people, and with the third you’ve all of a sudden lost your consistency.
So as much as I like what Etoile is doing it’s hardly a viable solution to the consistency problem.
The apps on my etoile don’t look or work much like mac apps, they look like NeXTStep apps. Is there some sort of mac skin or something available?
yeah there’s a horizontal menubar addon called EtoileWildMenus.
defaults write NSGlobalDomain
“/usr/GNUstep/System/Library/Bundles/Camaelon.themeEngine”,
“/usr/GNUstep/System/Library/Bundles/EtoileMenus.bundle”
to install it. There’s more information in their documentation. I’m building from svn at the moment but the bundles have been around for a while.
AFAIK there’s no actual mac theme that makes it look exactly like osx but I bet a decent theme artist could whip one up.
I will go as far as saying that etoile is expected to run with those modifications applied. Because they have released an application called EtoileMenuServer which basically recreates the entire mac bar. if you think of each app as making the DictionaryReader Edit Windows Services etc
menus. This program creates a bar that those menu entries are overlaid on top of, and that bar creates the “apple icon” menu (A star in etoile’s case). A screenshot is here:
http://etoileos.com/uploads/screenshots/etoile-0.4-starryreader.png
There is also an api for little menubar applets. There’s volume control, and calendar as well as battery meter and services so far. Personally I’m waiting on msn/icq and a webbrowser then I plan to make etoile my primary Desktop. I only really use the pc for msn/icq/irc/browser/music/videos. Normally I use mplayer or XBMC for video so I don’t need a player. Etoile has irc/e-mail/music so it won’t be long now. If I knew more about writing the backend of objective-c apps I’d develop my missing tools.
Edited 2009-02-16 15:23 UTC
And again the same old thing. I would really enjoy using GNUStep, with or without Étoilé, and I would surely take the time to dig into Objective-C to create the apps I need for it, if there was a Web Browser with it. There should be a massive campaign for the full port of WebKit (if I recall correctly, there’s an offering of help from the ones involved in WebKit to port it to GnuStep).
Unfortunately I am aware that I’m not skilled enough to do that, since I have no idea what goes behind a Web renderer engine and knows little about Obj-C.
But as soon as a Web browser were available, I’d jump on it and start working on small apps that could be useful, because it really fits the way I believe computers should be dealt with.
Once I was also quite interested in Gnustep & Etoile. I even learned ObjC and had some plans for a small project. But as a Desktop environment gnustep/Etoile is basically unusable: there is no webbrowser, KDE/Qt/Gnome/gtk applications do not integrate at all with gnustep. Instead of porting webkit, people want to code their own HTML rendering engine. Obviously that is o.k., because people are doing this in their spare-time and it is probably much more fun to code your own HTL rendering engine instead of porting an existing one. But as a potential gnustep user, I think it is totally wrong. There is no way to write something like webkit for such a small team as the gnustep/etoile people. Even the KDE people cannot create all the test-cases and do all the regression testing like Apple can. Instead of learning more ObjC I decided to write a small Qt/KDE application. I think Qt/KDE is quite nice from a programmer’s point of view. I do not have enough experience with Objective-C/Cocoa/gnustep to judge which framework is actually better.And actually I don’t care too much. I think KDE has a great community and KDE4 is moving forward quite fast and I am quite happy with it.
You’re right on the money with window devs stuffing up usability. Look at Caligari truespace version 1-6 and then look at version 7.
Talk about a step backwards.
There is a webbrowser coming to gnustep. There’s the webkit port which has a browser called Vespucci. I’ve run it and it does display websites albeit simple ones. Gnustep is purely lacking developer manpower. When it gets it it’ll become a decent platform.
Edited 2009-02-16 22:15 UTC
Gnome developers must think users are really dumb! Make no mistake, I am a Gnome user and I use Ubuntu as my daily development machine. But I still get annoyed by this.
Take a simple example: The screensaver in Gnome. You can select which screensaver you want, but you cannot configure the screensaver say to select which picture folder to use???!!! That is NOT an advanced option! Gnome users are not as useless as the Gnome developers make them out to be. It’s things like this that will drive me and others to switching to KDE base apps.
As for non-consistency between KDE and Gnome. That is purely due to Linux not having any standards when it comes to GUI applications. Every GUI toolkit vends for itself and users have to suffer. That’s just life under Linux. Until organizations like FreeDesktop.org etc can prescribe some GUI standards and toolkit developers start implementing, only then will things start to improve!
In the mean time OS’s like Windows and Mac that only have one GUI toolkit will be miles ahead in this regard!
Edited 2009-02-16 14:53 UTC
you’re kidding, right? …right?
http://en.wikipedia.org/wiki/List_of_widget_toolkits
(edited – added link)
Edited 2009-02-16 14:58 UTC
Just to be a devil’s advocate, you’ll find the a good many of them are no longer in active use by developers (outside purely for backwards compatibility). In reference to WPF, its debatable whether one could/should consider it a toolkit/widget kit given the different scope of its original intention.
That being said, what is needed in the *NIX world is a standardised HIG for both KDE and GNOME can subscribe to – and if they means that the GNOME HIG becomes the ‘HIG to rule them all’ then I say go ahead and make it so. The value proposition of whether a KDE or a GNOME application is good isn’t on the basis of how weird and different the application is. The value position is derived from how well the application is designed, how easy the tool it is when it comes to allowing the programmer to achieve a given task and ultimately how good the programmer is at turning his vision into a reality.
We’ve already seen this fixation in the Windows world of people focusing on how their application looks rather than how their applications work. How many have seen an application they used to love using only to find it has turned to crud because some developer thought it was neat to focus all their energy on buggering up the interface with skinning and gunk rather than improving the usability of the application and the speed of the underlying code.
I’ve gone off on a tangent already but I’m sure most here can see the situation which the software would has arrived in. When there are protests against standardisation – you know it has nothing to do with choice and everything to do with a noisy wheel annoyed that their butchering an application will no longer be considered as a valid reason for pushing an upgrade onto its users – be it open or closed source.
Edited 2009-02-16 21:20 UTC
No way. GNOME HIG sucks donkey balls. It was created by a bunch of developers who suddenly regarded themselves as usability experts after reading “The Inmates Are Running the Asylum”.
Here’s an example that illustrates how bad it is:
In Epiphany, the tab bar is at the top. This makes sense for a web browser. In GNOME Terminal, the tab bar is again at the top. This makes absolutely no sense for a terminal app. The HIG fails when it preaches consistency above senses.
Why not? Having it consistent with Firefox, Eclipse, and other tools works fine for me – I’ve never felt the need to find some way to change it.
First of all, it makes sense to have the tabbar on the bottom because the bottom is usually where you’re looking in a terminal. It’s more or less arbitrary in a browser, but the menus and such are at the top so the tabs might as well be there too (I’m sure there are a few more reasons to put them at the top). The menus argument is moot for terminals because you only look at the menus when you’re using your mouse to select them, which pretty much guarantees you’re not using the command prompt.
More importantly, the point of consistency is to make the apps easier to use (or if you prefer, usability is a better goal). If there is a compelling reason to make the app more usable at the cost of making it inconsistent in some way, usability should always win.
In Epiphany, the tab bar is at the top. This makes sense for a web browser. In GNOME Terminal, the tab bar is again at the top. This makes absolutely no sense for a terminal app. The HIG fails when it preaches consistency above senses
Umm, why would it make more sense for the tabs to be at bottom for a terminal app? I don’t understand. Atleast I find it consistent and easy if all apps have their tabs in the same place. What does it matter what the content of the tabs is when their functionality is still the same?
Just because you are used to having the tabs at bottom for terminal apps doesn’t mean it actually is better design or more consistent.
Umm, why would it make more sense for the tabs to be at bottom for a terminal app?
Because the user’s prompt and visual focus is at the very bottom of the terminal window 99% of the time on average (as long as you are in command line mode).
That’s pretty much different from a web browser or an editor where you start to read at the top as soon as you open a new Url and keep the text you are interested in about in the center of the viewport when scrolling.
So arranging the tabs at the bottom of the terminal window keeps the names of the sub windows within reach of your visual focus.
actually I did try kde for a while and I HATED the kterminal’s tabs being at the bottom. It really bugged the hell out of me. OSX and gnome both have the tabs at the top of the window.
Actually…
Right click, edit profile, select that tab called “tabs”, select tab bar position “above terminal displays” — and presto!
Not sure what the incantation was for KDE 3’s konsole, but it was equally possible. I always put the tabs on top, too.
“Because the user’s prompt and visual focus is at the very bottom of the terminal window 99% of the time on average (as long as you are in command line mode).”
good point and the same is also true with IRC apps. Note that the tabs in chatzilla (part of mozilla) are at the bottom.
The problem with the Gnome and it’s HIG is this:
If you can’t wrap your brain around the interface, you are not going to use it, because you cannot configure it to behave as you like it.
The Gnome HIG is not written for my brain, so I find it clumsy, unintuitive and uninformative.
People who think like the HIG – guys will of course have the opinion, that there is no better desktop than Gnome, because everything just fits for them.
An example:
Take the “File > save as” dialog. In KDE you get a tree view when you open the dialog, in Gnome, the only way to find out where the file will be saved, is to read the bread crumb line.
I am a person, who can take in the contents of a picture with ease, it takes me half a second of looking at the tree view, to find out where my file is going to get saved. Reading the breadcrumb view takes MUCH longer (for me!), so the Gnome dialog is a nightmare (for me!). I always have to click on the “file browser” button to get a somewhat retarded graphical representation of where the file is going to be saved.
I have 3 windows opened right now, Konsole, Opera, and VMware Server Console.
For Konsole, the tab bar is at the bottom (the default setting). Hopefully Torsten’s explanation has made you aware of why this is regarded by us as a better design, although “99% of the time” is definitely an understatement
For Opera, I place the tab “bar” at the left. This is because:
– I usually have 10-20 tabs opened. A horizontal tab bar doesn’t scale and will make it very difficult for me to identify one tab from another.
– I have a wide screen monitor (1280×800). Even if I only have 1 tab opened, I can afford the screen real estate needed by a vertical tab bar (about 160×700).
– I haven’t encountered any website that was designed specifically for wide screen anyway.
– Having it at the left gives me infinite depth to hit the scrollbar with a mouse click, compared to having it at the right.
Finally, for VMware Server Console, the tab bar is at the top (the default setting) when it is needed. Most of the time, I just hide it because I usually run one VM at a time.
So there, 3 different apps, 3 different usage patterns, and 3 different tab bar locations.
Edited 2009-02-17 15:49 UTC
Please show us where in the HIG ( http://library.gnome.org/devel/hig-book/stable/controls-notebooks.h… ) it says you have to put your tab bar at the top? It’s not much more than the Gtk+ default. In fact there’s an Epiphany extension to put tabs on the side.
You may or may not be right about the tab positioning, but don’t blame the HIG without backing it up.
How about this? http://library.gnome.org/devel/hig-book/stable/principles-consisten…
So, when there is no explicit guidelines, the Consistency principle says you shall HIGify your application so that it is consistent with other GNOME applications
And how about this? http://bugzilla.gnome.org/show_bug.cgi?id=75420
It is a bug that was opened 6+ years ago because the reporter wanted the tab bar at other location than the top. Incidentally, it was shot down immediately by none other than Havoc Pennington, the one who would then bring the holy book of “The Inmates Are Running the Asylum” to the world of GNOME (http://osdir.com/ml/gnome.usability/2002-12/msg00167.html).
And finally, here’s a cute one from Ubuntu’s Mark Shuttleworth: https://wiki.ubuntu.com/TabConsistency
The GNOME guys are working on adding some guidelines to the tab usage, and Mark’s document is being referenced by http://live.gnome.org/UsabilityProject/Whiteboard/TabImplementation…
Not at all. If you know anything about programming, you will see what I mean. Lets take the Windows example: Things like MFC, VCL etc are all wrappers for the underlying Windows API. Even .NET’s Windows Forms is just a wrapper for the stock standard Windows API. So yes, there is only one integrated GUI toolkit for Windows.
Compare that to Linux, where you can truly have 100’s of GUI toolkits, or none at all. The Linux kernel/core doesn’t come standard with a Linux GUI API, neither does X11 come with standard widget sets. X11 just managers windows, it knows nothing about buttons, comboboxes etc…
But getting back to the point. Being able to set a few custom properties of your selected screensaver is NOT beyond all users capabilities, so Gnome developers must not treat us like such dumb users!!
Ahh… you’re not kidding, you’re misinformed.
/Some/ of the ‘toolkits’ on Windows are wrappers around the standard win32 API, but not all or even most. You could argue just as well that GTK/QT/etc are all “wrappers” around xlib, because it’s just as true and just as irrelevant.
Based on the link you gave, I think you’ll find that from the list of frameworks listed for OSX, only one is still active… The other 3 were frameworks for OS 9 and below…
Carbon wasn’t listed however, but that is being phased out too, so on OS X currently there is only Cocoa from Snow Leopard onwards (some will argue you could still use Carbon, but it is limited in 64bit environments)…
You can use Gtk+ or Qt if you choose too, but they aren’t “Native”… You can use Swing for Java too (or SWT), Flash, Silverlight and I’m sure there are others too…
What is The One GUI toolkit under Windows? I can think of three off the top of my head, plus a bunch of wrappers around them offering various abstractions. Then there are all the different approaches developers take to make their apps look special and unique…
Saying that the situation under Windows is miles better than under Linux simply isn’t true.
Have you taken a look at Chrome on Windows yet?
It’s drawing its own blueish border with custom min/maximize/close buttons (Vista like, but still quite different) etc… None of the controls are/feel native.
.. that’s soooo annoying.
Well so I looked for a bug report in their issue tracker and found it, starred it, commented on it – it simply got CLOSED.
“But Office also has this Vista like custom UI…. And then Trillian is of course doing its own skinning.” – so what? It is damn annoying, change it!
Just take a look at this: http://chromium.googlecode.com/issues/attachment?aid=27634097853610…
It’s plain ugly!
.. and you’re complaining that the Linux port won’t have a native *feel*; OMG!
Edited 2009-02-16 14:54 UTC
Dear lord, you really missed the point, didn’t you? Read the article (which you clearly did not) and then comment again.
No I did not and I also don’t think that it’s irrelevant what I wrote.
“at least Linux gives me the ability to stick to one toolkit and have a consistent desktop”
And on Windows you can’t have a consistent desktop? You can’t run GTK+ or Qt or normal Windows applications only?
.. it just depends on the applications that are available.
What would you say if the Google guys used Qt but implement their own custom controls, frame decoration? That would be absolutely priceless.
Edited 2009-02-16 15:23 UTC
Oh come on, he does have a point… based on their bizarre interface in Windows, Google Chrome probably isn’t going to feel right in KDE *or* Gnome, so it’s hardly worth anyone getting up in arms about their choice of toolkit.
Apart from the fact that the poor sod completely missed the fact that you were talking about the issue of consistency, and not complaining about Chrome, it was a very relevant post.
That’s exactly what I meant. It will probably be more inconsistent with other Gtk apps than Qt <-> Gtk apps!
So even if you use the super ability to stick to one toolkit only it won’t give you a consistent desktop.
Exactly what point would this be when the application that kicked all this off is about as non-native on any platform as you can get? There’s a certain irony there.
There isn’t even a proposed solution in there, or at least one that will actually work, and it finishes off by saying that people can use what they want anyway. Choosing your applications via the toolkit that your desktop uses is going to leave you with precious little, and the vast majority just won’t do it so you’re in a minority.
I’d actually guess that people do choose their desktops based on the apps available and they do try to run pure environments as much as possible. I’ve seen a lot of people do that. most of the DEs have net/movies/music now so it’s not a problem for 90% of people. Probably half of the other 10% don’t care.
We aren’t talking about Chrome. Chrom ekickstarted the discussion on consistency – this article isn’t about Chrome at all.
But his underlying point is valid to the discussion. Just because all your apps use the same underlying toolkit is in now way a guarantee for a consistent experience. Chrome is just the illustrating example.
Chrome integrates very nicely into the Windows XP default theme, which is OK considering XP doesn’t support theming by defualt. You could argue about the merits of Chrome’s custom UI, but it definitely fits in with Windows XP vanilla (and Windows Vista vanilla).
All guis are the same, inconsistent. Just look at Windows. You have different widgets between apps. Some apps have floating menus, some have huge ribbons across the top. Some have most of the options hidden in pop up screens. There is no consistency anywhere. And really, do we need it? Are we willing to give up creativity and artistic license to appease people who just don’t want to think?
The goal isn’t to concentrate on your art, it is to concentrate on the user’s work.
If the application follows standard interface guidelines of the specific platform, many things can be done by reflex, without getting distracted by the app’s idiosyncracies. Example, since every app implements cut/copy/paste in the same way, (browser, text editor, photo manipulation, drawing app, IDE etc.), I can copy/paste text or images without having to search for the menu item/button and just use standard shortcuts.
I can change settings in the same way, I shouldn’t have to go searching for it. Saving a document, creating a new document, works more-or-less the same in most apps.
Just a few examples of a few standard conventions that make life easy for the user.
Edited 2009-02-16 16:14 UTC
It’s not about art, it’s about science. If you never evolve UI by experimenting with new conventions then you stagnate. Maybe the status quo is good enough for you, for everything, forever but I certainly don’t think so. Interface /guidelines/, where they serve to prevent needless specialized interfaces, are good things but where adherence to a standard becomes all important you lose all chance for innovation.
I don’t want creativity in an application interface and I don’t think anyone else does either! The novelty of a creative interface generally wears of rather quickly. A great example is Nero smart start on Windows. It’s the ugliest, most useless, gaudy interface I have ever seen. There are many other examples of this and it never enhances the usability of the application and personally I think it looks a lot worse than having a standard application that works with the rest of the desktop more seamlessly.
I do. Many great apps have a creative interface. Take the video composting app Shake for example. It has (at least had, I haven’t used the latest two versions) a very creative and unique interface. It is also, in my opinion by far the best and most easy to use compositor I’ve ever used.
Another example is Office 2007. I’ll admit i was mighty skeptical the first time I used. But I have to say that after getting used to it I really appreciate what they’ve done and I consider it a clear improvement over what went before.
There are also countless examples throughout the history of computing where a novel and creative approach to user interfaces have changed the way we interact with applications.
Now of course not all creative endeavors lead to something useful, but if we never try anything new we’ll never advance. New and creative may be unfamiliar, but unfamiliar doesn’t have to equate to bad (it obviously doesn’t have to equate to good either but I don’t think anyone is arguing that).
Shake’s interface could be done using native widgets and HIG conventions. There is nothing spectaculary different about it. I’m not arguing that there are not times when you need to stray from strict guidelines but unecessary non-standard widgets, and menus not only look out of place but make it much more difficult to transfer knowledge from application to application. Sometimes it’s just the little things that makes all the difference. For example I know that on any GNOME application I can go to Edit->Preferences to change preferences, but other applications have preferences under File, View, Tools, or some other menu location. I know what a button will do when I click it without additional text because icons are used across the system. The learning curve for a new application is much lower when you already have half the menus and buttons figured out the first time you launch it. If everyone decided that they have a better way to do it we would end up with thousands of applications that all worked differently and we would need to learn all the strange conventions of each individual program. No thanks. I’ll take a consistent toolkit and HIG over a whiz-bang solution any day of the week. Sure, there are downsides but I don’t have enough time and patience to re-adjust habits for every different application I use.
Which native widgets? Motif? Shake using native Motif widgets would not have been the same app. I realize we’re probably not going to agree on this, but suffice to say I think Shake made exactly the right choice going with their own UI widgets. Sure the file selector, for example, was different from the native one, but it was also far more flexible and powerful, something which very quickly made up for the few minutes you spent getting the hang of it. In fact if I was forced to name the app with the best UI I’ve ever used Shake would definitely be on the top three.
Sure for small utility apps like browser, mail, chat and text editor it is important that cut and paste works the same in all apps, but for apps like Shake internal ease of use is far more important than external consistency.
I’m not tyring to make the argument that Shake needs to use a different toolkit, just that a completely custom toolkit is not necessary and often confusing. You seem to by implying that it’s not possible to create an image compositor like Shake with a native toolkit like QT or GTK. I don’t buy it.
Sure you could re-implement Shake in Qt today, but Qt was a lot more primitive when Shake was written. Given the tools available, I think they did the right thing going with a custom toolkit. Would they have started today I doubt they would have made the same choice, but hopefully they would have kept the same UI and design.
Also by writing, for example, a custom file selector optimized for the job, rather than relying on the default platform one, they made the app a lot easier to use. Admittedly at the cost of it taking a few minutes to fully get the hang of, but in my book that is a tiny price to pay. Sometimes it’s worth writing a specialized widget to solve a specialized task. For large apps used in isolation I think harder to learn is worthwhile price to pay for easier to use.
I already said I’m not arguing for Shake to get a new UI. This doesn’t have anything to do with Shake specifically.
Hmmm. I did say that it is okay to stray from the conventions when it is needed but sticking as closely to them as possible makes thing a lot easier for an end-user. I’m not so stubborn as to expect strict guidelines that never can be broken but making something different for the sake of being different is not something we need.
And you’d be wrong. I want it. What now?
If by ‘creative interface’ you mean ‘glaringly ugly custom skinned crap’ then I agree. What you and other UI consistency wonks seem to forget is that all that is not consistent is not bad.
I /want/ the developer to offer the best UI for his application, I do /not/ want the developer to shoehorn his app into an existing convention just because it’s consistent. Consistency is not the be-all and end-all of interface design! Sometimes it makes /sense/ to not follow the guidelines, so you /should/.
“Are we willing to give up creativity and artistic license to appease people who just don’t want to think?”
Who has time to ‘think’ around a messed up GUI? Most people just want to get their work done faster, which is why computers were invented in the first place.
I’ve never understood this ‘use one toolkit and we will have brilliant consistency’ argument, and it is one that seems to be deeply rooted in the psyche of people who advocate GTK+ as the one ‘standard’ toolkit as if it’s somehow a given that merits no explanation. A cursory glance through Gnome’s ‘control panel’ shows applets that use instant apply and a close button and some that use a two button OK/Cancel method. There are GTK+ applications like this littered all over the place that simply don’t have a consistent, inherited core infrastructure to them. If you show that to a Windows developer he’s just going to laugh at you in disbelief. Consistency. What a laugh.
I’ve never been able to fathom what on Earth these arguments are based on, other than a hope that the limitations of GTK+ can be painted over and everything else will sort of, ‘go away’. It’s been going on for years and shows no signs of ending, despite the fact that Windows and Mac developers are not flocking to write applications for the platform and Windows and Mac users see nothing of consequence to make them move over, despite the hype.
The simple fact of the matter is that if you have lots applications written for your platform, which is actually what you want, then you get divergence in look, feel and developer technology that use ‘native’ look and feel to varying degrees. Even Mac OS has had this problem. The notion that we’re somehow going to be able to wave a magic wand and solve it in the open source platform world by mandating a ‘by fiat’ standard toolkit that can’t even help application developers out is a contagious, mental disease that seems to pervade an awful lot of people.
This attitude of some people trying to have some ‘pure’ one toolkit system will only leave you with fewer and fewer quality applications with the functionality that Windows and Mac users demand, now and in the future. Developers, developers, developers developers, applications, applications, applications, applications. That’s what you need if you want a desktop that actually does anything. It’s your funeral.
Religious attachment to one toolkit == no applications and no functionality. Take your pick.
Hmmmmm. Which platform there has all the applications people tend to want to use Thom? 🙂 How many Windows users do you think really care?
you’ll probably find the big boohaha over gtk+ being the one toolkit was it was the only lgpl licensed toolkit for ages and companies were too stingy to pay up to trolltech for the right to use QT. That probably has had more to do with gtk adoption than any other factor. KDE was first on the scene as far as I am aware, although the gnustep people have been claiming that gnome did look into gnustep as a possible api for gnome before they finally settled on gtk. btw to be fully disclosed, I am currently writing a 3d modelling app in gtk+ 2.0 ported from gtk+1.2. (it’s not easy to write apps in any language I’ve tried so far. (except vb but I didn’t like how vb worked anyway.))
Edited 2009-02-16 15:30 UTC
It’s one of the reasons given, but I’ve seen no Windows or Mac development companies getting interested in GTK+ because of the license. It was a really rather sad argument to make. It certainly lowers the barriers to entry, as it will with Qt, but picking up development tools out of interest and sticking with it are two different things. Maybe the Qt and KDE people aren’t quite so self-conscious, I don’t know.
Going back to the article, I just don’t see how you will attract applications, and henceforth users, to your desktop and platform by advocating the ‘one toolkit’ route. It just limits the functionality you have available on a platform that is absolutely crying out for applications and users.
If that’s true then they need their heads examined. With the right investment of people and time GNUStep could have been so much more.
Call it sad if you will, but QT license does get in the way;
We develop a suite of apps for our local investor community. We don’t charge for the software, but provide it as a means to accessing the exchange data which we do sell.
Our current target platform is Windows. Of course, the platform and libraries do come at a cost, but it’s a cost the customer is very willing to pay. They take it for granted.
Were we to adopt QT, we would have to charge a fee for each instance of our application suite; where our customers pay nothing right now, the QT app would cost them more than the Microsoft one- guess which one they would choose?
Conversely, our adopting the GTK allows us to continue to provide the app at zero cost to our client base; the choice is up to them whether they run Microsoft or Linux, without any cost implication.
I strongly suspect a similar reasoning for Google-Chrome.
Edited 2009-02-16 18:37 UTC
Hu? There is not, and have newer been a runtime cost for using Qt on windows/linux/mac
And with Qt4.5 qt uses the same license as Gtk
“Hu? There is not, and have newer been a runtime cost for using Qt on windows/linux/mac…”
What Lousewort implied was that Qt’s earlier (pre-Nokia) license would have required him to purchase a commercial Qt license which would have driven the end-user cost higher.
You are mistaken. Qt does not and has never had a runtime/distribution license. Once you own the toolkit you can distribute as many copies of your app as you want.
You could have even made it open source and used Qt free of charge (since you’re not charging for your software anyway).
This whole issue is in the past with the new Qt license anyway.
Yes, let’s sweep the nasty things that Trolltech has done in the past under the rug. And “All Hail Nokia!”.
What are you talking about? What nasty things are we sweeping under the rug?
When you have a clue what you’re talking about, and things called facts, give us a call. A royalty has never been a part of Qt’s licensing model. Only developer fees have, and the latest version 4.5 has now been relicensed under the LGPL so even that has gone.
I have had two civil responses already informing me as to my error. The tone of your response is arrogant, as if you cannot make mistakes. I would appreciate it if you would get off your high horse and join the rest of humanity.
Sorry, but given this:
It gives the impression that you’ve already done your research and come to your conclusion based on this. It just doesn’t come off as a genuine error.
Where did you actually read the above to make you think it was true?
Oh, believe me, it was a real error. I cannot recall where I got my information; I have been under a mistaken impression about QT’s license for a long long time.
Happily, I now stand corrected.
I have neglected even looking at QT as an option due to my previous belief that there was a per-seat license cost implication.
I think the real point I was trying to make is this:
The fact that customers already purchase the Microsoft GUI API/toolkit packaged with the OS makes it very hard for competitors to provide viable alternatives, even markedly better ones, at a price.
That’s the real price we pay for a Microsoft monopoly.
Another way of saying it is:
The reason alternative GUI toolkits have to be free (as in beer), is that the most used WIN32API GUI toolkit as provided by Microsoft is bundled with the operating system, and is already a sunk cost for the prospective customer base.
I would personally have preferred a free market system for GUI toolkits. We might have seen way more innovation. It is only right that people (other than Microsoft) are compensated for their labor.
Right now, obvious choices for cross platform GUI development are IMHO QT, GTK+ & Java. Each have their good & bad points. Others like Ultimate++ etc. just don’t make the grade.
I happen to like the GTK; not everything about it mind you- the model-view-controller approach in things like gtk_treeview/gtk_listview for example is just ridiculously and unnecessarily complex. I do like the ease with which it binds to C, or scripting languages though.
“I have neglected even looking at QT as an option due to my previous belief that there was a per-seat license cost implication.”
Don’t beat yourself up. For commercial development, up to just a couple months ago, there was a per seat charge for QT. QT has only very recently been released as LGPL. The fee was pretty steep as well, amounting to about $1500 per seat per platform. They offer 3 platforms, Windows, OS X, and Unix.
So that would be $4500 if you want to take advantage of the cross-platform feature, effectively encouraging devs, for many years, to write for the fewest number of platforms possible.
It occurs to me that after years of arguing that GPL was better, the QT advocates are suspiciously forceful, even gleeful, about pointing out the impending license change for 4.5.
Edited 2009-02-17 19:05 UTC
“So that would be $4500 if you want to take advantage of the cross-platform feature, effectively encouraging devs, for many years, to write for the fewest number of platforms possible.”
Exactly. It was a very expensive proposition for commercial software. Not my toolkit of choice for OSS, though I may look at it again now.
Many thanks. I understand now that this is a per-developer seat, which is sort of in the same price range as other dev toolsets. Steep, but probably reasonable. My previous understanding (prior correction) was that it was more like a royalty per customer.
Even so though, convincing a board of directors that we need to rig 20 developers at $1500 pers seat per platform
(or 1500*3 platforms*20 = $90 000),
they would go: “Are you nuts? how do you plan to recover those costs by not charging for your software? do you really need to target Max & Linux? why not just target WIN32 like you have for the past 15 years?”
I am very glad to hear QT has gone LGPL.
I have not followed this closely, but I don’t believe that QT 4.5 Final has been released. I think the first RC was released Feb 6 or so. So I do not think that it is LGPL yet.
…?
What exactly am I missing on my KDE desktop if I stick to Qt only? What am I missing on my GNOME desktop if I stick to Gtk+ only?
Edited 2009-02-16 15:40 UTC
You’re artificially limiting yourself.
I could list a bunch of apps, but for each app I’ll list you’ll no doubt name a different app which is similar as some sort of counter argument. And then we’d be stuck arguing over what you’re missing by choosing one over the other and start listing features the other app is missing and nobody would have any fun…But what the hell here goes
I like Eclipse for those times when I do Java development. Could I develop Java using a pure Qt or pure Gnome app, sure, but I’d miss Eclipse. There is one small example of what at least I would be missing by being a toolkit purist.
At the end of the day it’s a question of priorities. I have no problem running a Qt, gtk and even a motif app all at the same time if it means I have access to what I consider the most effective tools for the job at hand. What I lose in consistency I make up in efficiency.
On a KDE desktop you miss out on mainstay applications like Eclipse and Firefox because you refuse to touch anything that uses the ‘other toolkit’ in any way. Maybe we’ll have a great KDE WebKit browser, but we don’t. It means you miss out on applications like the Orca screen reader just because it doesn’t have a Qt/KDE front-end. If it means I get access to this functionality then I’m willing to put up with some ‘impure’ applications, and the majority are. I’d love them all to have Qt/KDE interfaces, and maybe they will, but it won’t stop me using them and me advocating a standard toolkit won’t change that. Maybe they could have made better development choices, but that’s up to them.
On a Gnome destktop you miss out on Amarok, the full suite of excellent edutainment applications with no parallel that Ubuntu amongst others have pitifully tried to rewrite for GTK at various points, DigiKam, TaskJuggler project management, KDissert mind mapping, BasKet, Rosegarden, KOffice (stuff like Kexi and Krita in particular), KMyMoney……. I’ve picked a few there that either have no parallel, or where their functionality has gone beyond that of pretty much anything else available.
If an application doesn’t work as well as you thought it did, why restrict yourself by not using something even if it is better? Users want to do stuff with their computers, that means functionality and that means applications. It trumps beautiful purity every time.
I take your points, but I do have to ask one thing about your examples, and yes, this question is OT. Exactly what would it matter if someone missed out on the Orca screen reader under KDE? It doesn’t work with QT apps at all, at least not yet, though work is being done on this and QGTKStyle might end up a good interim solution. So yes, you miss out on this program, but it hardly matters anyway, as currently it really does depend on APIs that only GNOME provides. If you have gotten it to work with QT or KDE somehow, please do share (pm me so as to not clutter this thread), I’d absolutely love to try KDE4 after everything I’ve been hearing about it.
Back to the topic, I’m of the opinion that UI consistency is a dream at best. Everyone, be they user, developer, or manager, has different ideas on what a good UI is. Even if one sticks to a single toolkit, you still don’t have consistency, just look through the majority of GNOME apps and you can see that.
By far, the most consistent UI at present seems to be OS X, and I mean consistent in behavior, not necessarily in looks. But even there, where Apple is extremely strict on UI guidelines, you don’t have 100% consistent interfaces. Just open the preferences of some of your favorite apps, odds are you’ll find some that don’t have ok/cancel buttons (they save your settings when the window is closed) and some that do. Actually, let’s simplify it: compare Apple Mail and iTunes preference dialogs. Enough said.
I stick to GTK+ apps on Linux, why? Not because I hate QT, or think GTK+ is any superior to it. I’ve programmed in GTK+ in several languages, I happen to really like C# and GTK#, but no one in their right mind would claim GTK+ in C is the cleanest of APIs. At the moment I stick to GTK+ and/or Java/Swing apps (SWT doesn’t count, as it bridges to GTK+ and therefore works)for one simple reason: nothing else works with Orca yet, except for a few exceptions–Firefox, Openoffice, and Mono Winforms-based apps of which there aren’t that many in Linux.
There are any number of reasons to stick to one toolkit, or not to do so, and it all comes down to personal preference. Simple as that. Attempting to force your choice on to someone else is akin to trying to persuade an evangelical Christian that you’re not interested in their religion. It’s not going to happen, and you’ll end up shouting yourself hoarse by the end of it. Isn’t that the beauty of choice? I do what suits me, you do what suits you, and everyone should just be happy with that.
It does with KDE 4 and Qt 4 because they support AT-SPI.
However, that’s not the point. This was an example. The point is that you’re limiting the applications available and limiting your functionality which will not expand the userbase for open source desktops. In addition, you’re also increasing the work of already stretched open source time, people and resources because you’re dictating that if an application exists it needs to have at least its front-end re-written. It’s just a bit daft really.
Edited 2009-02-17 14:34 UTC
There is no kile application in Gnome world. Gnome’s education suite pails in comparison to KDE’s. There is no k3b (and no brasero isn’t even close).
Exaille, Rhythmbox are not even close to Amarok. Konqueror and krusader kick ass as file managers. Nothing close on the gnome side.
On the Gnome side of the fence, kde doesn’t have anything close to G.R.A.M.P.S.
I could go on for hours, but if you are asking for interface purity, you will be missing on fundamental applications.
Very well said. All this talk about this subjective consistence on this or that platform is so out of reality, it would be made true if all you do is browse the internet, mess with your files on a file manager, watch your videos or listen your musics (right now not even on that), but just start to use some more serious applications and what? Kapout, so goes your dream of that holly consistence. I´m not saying that a minimum level can not be reached, but expect that all applications you use abide to your desire is just a kind of infantile dream that would impact severely the usefulness of non-trivial software.
If you can make the appearance of a QT app match then most of the consistency issues you mention boil down to developer inclination. Let’s assume a KDE developer went a little mad. The menu structure could be made to match Gnome’s style and structure. If the mood struck you would it be difficult to match GTK apps behavior in QT?
In the end it does not matter to me. I am one of those who do not give a rat’s butt about consistency. I honestly do not even notice differences in structure/choices anymore. Even the UI differences between KDE and Gnome apps seem no worse to me than the hodge podge of looks in OS X Tiger (which I do not mind either). Some apps more configurable, some less. Some are faster, others easier. Over time I just find what works and use it, regardless of toolkit.
I’m all for consistency but when it comes down to it I will always use the better tool for the job. I use XFce as my desktop environment but wouldn’t want to burn a CD with anything other than K3B. I used to use Azureus for downloading torrents (up till yesterday when I switched to rtorrent because it was replaced with Vuze in my package manager).
Arguing for consistency in a Linux distribution seems silly to me because half the stuff I use is on the command line and the other half graphical… how consistent is that? And then the consistency of command line programs is a whole ‘nother topic.
By the way, Verizon Wireless came out with a “consistent” UI for all their phones. If you get an LG, Motorola, or whatever, they load it up with their same software to make it look and feel consistent across various platforms. It sucks horribly.
I use some applications in english, and some applications in my native language. The web is full of non-consistant content. OSNews’ layout is far from that of slashdot and nobody see any problem with that. I can easily work with diversity and I have no problem switching from firefox to epiphany to dillo to lynx to opera. I multi-boot multiple distros and I find consistancy boring. I’ll adapt to chrome in GTK+ and I hope someone translate that to QT so I can switch when I feel like it.
First of all, what is the point about using native GUI libraries when the result does not integrate at all with the rest of the system? Just have a look at: http://winlux.pytalhost.de/tumblelog/upload/google-chrome.jpg. Google Chrome doesn’t look at all like other Windows applications.
And this is where the problems occur. In general, GNOME developers design the user interfaces of their Gtk+ applications different than how KDE developers design their Qt interfaces. KDE developers value choice, configurability, tweakability, whereas GNOME developers tend to work towards providing the necessities, and leaving out options that they deem confusing or pointless. This is of course a gross oversimplificiation, but the point remains. I’m not trying to say either approach is better – I’m just stating that they are different.
Firefox doesn’t care about the Gnome HIG and looking at the Windows Version I seriously doubt that Google Chrome will. I am quite sure you can make a KDE application look & feel more like a Gnome application then you can do with Firefox or Google Chrome. Gimp also doesn’t care much about the Gnome HIG, the interface is quite different from the usual Gnome applications.
When I’m using a KDE environment, Gtk+ applications annoy me because they do not behave like the Qt applications I’m currently using. When I’m in a GNOME environment, it’s vice versa; it are the Qt applications that annoy me. This has nothing to do with placing blame or about what toolkit is better; when using environment A, I have certain expectations about where to find stuff – add in applications from environment B, and these expectations are of no use anymore. I find that frustrating.
And just to mention it: MacOS X also uses two different styles. Actually I find that kind of refreshing.
ome people see the competing toolkits as a problem, but I really don’t. People who like consistency and the KDE approach, can stick to a strict Qt desktop, and people who like consistency and the GNOME approach can stick to a strict Gtk+ desktop. People who just don’t give a rat’s bum can use whatever they want. Everybody is happy!
At least for me applications are more important then GUI toolkits. I really don’t see a problem with using gimp or Firefox on my KDE desktop. I actually work with Linux, MacOS X and Windows and I had never had any problems switching between them.
And if Google Chrome integrates in Gnome as good as the Windows version integrates with the rest of Windows, your whole point is mood anyway.
Not really, because I use KDE, and so0 do a lot of other people. A lot of people use XFCE, or GnuStep, Enlightenment, there are a ton of DEs. Just like half the other posters here have said, Gnome integration is not Linux integration.
I think current Chrome-Win user interface is nice and fast. I think they did the right thing simplifying the UI. Its blue border is nice and it’s not that different from Windows applications when you access the options. KDE and GNOME experience are completely different – it is ‘DECLARED APARTHEID’. Something that has gone unclaimed in South Africa, but in the Caribbean for instance, it’s more alive than anything.
What? I think KDE and Gnome are actually quite similar. I use Windows, MacOS X and Linux regularly and in my opinion Windows, KDE and Gnome are quite similar. MacOS X needed some time getting used to it because of the menu bar on top and the concept that apps stay open even when the last window has been closed and Cmd- instead of Control-Key. I don’t get why people think KDE and Gnome are so different. Both are designed quite similar and if you don’t like the extra options KDE offers, just ignore them. Nobody forces you to use systemsettings to tweak everything. I ran KDE with all the default settings and I think it is quite o.k. No point in wasting time and modify stuff for the sake of it.
Good article, I agree completely.
GNOME and KDE are funny. I think they mirror OS X and Windows. OS X tend to simplify a little, and Windows tend to offer some choice.
GNOME/KDE take it to their respective extremes.
Despite GNOME’s crazy focus on simply GUI I quite like them – except when it’s missing that one function I want. *laughs*
IMHO this discussion is somewhat moot…
All the big distros have some sort of “inconsistancy” in this regard and even swap applications in their point release.
As example KUBUNTU comes with GTK+ (and more) preinstalled.
😛
Tom, please don’t entangle behavior, which is primarily driven by design (including HIG rules), and toolkits, which have little to do with behavior.
You could take every single GTK+ or GNOME app, port it to Qt and have it look and behave essentially exactly the same. All the toolkit does is provide a mechanism to implement design. And behavior is design.
Google’s choice of GTK+ is simple: The people doing the work are more familiar with GTK+. I can hardly beat up on them for that. However, these empty arguments about consistency and all that is apoplectic gum-smacking, plain and simple.
Lord knows I’d have preferred that they used Qt since it at least afforded the *possibility* of *visual* integration across desktop environments. *Behavioral* integration was never a nut they could comprehensively crack anyway. Besides, there’s already much *behavioral* inconsistency across apps within the same desktop environment on any OS. In fact, the behavioral paradigm Chrome introduces (no menubar, tabs as processes/windows/apps, etc.) is arguably as purposefully inconsistent as any app introduced on any platform. And I like it. And it anecdotally contradicts arguments that suggest behavioral consistency drives, or should drive, toolkit choice.
Is it really that hard for people to deal with more than one toolkit? When a dialogue box pops of with a different button order, do you instantly go into a state of shock and start drooling all over your keyboard?
This Qt vs GTK / KDE vs Gnome is getting RETARDED.
I can understand if there are interoperability issues, but it’s as if fans of one toolkit view the other as kryptonite that saps all their geeky computer powers away from them.
You’re all like a bunch of little old ladies bickering about how it’s such a sin to wear white after labor day. Maybe we should write to Miss Manners and see what she has to say about this…
Is it really that hard for people to deal with more than one toolkit? When a dialogue box pops of with a different button order, do you instantly go into a state of shock and start drooling all over your keyboard?
This Qt vs GTK / KDE vs Gnome is getting RETARDED.
I can understand if there are interoperability issues, but it’s as if fans of one toolkit view the other as kryptonite that saps all their geeky computer powers away from them.
You miss the point by a mile or few. As the article itself says, it doesn’t matter which toolkit is in use as long as all the applications look and feel consistent.
I for one am not specifically a fan of either GTK+ or Qt. GTK+ has several flaws I don’t like, and I have absolutely no Qt programming experience, so neither of them are the perfect choice for me. But it’s the look and feel of all the applications on my desktop that makes or breaks which apps get to stay on my computer. Qt apps on a GNOME desktop just feel out of place just as much as GTK+ apps feel out of place on a KDE desktop. The reason why I use GNOME as my desktop is because there are no Qt equivalents of all the apps I use, but there are GTK+ equivalents of all the Qt apps I’d use. It’s not because I like one toolkit over the other.
By the way.. I suggest you read the article next time and think about it a bit more. This article isn’t even specifically targetting GTK+ versus Qt, it could just as well be any other toolkits/desktop environments. The point is that many people dislike inconsistency, nothing else.
This is one of the few sensible reasons for preferring one over the other.
From my persepctive, the better applications are found more often for Qt rather than for GTK+.
By default, GTK+ applications look horrible under KDE (I think it is that horrible Raleigh theme), and KDE lacks decent support for making GTK+ applications look right.
I am looking at installing the standalone applet called lxappearance, I believe that this (in conjunction with some nice compatible themes such as qtcurve, gtk-kde4-oxygen-theme, gtk2-engines, gtk-smooth-themes, murrine-themes and Klearlooks) will fix this issue and help make GTK+ applications look very much at home on a KDE desktop. Anything but Raleigh, that has got to be the ugliest default theme ever.
http://wiki.lxde.org/en/LXAppearance
http://wiki.lxde.org/en/Image:LXappearance.png
http://en.wikipedia.org/wiki/LXDE#Components
This works by being a GUI editor for your local .gtkrc file if there is no GTK appearance deamon running.
(In fact it is probably a good idea to install the entire lxde-desktop package under Kubuntu, because all of its components are very lightweight and standalone, and it gives you a nice “emergency” alternative desktop if the full KDE desktop won’t start properly for whatever reason).
Interesting. Which areas do you feel lack Qt apps?
For me, GTK+ applications are lacking in the area of music collection browser/manager (not just a player), scanner, file manager and photo management. GTK+ applications often suffer from GNOME’s horrible file selection dialogs. GNOME has relatively poor support for clipboard management. And significantly, a few GNOME applications are Mono applications and not really straight GTK+ applications at all.
Having said that, even then, I still prefer GIMP over Krita (perhaps until Krita 2.0 becomes available, I don’t know), Synaptic over Adept, and Firefox over Konqueror (no contest here. Maybe one day there will be a useable Qt browser with webkit).
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.
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?
When I don’t have to deal with these stupid inconsistencies, unecessarily duplicated infrastructure, or missing functionality, then i’ll stop bothering, maybe.
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
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?
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.
stupid quotes… nevermind.
Edited 2009-02-17 12:32 UTC
Does consistency matter at all? Chrome does not need to be “consistent” in the way you mean. Besides most of the Google apps are not consistent on the windows platform toolkit-wise. Wait! The latest Office applications aren’t consistent either and finally Linux users don’t care about consistency ( unless you ask them of course 🙂 ) I guess the point I am trying to make is that you are right but you are right about something that (IMHO) isn’t important to the user at all.