|
Speaking as a Linux user, I don't think they have. Their use of and integration with the UI primitives of the GTK+ toolkit has been, well, primitive and unsatisfying, and Qt support is virtually non-existant (there was some porting done, but not enough to be anywhere near usable). However, even on OS X and Windows they don't use, say, native tab buttons. In fact, looking at the live demos I linked earlier, I don't think it's any more or less differenciated from each system's native style than the current design, purely in terms of for what elements it calls into that style for and for what elements it doesn't. As for Chrome, the sin Chrome commits on Linux in particular is that it defaults to something called client-side window decorations, that is it tells the window manager not to display the decorations it would normally put around the client area and then proceeds to draw its own inside this client area, which behave potentially vastly differently from whatever the user has configured for his native system decorations. This is less of a sin on Windows because client-side decorations are in some sense almost the norm there (and in the technical sense they in fact are). The new Firefox design still appears to avoid it on Chrome and thus is still better, though in fairness Chrome also offers the option to disable it. Let's face it, desktop Firefox has in fact never been using the native toolkit of the platform on any platform it supports in the conventional sense (reason for the desktop qualifier: I heard the Android version now intends to go native). Rather it uses its own UI toolkit that has a set of platform backends that call into native APIs to, say, grab a pixmap of a native element and then weaves that into its own rendering, which is very different from actually putting a native element on screen, since the original code implementing its behavior and the details of its rendering doesn't actually run[1]. Rather, any time Firefox makes something look native it's just a case of more or less close emulation. Now interestingly, this is not uncommon among browsers, especially in the document viewport: As far as I know, even MSHTML reimplements all of the form controls it embeds into websites by itself rather than use native Windows widgets, and for the longest time you could easily spot the differences in behavioral details. To my knowledge KHTML is the only browser engine which ever used (and still does use) native platform widgets directly. And in the case of Firefox, the Gecko engine powering the viewport also powers the browser chrome. This is one reason that you had number of semi-popular browsers embedding Gecko into chromes actually using native platform toolkits, like Camino on OS X and K-Meleon on Windows. 1 = Let me give a concrete technical example of why this is a problem. In KDE 4, our default style engine renders combination of radial and vertical gradients into the background of windows. Cf. this screenshot of a plain, empty window: http://www.eikehein.com/kde/window.png Now, KDE is based upon the Qt toolkit, and the traditional Linux platform backend of Firefox uses the GTK+ toolkit instead (as mentioned there are the beginnings of a Qt port, but it's not anywhere near useful yet). Obviously we prefer Qt over at KDE, but since application developers who chose differently have written some perfectly excellent applications using GTK+ and we believe users should be free to use them without suffering aesthetic consequences, we in fact sat down and wrote an essentially feature-equivalent, visually faithful and fully native GTK+ version of Oxygen. It's the most sophisticated style engine available for GTK+ today (in ways screenshots don't entirely do justice - there's e.g. tons of subtle transition animations in there you don't usually see in a GTK+ engine, say fading in focus rings). This makes actual, native GTK+ windows look just fine. Here's one and the same demo application written using three different toolkits, Qt 4, GTK+ 2 and GTK+ 3: http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAAAAk... Firefox however isn't a native GTK+ application, but instead just calls into GTK+ to let it render certain UI elements (or even only parts of them) into buffers it then uses as sort of raw materials in the painting of its own UI elements. And this abstraction over the native GTK+ is leaky, i.e. it suffers from limitations where Firefox' indirect use of GTK+ doesn't account for something a GTK+ style engine might be doing because it wasn't anticipated. And our gradient window backgrounds are where one of those limitations hits: Firefox doesn't ask GTK+ for the window background to draw into its own window. As a result, you don't get the gradient in a Firefox window using the Oxygen GTK+ style engine - and we even had to add a system to our window decoration to allow the special-casing of such windows to tick off the gradient in the deco as well, so you don't get a seam. This makes it look reasonably okay, but it's just not fully there: http://www.eikehein.com/kde/firefox-oxygen.png And let's not even talk about those transition animations ... or actually, let's, to pre-empt the counter-argument of them not being desirable in the first place: You can turn these off if you don't like them. The point is that by not actually using the native widget, Firefox is not in a position to follow the user's preference in the matter either. So, there you have it - here's the KDE guy in fact not complaining about Firefox not doing Qt, but actually doing GTK+ so poorly we can't make it fit even by embracing GTK+. Clearly it's not us not going the extra mile for integration :). |
