Slashdot Mirror
Google To Replace GTK+ With Its Own Aura In Chrome
sfcrazy writes "Google's Chromium team is working on an alternative of Gtk+ for the browser, called Aura. Elliot Glaysher, a Google developer explains, 'We aim to launch the Aura graphics stack on Linux in M35. Aura is a cross-platform graphics system, and the Aura frontend will replace the current GTK+ frontend.' The Free Software community is debating: is Google trying to do Canonical? Couldn't Google just switch to Qt, which is becoming an industry standard?"
Atleast Gtk+ isn't gaining.
Why it really matters whether Google uses QT or GTK or their own stack. I mean for a GDE or distro like Ubuntu, I can see that "make another one" matters because it impacts all sorts of other projects. For Chrome, though, it doesnt really affect anyone else that I can see, and its really just Gnome folks being upset that Google didnt want to use their stack. At the end of the day, isnt it just more work for Google? If theyre happy to do it, who cares?
And-- though Im not privy to all of the politics-- Ive gotten the impression that the GTK3 folks werent terribly interested in hearing other people's thoughts.
Qt is my golden standard too, but in case of Chrome, it does not matter much. Go with "Aura" if it makes them happy. I mean, how many UI widgets do you see in Chrome anyway? There's the tab bar, pop-up menu, and some little popup thingies here and there. Everything else is a web page, which is rendered with its own engine.
The reason why Gtk was written is because at the time that GIMP was starting out, there wasn't a good alternative. Nowdays there are.
And then again, why should anyone have a say on what toolkit Google decide to use for their own browser? Did "the Free Software Community" have anything to say when it was slang vs ncurses, emacs vs vim, gtk vs qt, gnome vs kde? No, because exploring alternate solutions is good for the whole community in the long run. Please stop this poisonous attitude of finding "enemies of the people" among people who dare write free software.
Because GTK2 is bit-rotting and GTK3 is bound to GNOME.
For starters, Aura isn't a fork of GTK.
Reading through the documents, it doesn't look like a trivial task to recompile all your GTK-2 apps against it. From the UI Toolkit standpoint, it looks like a combination of NextStep and Swing.
AFAIKT Aura is a more than just a UI Toolkit, it's a complete Window Manager. A replacement for Gnome (wow! I hope that takes off!) Apparently it's been running on the Chromebooks. Here is Linus' take on the topic.
The main reason I would be reticent to use it is because Google doesn't always have a strong commitment to backwards compatibility. So you may end up having to rewrite pieces of your code, just to keep them compiling. If you're ok with that though, go for it.
"First they came for the slanderers and i said nothing."
GTK+ 3 is LGPLv2, not GPLv3; it is not developed by the FSF, and never has been. And the GPLv3 is arguably more friendly for businesses than the GPLv2, with its explicit patent provisions, the lack of the termination provision, and the explicit system libraries exception.
Google Chrome also uses Blink-182.
Woo hoo! So they lie and they're easy?
If I remember correct the Gimp guys had started with Motif. Early versions of Gtk+ was more or less a non-strict reimplementation of Motif, but that changed quite rapidly after a while.
To be honest i see this more as a feature than as a problem.
This will very likely improve the quality of the linux build making it more complete and compatible with the windows build and features.
Just compare the linux and windows versions of firefox for example.
They look far from the same.
And for a big part this is caused by the difference in toolkits used beneath the skin.
Now i am a big fan of QT.
But even if they port their own: one toolkit everywhere can only make things better.
"Couldn't Google just switch to Qt, which is becoming an industry standard?"
It is? I haven't seen evidence of that. Trolltech/Digia have been working on that for a long time, and have in fact gained significant market share, but I don't see many projects outside of the KDE sphere of influence or very specific embedded platforms adopting Qt. In fact, the popularity of entirely new mobile platforms that did not adopt Qt is a great counter-argument (i.e. iOS, Android, ChromeOS).
Mind you, that's no argument against using Qt - I just don't see evidence of it becoming an industry standard.
Every use of GTK outside of GIMP is a problem. Try running the latest CentOS with GNOME and see if you can run a newer GIMP. You can't. You will have to do all manner of things and you still will not get 100%.
I have discussed this topic with GTK, GIMP and GNOME projects and at the end of the day it comes back to GIMP/GTK developers. They say GTK is for GIMP. So every developer out there would be well advised not to use GTK any longer.
There is only XUL.
IIRC Gtk was written because there was a high-quality alternative but that wasn't free and open.
Years later Trolltech released Qt under the LGPL and suddenly there is no longer any need for Gtk (or other toolkits written it seems just to be a bit "special")
You don't need to run Gnome to run GTK 3. I'm using it right now on just fvwm.
It is now (LGPL). Time to move back?
From previous releases its clearly the Chrome team is being mismanaged and has lost its way.
They really cannot get the basics right. A web browser is basically text in windows that can be styled by the page author. Lets see you they are doing:
i) They don't fix the appalling font rendering issues on Windows promptly and as a priority. Most of Google's own web fonts are unusable in production because of this.
ii) They don't follow standard most-recently-used order when ctrl-tab between tabs and they don't see the problem and close any bug report as won't fix. How can Chrome be the platform for office tools and applications when you can't flick between applications?
iii) They start adding animations to html elements you can't restyle with CSS e.g. the zoom ease-in they added to select elements in a recent Chrome. What possible justification was there for that? If you need to use more than a couple select elements on a form the animation effect of using each one is terrible.
iv) They add forced behind the scenes updates (ok) but they then push poorly tested unstable releases. There were wide-spread issues on their recent releases. You can only auto-update if you are rock-solid.
v) They fork from the web-kit project, a once high-point in cross company collaboration for the betterment of the web. Now... beginning of the end.
vi) And now they are going to spend their time re-implementing a cross-platform widget toolkit. How about fixing the fucking font rendering first?
I don't know how the team is being led but it can't be right. Google, time to take an axe to your chrome team...
Why do they need a GUI toolkit at all? Why don't they build the Chrome UI in HTML/JS/CSS?
i've worked with webkit a *lot*. for example, i helped denis with the port of webkit to directfb. in doing the python-webkit (direct) bindings http://www.gnu.org/software/py... i covered a *lot* of different ports of webkit. here's the summary:
* when compiling the standard webkit to run on a 400mhz ARM9, the gtk port started up in around... i think it was somewhere around 8 seconds. this was tolerable. it used about 130mb of memory to load a single basic page.
* when compiling the DirectFB port to run on the same system, it started up in about 3 to 4 seconds, and used about 1 or 2mb less memory. this was great!
* when compiling the Qt4 port to run on the same system, it took NINETY SECONDS to start up, consumed DOUBLE the amount of memory, and was basically completely intolerable.
the directfb port basically used an older (revision 1.2) version of the lite toolkit. to say it's light-weight would be an understatement: it's absolutely awesome. qt4 has unfortunately turned into a bit of a monster. gtk by comparison has remained reasonably level-headed, and when it (finally!) has the equivalence of COM's co-classes added to the gobject introspection layer gtk will become highly significant, strategically.
the only thing that the directfb-lite port lacked (at the time i was involved) was a window manager. this basically meant that you could only have one browser window open, and you had a callback for dealing with console alerts, which you had to then deal with yourself. i _thought_ about doing the same trick that mozilla does (which is most clearly demonstrated in b2g) - namely to implement the windowing system *in* webkit itself, in a high-level language: that would be cool. not many people are aware that firefox's menus including the toolbars and tabs are actually implemented *in javascript* (!), and the main browser "window" is merely a (secure) frame. b2g is an extension of that.
so anyway, the point is: there are lots of ways this can be achieved. you can implement the window manager externally and treat the browser as an isolated "component". you can go the other route and implement the window manager *using* the browser engine. but the main point is that either way, gtk and qt4 are to be honest complete overkill. it's only when you have things like co-classes built-in to the underlying infrastructure (like COM has) that you get any _real_ flexible benefit from the widget set, and as neither gtk nor qt4 have those, there's honestly really no point having them around.
Except that this "standard C++" is total crap that doesn' even offer proper reflection, which is the whole reason why Gtk+ went on to create this "weird kitchen sink object system" (so that creating the bindings to all the dozens of different languages used in a typical Un*x system were as simple as possible). And why - wonder of wonders - Qt did the same, to improve this "object shitstem" of C++. I think a discerning observer might start seeing a pattern at this point...
Ezekiel 23:20
You need lots from GNOME project to get GTK3
Can you be more specific? GTK+ does not have a lot of dependencies to begin with, and most of them is not directly related to the Gnome project; GLib, GdkPixbuf, Pango, ATK and GObject according to the documentation [0]. The rest of them are external.
[0] https://developer.gnome.org/gt...
Qt has a lot of overhead that can be useful for writing desktop apps but requires extra work for a web browser. Qt wants all apps to be web apps, except you get your "choice" whether to write layout and logic in Qt Quick, C++ or overhead-added HTML; this gives you some degree of interop with the other two, but web browsers don't need that or the overhead it brings. Qt also pointlessly reinvented lots of the C++ standard -- witness QString and all their container classes -- making it hard to integrate with libraries written in non-Qt C++. People who use Qt are mostly allowing themselves to be locked in to a dead vendor's proprietary library.
Is looking darker and darker every year
Actually, Aura has been part of the Chromium project for quite some time, so it isn't any darker today, than it was yesterday, or even last year or two. Most likely, this has more to do with ChromiumOS than Chromium/Chrome.
Here's the link: http://www.chromium.org/develo...
QT with LGPL could be used freely by google... maybe the problem is control... they could not control GTK and may have fear that QT could neither be controlled by then... Or is just another NIH attack!
Higuita
i) They don't fix the appalling font rendering issues on Windows promptly and as a priority. Most of Google's own web fonts are unusable in production because of this.
I haven't used Windows since about 2000, so I have no comment on this. I will point out that it appears work is in progress: https://code.google.com/p/chro...
ii) They don't follow standard most-recently-used order when ctrl-tab between tabs and they don't see the problem and close any bug report as won't fix.
I disagree with this one. The Chrome tab ordering is better. most-recently-used sucks when you have 20 tabs and have bounced around between them somewhat randomly (as is normal). It makes ctrl-tab completely unpredictable unless you're just jumping back one or two levels. The Chrome way is better.
iii) They start adding animations to html elements you can't restyle with CSS e.g. the zoom ease-in they added to select elements in a recent Chrome.
Got a link to more information? I'm not sure what you're referring to.
There were wide-spread issues on their recent releases. You can only auto-update if you are rock-solid.
Link? I certainly never noticed any issues, but perhaps that's -- again -- because I don't use Windows.
v) They fork from the web-kit project, a once high-point in cross company collaboration for the betterment of the web. Now... beginning of the end.
Nonsense. There is still cross-collaboration between Blink and Webkit, and Google isn't the only company working on Blink.
I also fundamentally disagree with the common /. meme that forks are bad. There is this mistaken notion that having all of the developers interested in a certain space collaborating on one implementation will improve the pace of development, but that view ignores the fact that software engineering isn't like ditch-digging; with software there are definitely diminishing returns on larger and larger collaborative groups, particularly if the software isn't of a sort that lends itself to crisp, well-separated modules. In practice, we tend to find that with sufficiently-important spaces (e.g. web browsers) the ecosystem is better-served by friendly competition among open source projects. That reduces the amount of inter-group communication needed to reach consensus on approaches and therefore increases the speed of iteration. The fact that all are open source means that when one project implements a great new idea the others can see the details of the implementation and more easily incorporate the idea, even if they can't actually use the implementation.
I think the "we should all work on one implementation" theory has basically the same merits as the old Soviet one-gigantic-factory model for production of goods. On the face of it one would think that producing many different designs for one type of product and then building all of them in separate production facilities, distributed through different distribution networks, etc., is very inefficient. One design, one huge factory to maximize economies of scale should be better, right? But history showed that the opposite is true, that a competitive market produces more goods, better goods and does it at a lower cost. The issues in software are different, but at a high level the emergent properties are similar.
vi) And now they are going to spend their time re-implementing a cross-platform widget toolkit.
They already implemented it. It's been used in ChromeOS for a while. My guess is that they've decided it will take less engineer effort to port and maintain Aura than to keep up with Gtk+. I also wouldn't be surprised if a goal isn't to remove some unused cruft from Chrome on platforms (like Windows) that don't tend to have Gtk+ libs lying around. I doubt Chrome uses more than a tiny fraction of the Gtk+ functionality.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
People on Slashdot keep saying this, but corporate lawyers see "GPL" in "LGPL" and flat out say "no way."
Maybe those corporations should hire actual lawyers instead of corporate lawyers.
No colour or religion ever stopped the bullet from a gun
I don't see anything Gnome-related in that list that I didn't mention.
God forbid someone make an on-topic reply to a joke. Noooo we can't have that, anything on topic after a joke *must* be whooshed.
I hate printers.