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?"
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.
Double-post, but why is this in the news now? All of the linked design docs are from Dec 2011. This stuff is 2 years old.
It's going live now. The stuff has been experimental for that time, it's just now being pushed into Release builds.
Fun fact is that Aura is already enabled on Windows, this is why scrollbars, buttons, combos and everything else now looks like shit and are missing usability features that every other scrollbar on the system has.
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.
"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.
There is only XUL.
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?
I guess it depends whether their interest in it is limited to "we need something to write Chrome using, and GTK isn't doing it for us any more" or whether they will later be saying "come write apps for Chrome and ChromeOS using NaCl and Aura". Google has taken on their own UI stack -- is their only interest in it really to write just one application? If it is instead another step in the direction of encouraging developers to write apps that only work in Google's browser, that would be interesting to hear.
But I haven't looked into it closely.
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.
I'll let the AC explain what he thinks is wrong, if he will actually step up to the plate.
But, you do realize that this story starts with Timothy mentioning what a small percentage of the OS community thinks, and doesn't mention a somewhat more likely possibility - that Google is dissatisfied with the GTK, finds it very difficult to work within its limits, and doesn't feel it can get any cooperation from the GTK designers. If that is how Google feels, then the AC would probably say Google's position is reasonable. I tend to agree with that, myself. But, what's the point of asking the AC to defend his position, when that same position was totally left out of Timothy's original summary, and the position of those who don't see any problems with the GTK is presented as the default of the whole open source community?
Summary: Ooooohhhh! Anybody who doesn't like FOO is a rapist of dead baby seals and unmutual to boot! We're gonna just assume that absolutely everybody reasonable likes FOO, and raise only the questions those reasonable people would ask mean old unreasonable Google.
AC: Well I don't like FOO because it's smelly and might let girls into the Sekret club...
You: AC, you need to explain mo' betterer
Yes, AC probably should present some specific facts, if this was a debate over GTK's quality. But even if you turn this whole thread into a debate with the AC and others like him, win every point, and leave the rest of us impressed with your clarity and logical superiority, do you really think that will prove Google's reasons are as invalid as your debate opponent's?. The facts are, there is an ongoing debate o in the OS community over the conduct of the GTK developers. The summary needs to be written like the community is still seriously divided, not like the only questions being asked are from people who don't see a problem with the GTK and assume that Googgle can't really have a good reason.
Who is John Cabal?
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
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