Google To Replace GTK+ With Its Own Aura In Chrome 240
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?"
Re:Just for a browser? (Score:3, Informative)
Re: I'm with Google... (Score:2, Informative)
For starters, Aura isn't a fork of GTK.
Re:I'm with Google... (Score:5, Informative)
Qt? (Score:4, Informative)
"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.
Re:Qt? (Score:2, Informative)
Go look what industry software is written in, not just mobile crapware.
All the big player proprietary softwares are shipped with QT4 anymore. Automotive is also embracing it finally along with QNX... which I suspect will bleed back into smartphones if the market forces allow.
Re:Qt? (Score:2, Informative)
HTML5 + wrapper probably has as much, if not more, adoption.
Qt does provide a very convenient HTML5 wrapper, though. So that's not mutually exclusive.
directfb-lite and other webkit ports (Score:5, Informative)
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... [gnu.org] 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.
Re: As a Qt fan (Score:0, Informative)
Anonymous Coward
Re:Google's Aura (Score:5, Informative)
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... [chromium.org]
Re:Why care? (Score:4, Informative)
Firefox is an app that runs on XULRunner. XULRunner uses no native widgets, it has its own widget set and its own interface definition language, XUL. Firefox's entire user interface is written in XUL. The widget set in code is the same for OSX, Windows, Linux, Solaris, and whatever else it runs on.
The interface only looks different between windows and linux or mac because the default CSS theme for the application is auto detected and selected at startup so the widgets 'look and feel' native, but again - they aren't.
You can make the widgets look like any OS you want, make it act a lot like most other OSes as well, though some functionality is different such as the file open dialogs and such, which I guess you can count as 'widgets', which are actually native depending on OS/features.
At Mozilla, there is only XUL - http://www.mozilla.org/keymast... [mozilla.org]
Seriously though - http://en.wikipedia.org/wiki/X... [wikipedia.org]