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?"
As a Qt fan (Score:2)
Atleast Gtk+ isn't gaining.
Re: (Score:2)
Lots of adjectives. Explain what you yhink is wrong with it instead of just saying that you dont like it.
Re:As a Qt fan (Score:5, Insightful)
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.
Re: (Score:3)
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?
That is pure speculation. Google hasn't stated why they are switching, just that they are switching. A just as valid reason could be that since Aura's purpose is to produce a new desktop window manager and shell environment with modern capabilities. The UI must offer rich visuals, large-scale animated transitions and effects that can be produced only with the assistance of hardware acceleration., that it simply fits in better with their vision for Chromebooks or something they want to do with android. If y
Re: (Score:2, Funny)
Re: (Score:2)
Gtk is actually the best example of OOP in pure C I've ever seen. It still works great, lots of apps use it. Mostly, apps that don't bother advertising their toolkit because it is besides the point.
These fanboys should lay off the drugs. Toolkits are not the current fad, you get no style points for loving Qt in 2014. People even hate on the code, guaranteed if they had to find an actual example of bad code it would be their first time opening it up, and they'd eventually just point to some app that uses it.
Re: (Score:2)
Re: (Score:2)
I wouldn't say native-looking, but rather native-inspired. I'm using OS X occationally and it's very clear when an application is built with Qt. Things usually look almost native, but there's always some things here and there that's not right.
If you want native, build a native UI per platform and share common code between them.
Re: (Score:2)
wxWindows was a nice promise. I remember trying it out over a decade ago. And then again a few years later. The problem is, the code isn't written in a portable style; instead they try to bugfix their way to portability. So it often has trouble compiling. You can't just distribute a wxWindows app and have it work everywhere, for real, the way Gtk and Qt apps do. It will crash and burn for some percent of users; it will crash and burn if the compiler settings need to be adjusted; it will crash and burn just
Someone please explain (Score:4, Interesting)
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.
Re: (Score:2)
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.
Re:Someone please explain (Score:5, Interesting)
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.
Re: (Score:2)
"Looks like shit" is subjective. Personally I feel like Chrome "looks like shit" on Linux compared to Windows and Mac OSX where it has a consistent look. I am looking very much forward to this move. Like many nowadays I live in the browser and spend 95% of my time there. The more it is consistent across platforms the better. It doesn't matter nearly as much that my browser on Linux looks like my Eclipse as it does that my browser on Linux looks and behaves like my browser on Android or Windows or Mac.
Re: (Score:2)
Really?
I think that most people don't care about how Chrome works on multiple OS's because they only use one. And for that one, they prefer that app looks and works like apps for that platform.
And even the people that say, using Windows at work and MacOSX at home, probably would like the two versions to work similarly, but still look and feel like other apps for each specific platform, and not do shit like Adobe and try to make an AdobeOS app that happens to run on Mac or Windows.
Re:Someone please explain (Score:5, Interesting)
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.
Re: (Score:2)
When we're running apps, we inevitably end up with using at least one QT app, at least one GTK app and probably in future at least one Aura app. These libraries have a huge level of duplication (e.g. each one will have a completely separately implemented file dialog). Add to this that each library will be used in several incompatible versions and you end up with serious bloat.
That's true, but how much can that bloat amount to? 20 MB? 100 MB? It won't be much relevant for today's standards. Code duplication is what happens regularly in the closed source world, where applications ship with a private version of all the libraries they use, and not only for the UI - with few people complaining.
Ive gotten the impression that the GTK3 folks werent terribly interested in hearing other people's thoughts.
This sounds like a serious problem; do we have any proper evidence?
https://mail.gnome.org/archive... [gnome.org] - don't know if things have changed in the last two years.
Re: (Score:2)
To your points, it seems to me that one could argue that its only bloat if youre using QT and GTK and Aura, which many users will not. On the other hand, if someone made One Library to Rule Them All and it hit all of the requirements for all of the projects, that too would be bloat that everyone had to deal with.
And I kind of get the impression that Google is happy to donate to some things where they like the direction, but theyre not about to change their course to cater to or help out another project. I
It's gonna be fine (Score:4, Insightful)
Do Canonical? (Score:5, Insightful)
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.
Re: (Score:2)
no, no one has ever had anything to say about emacs vs. vim.
I am all for exploring solutions and like the linux community as a whole but let us not pretend that flame wars in FSF lands haven't started over less.
Re: (Score:2)
pico
Flame on!
Re: (Score:2)
I'm writing a text editor, the one text editor to rule them all. It's called femto. Everything you type is so small you can't see it. When you save the file, its size so small you can't see it in the directory listing! Its going to change the way we edit.
Why care? (Score:3)
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.
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]
Re: (Score:2)
I like it better on linux as I get the full "file edit view history.." menu per default.
It looks good in a GTK2 desktop if the system-wide icon theme is decent.
the worst thing with it is that I left myself open way too many tabs and keeping track of them is near impossible.
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:5, Insightful)
I came here to say this.
I'm quite the fan of Qt, but it's far from an industry standard. HTML5 + wrapper probably has as much, if not more, adoption.
And, once you use iOS or Android to dev GUI, some modern, convenient, and well-crafted patterns begin to emerge. They're not perfect, but they're nice to use. Honestly, if Google wants to use their own toolkit and publish it as open source, why should anyone complain about that? Some very interesting ideas may come out of it and be brought into other projects. Just as Mozilla's XUL was clearly aped for Microsoft's XAML, open source contributes to the field as a whole, not just one particular project. There's no need to lick the pizza with open source.
Only the ever-trolling slashdot community could turn Google releasing and dog-fooding an open source project into a bad thing.
Re: (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.
Re: (Score:2)
choice is good, but too much choice is bad - imagine if every project rolled its own GUI toolkit :(
Re: (Score:2)
Re: (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: (Score:3)
Perhaps not "industry standard", but it IS used by several proyects that dominate in their area, and several quite large (lage as in "with a large userbase") projects:
Skype, Vlc, Teamspeak, Origin, and lots more:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
"Couldn't Google just switch to Qt, which is becoming an industry standard?" It is? I haven't seen evidence of that.
On Windows, yes it is.
My employer, traditionally a very dedicated Microsoft toolchain Windows shop, is currently transitioning to Qt for GUIs. The only option MS really supports these days is .NET based, which means a closed-source vendor is forced to buy some expensive bytecode munging utility if they don't want their code reverse-engineerable back to its sources. Its also damned inconvenient if there's some reason your application needs to be "unmanaged".
Our alternatives are to go with way obsolete MFC
GTK+ is for GIMP!!! (Score:3)
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.
Re: (Score:2)
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 don't see how this is specific to GTK. If a program depends on newer versions of libraries, then you obviously need the newer libraries.
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.
But it's also for a lot of other projects. Gnome is largely based on GTK, and it's commonly used outside the Gnome project as well.
Re: (Score:2)
It's far worse than that because they deliberately broke their own naming convention to prevent the older software from running on a newer system and vice versa. They brought something like DLL Hell to linux for the first time.
Re: (Score:2)
dllhell has always been a problem, you just don't realize it because you hide the process behind a package manager and you update all of your software at once most of the time. Since the repos at the package manager get all the software working together and built, you don't see the problem. Its there. Someone else does it for you.
Generally doesn't work when you start using closed source apps on Linux, which people in the real world do.
Or when you need to use an old version of some software and the new ve
Re: (Score:2)
That is absolutely not the case. GTK+ started out as part of the Gimp project, but is now developed separately under the Gnome project.
Re: (Score:2)
Problem:
GNOME, an environment library is used by an application as well. If an older version of the environment is used, one cannot upgrade the application. Does that sound like a problem to you?
If GIMP were to do it right, it would make calls THROUGH the UI afforded by the OS and environment, not directly to libraries. But that's not what's happening. GNOME says "It's GTK, speak to the GTK people" GTK says "It's GIMP, speak to them." GIMP says "GNOME develops GTK now."
Someone is doing it wrong. And
Re: (Score:2)
At some point you just have to pick what you want to use. RHEL and its clones are intended to be a stable environment. 99+ % of users should be ok with the version of Gimp bundled with the system. Should the Gimp developers bend over backwards to support old enterprise systems? Maybe, but there would be a cost.
Re: (Score:2)
Those donkey fuckers managed to create something resembling DLL Hell on linux for the first time and made us all look bad.
ofcourse.. (Score:2)
Re: (Score:2)
People complain about Microsoft because they used closed proprietary non-standards software to cement a monopoly position that held back the industry for years. This is still causing problems now with the difficulty of ditching IE6/7/8 and XP and the fact that IE isn't compatible with their own software half the time. Google are nowhere near as bad.
Re: (Score:2)
Re: (Score:2)
I know you don't like Google but comparing any of their behaviour to Microsoft's is just crazy.
Why not build the Chrome UI as a web page? (Score:4, Funny)
Re: (Score:2)
Why do they need a GUI toolkit at all? Why don't they build the Chrome UI in HTML/JS/CSS?
I wish I had funny mod points!
Re: (Score:2)
Yeah.
Really funny [atom.io]
whoooshhhes (Score:2)
Why do they need a GUI toolkit at all? Why don't they build the Chrome UI in HTML/JS/CSS?
I wish I had funny mod points!
Yeah.
Really funny [atom.io]
Of all the whoooshhhes I've seen ... this is the biggest.
Re: (Score:2)
Most of it is going forward, if you read some of the links you'll see that very thing discussed, converting native widgets to WebUI where possible.
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: (Score:2)
Which version of Qt did you use? There were a few releases that focused on load-time speedups.
Have you tried it against Qt5? It should be 99% identical, the only change I know you need is to add widgets to the QT line, as Widgets are no longer the default application environment.
Re: (Score:2)
Which version of Qt did you use? There were a few releases that focused on load-time speedups.
Have you tried it against Qt5? It should be 99% identical
it was qt4.3 or thereabouts. the problem is that qt does far too much. when you think that lite 1.2 is around an 86k binary and qt4 and qt5 are several tens of *megabytes* you start to understand the extent of the problem. libQtCore is 3mbytes. libQtGui is 11mbytes.
now bear in mind that when you're doing something like a web browser, all you really need is a font and pixel drawing system (cairo, pango), an input box (liblite), a way to read the keyboard and mouse, and err... it really ain't that complic
Re: (Score:3)
ls -altr /usr/local/lib/*lite* /usr/local/lib/liblite.so.3 -> liblite.so.3.0.5 /usr/local/lib/liblite.so -> liblite.so.3.0.5 /usr/local/lib/liblite.la /usr/local/lib/liblite.so.3.0.5
lrwxrwxrwx 1 root staff 16 Dec 7 2010
lrwxrwxrwx 1 root staff 16 Dec 7 2010
-rwxr-xr-x 1 root staff 928 Dec 7 2010
-rwxr-xr-x 1 root staff 48848 May 3 2011
i'm sorry - that's 48k not 86k!! liblite is *tiny*.
Re: (Score:2)
Which version of Qt did you use? There were a few releases that focused on load-time speedups.
Compared with the startup time reported (90s!) even a 10x speedup would leave it being SLOW.
Actually, it sounds like something is critically misconfigured; I can't imagine any situation where a 90s startup is acceptable. Well, not in the last 20 years. (I remember using LispWorks when I started waaay back, and that had that sort of startup time. I dropped that commercial system for a lightweight open source solution and never looked back.)
Re: (Score:2)
Thank you
Re: (Score:2)
If not just run multiple browser windows using multiple virtual consoles, Alt-F1 Alt-F2 etc switches back and forth. You could have chrome in one terminal, bitchX in the next, editor of choice in the third, and so on.
Google should take note ... (Score:2)
Re: (Score:3, Informative)
Re: (Score:3)
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.
Re: (Score:2, Funny)
It is now (LGPL). Time to move back?
Re: (Score:3)
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")
Re:Just for a browser? (Score:5, Funny)
There is only XUL [mozilla.org].
Re: (Score:3, Insightful)
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
Re: (Score:2)
I agree with most of your points, and I don't use Chrome, or chromium, but I disagree here:
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.
I think this is actually a good thing sort of. The cross compatibility should come from good, implementable open standards, not a single open source renderer. It was beginning to get to the stage where Webkit was getting so dominant that it was looking to a return to the ba
Re: (Score:2)
I'm assuming webkit and blink will diverge. And isn't trident what IE uses?
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2)
"Well, it used to be that Android was basically a linux distro."
No, it really never was. Because when you say a linux distro what you are actually thinking of is a GNU distro, and android never attempted that at all. It's always been it's own wierd little proprietary linux offshoot and I guess it's nice that people are starting to see it that way, but it's silly to pretend it's a change, it was this way from the start.
Re: (Score:2)
I agree with you but not for the same reason: my reason is a variant on 'cannot get the basics right': Chrome is not pleasant to use at all on a 4GB RAM PC, it use too much memory which make the PC swap..
I used to prefer Chrome to Firefox, due to its snapiness, good separation between tab, but when it used frequently so much memory as to make the PC swap, I switched back to Firefox.
Re: (Score:3)
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... [google.com]
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'r
Re: (Score:2)
It has been "in progress" for so long that stationary might be a better term.
Did you look at the link? The last update was in January, and described the current status as depending only on one other piece to be ready for launch.
I see. I wouldn't be surprised if this is the root of the problem. They have conflated a web-browser with an OS. No good will come from it except an unfocussed bloated browser and an anaemic OS.
I can see you've never used it.
Re: (Score:2)
That, to the best of my understanding, is what confuses people: Qt is generally considered superior to
Re: Just for a browser? (Score:3)
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
Re: (Score:3, Interesting)
Re: (Score:3)
You don't need to run Gnome to run GTK 3. I'm using it right now on just fvwm.
Re: (Score:3)
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... [gnome.org]
Re: (Score:3)
I don't see anything Gnome-related in that list that I didn't mention.
Re: (Score:2)
I agree on this point, but, what about Qt? Qt is superior to gtk in almost every way, cross platform, and not "bound" to anything. Plus, the license is pretty liberal.
Re:Just for a browser? (Score:5, Interesting)
Re: (Score:2)
The could have just used SWIG like the rest of the planet.
Re: (Score:2)
Re: (Score:2)
The C++ mentality is that you should catch as many errors as you can at compile time.
No, the Haskell mentality is that you should catch as many errors as you can at compile time (stopping only barely short of executing the whole program at compile time during the type checking :-)). The C++ mentality is that you should improve C in incremental steps without breaking much of compatibility both in terms of source code and ABI (so that you could easily reuse legacy code), until it becomes either bearable, language-feature-wise, or horribly complex, programmer-experience-wise, and ideally both.
Re: (Score:2)
Wrong. GTK+ did their weird object system because it's in C, not C++.
Yes, they did. And they also had a number of other reasons. Most of which perhaps disappeared in time, but not all of them.
Reflection isn't a factor
Sure, if you're happy to be forced to recompile all binding libraries, generate new packages and force hundreds of thousands of people to upgrade them whenever the interfaces change instead of just upgrading Gtk+.
and as a C++ programmer I don't feel like I'm missing anything without it.
Oh wait, you're C++ programmer. Of course, in that case your brain is already so horribly damaged that you can't perceive the comparatively mild benefits this would bring to a
Re:I'm with Google... (Score:5, Insightful)
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 [google.com].
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.
If Linus would just endorse a toolkit... (Score:2)
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 [google.com].
If Linus would just endorse a toolkit, then there would be One True Toolkit; this would be the most likely thing to drive an actual "Linux desktop revolution". I am not holding my breath.
Re: (Score:2)
If Linus would just endorse a toolkit, then there would be One True Toolkit; this would be the most likely thing to drive an actual "Linux desktop revolution". I am not holding my breath.
And that's why he won't. The whole point is to avoid homogeneity, because homogeneity strangles progress and provides a single target for the spread of malware.
Re: (Score:2)
AFAIKT Aura is a more than just a UI Toolkit, it's a complete Window Manager.
You are aware, that - at least in sane computer system designs [swtch.com] - this is mostly the same thing?
Re: (Score:2)
Re:I'm with Google... (Score:5, Informative)
Re: (Score:2)
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
For starters, Aura isn't a fork of GTK.
Re:behind the aura, behind the aura, behind the au (Score:4, Funny)
Google Chrome also uses Blink-182.
Woo hoo! So they lie and they're easy?
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: (Score:2)
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.
Re:Google's Aura (Score:5, Insightful)
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!
Re: (Score:3)
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.
Re: (Score:2)
The incompetent lawyers hire the additional incompetent lawyers. It was hell just getting our lawyers to understand that ftping source over the network through open source routers and servers did not make the transmitted code open source. The name LGPL needs to be changed so that the letters "GPL" does not appear in the acronym. Our lawyers screech, "GPL! GPL!" "Uh no, it's LGPL" "But it's GPL!" Our lawyers are fine with the BSD license so maybe we can call it the LBSD license. :-)
Our lawyers, quashi