A major complaint about Google’s Chrome web browser has been that so far, it is still not available on anything other than Windows. Google promised to deliver Chrome to Mac OS X and Linux as well, but as it turns out, this is a little harder than they anticipated, Ben Goodger, Google’s Chrome interface lead, has explained in an email. It has also been revealed what toolkit the Linux version of Chrome will use: Gtk+.
The decision to use native user interface toolkits on each platform has made it all the more difficult to deliver the Mac and Linux versions of Chrome. Several people wondered why Google didn’t just use Qt from the get-go, which would’ve made the whole process a whole lot easier. Goodger explains that Google “[avoids] cross platform UI toolkits because while they may offer what superficially appears to be a quick path to native looking UI on a variety of target platforms, once you go a bit deeper it turns out to be a bit more problematic.” Your applications end up “speaking with a foreign accent”, he adds. In addition, Goodger claims that using something like Qt “limits what you can do to a lowest common denominator subset of what’s supported by that framework on each platform.”
As for the Linux version, Google initially thought that a Windows clone would be acceptable, since Chrome itself is already such a fast application. However, the people working on the Linux version of Chrome made a case for using Gtk+ instead, and Google went with that option. Since Chrome is open source, it could still be possible that a Qt version will be developed independently of Google, of course.
When it comes to the Mac version, Goodger explains that the plan there has been to develop a native version all along. “A Windows-clone would most definitely not be acceptable on MacOS X,” Goodger says, “where the APIs for UI development are highly evolved and have many outstanding features. So that’s always been the plan there.”
The Mac version is coming along nicely, and Google hopes to deliver both the Linux and Mac versions somewhere in June.
Hopefully, they will also implement something like Firefox’s NoScript extension because according to some users, the security model is still lacking.
Qt “limits what you can do to a lowest common denominator subset of what’s supported by that framework on each platform.”
The way I see this is an extremely bad excuse for not using QT for Chrome linux variant. I would have accepted them using GTK+ if they would have just said that QT licensing was confusing or something…
QT is a lot better toolkit than GTK+ and it’s a lot more advanced and it’s faster too. Take a look Opera and Skype for example. They use QT on GNU/Linux and are one of the best examples of porting Windows application to our favorite platform.
Besides Nokia who now owns TrollTech is making QT work under LGPL license…
Better talk about subject here under topic “Qt now a possibility?”:
http://groups.google.com/group/chromium-dev/browse_thread/thread/1d…
They didn’t say that QT was bad… they said they wanted to use the native toolkit. So the question is: what is the native toolkit on Linux? While it’s not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as “native”.
Well, that ought to upset a number of people here. 🙂
I’m wondering how many of them will show up to “debunk” your assertion, and “prove” it’s just a dirty rotten lie spread by Gnome fans. I suspect that there are at least ten essays under construction even as I write this. So you might want to inspect your asbestos underwear for any imperfections, and maybe borrow a few shuttle tiles from NASA.
Edited 2009-02-14 14:46 UTC
Citation needed.
I think Google coders want job security as much as anybody. So using Qt just wouldn’t have made sense.
What is better? A bit more native speed and being a bit leaner or having the browser develop at much great speed with a much better and consistent code base and simultanous releases. (Qt 4.5 is fast on every platform.)
The way I see it, Chrome was meant for windows and then after the fact they decided to go x-platform.
Great strategy.
Citation needed.
Edited 2009-02-14 15:14 UTC
There you go. The way Kragil sees it, Chrome was meant for windows. That is the marvelous quality of language where when you make clear something is a personal opinion on motivation of others it is capable of self-citation. “The way I see it GTK is better than QT.” is an opinion and stands fine on its own.
When an expression is quantifiable however this ability to state opinion is weaker. “GTK is the native toolkit for linux because Gnome has more users than KDE” is a questionable and contentious statement on multiple levels.
The original Chrome was written for Windows with strong ties to Windows API’s. Chrome was probably intended to be cross platform from the beginning; it is proving to take a large amount of effort to port to Linux and OS X however. This tends to lend credence to the opinion that it was written for a specific platform with the philosophy that they would worry about how to port to other platforms at a later time.
Citation not needed as this was an opinion.
Gnome having more users and KDE was referencing an objective fact. I would also add that clearly Chrome was meant for Windows first. I mean its obvious they only began porting to other platforms after Chrome was released for Windows. I am sure they knew they would have to create versions for other platforms but it hardly seemed a priority for them, at least initially. Emphasis on ‘seemed’.
My perception has been that Chrome was always intended to be cross-platform, but that getting the Windows version out was the highest priority. As a strong advocate of Linux, who doesn’t even allow Windows into my home, I agree with their priorities. Getting another standards compliant, WebKit-based browser out there to the unwashed, Windows-using masses likely helps us more than it helps the unwashed masses themselves.
I also happen to believe that they made a good choice in going with GTK+ for Linux. And it’s also pretty apparent to me that while it is easy to run a Linux system without QT, it is much, much harder to get along without GTK+. Shall we have a look over the default packages included by various distros to see how QT apps and libs actually fare against GTK+ apps and libs? Even if you run KDE you need GTK+.
Edited 2009-02-14 16:42 UTC
You’re demanding a citation of someone’s opinion?
How about this:
http://www.osnews.com/thread?348883
You know, it’s generally a good idea to read a post before replying to it. Just a thought.
A very interesting reply, all things considered. And your interest in this is? Looking over your posting history it’s pretty clear that you are interested in stirring up controversy within communities of which you are not a part.
Citation? Here:
http://osnews.com/user/uid:16767/comments
Do you have some *legitimate* interest in this thread?
Edited 2009-02-14 18:49 UTC
Relevance?
If you want to rely on inane assumptions, be my guest.
At least as much as you do, dear.
Edited 2009-02-16 01:42 UTC
<quote>(Qt 4.5 is fast on every platform.)</quote>
Wrong!
Qt fails when it comes to network transparency. This is true with remote X11 (unix) and terminal server (windows), especially when heavy rendering is required (cad/gis). Yes, an answer is to use vnc/remote desktop instead but they’re not suitable replacements.
We dumped qt4 because of the above and if you go looking at the qt blogs a constant theme in the user comments is: “is this feature X going to speed up remote display”?
I was kind of hoping that google might take a shot at writing a better cross platform gui toolkit.
As it stands I certainly hope to see Qt truly shredded over the next 2 years as the old unecessary redundant portions written specifically for vendor lock in are replaced with better open/standard technologies. I’d say gtk is likely to be more stable in the upcoming couple of years.
Technically, Qt is far superior to Gtk. QGraphicsView alone is one thing that you cannot do in Gtk without a significant amount of extra effort. The API, the tools (designer, linguist, creator..) and documentation are lightyears ahead of Gtk.
Also, what “unnecessary vendor lock ins” are there? You do realize that starting with 4.5, Qt will be LGPLed, right?
I have been writing scientific visualization software using Qt as the toolkit and OpenGL for real-time previews and editing. I would NEVER use the X protocol for network transparency. Instead, I wrote the application itself in a distributed way. There is no way you can use DRI OpenGL and X network transparency at the same time without ugly hacks. (And you *want* DRI with OpenGL.) Relying on the X protocol for heavy rendering is just *wrong*.
Citation needed.
I’m not looking to get into some long-winded debate here. I run 2 websites that appeal to the general linux crowd (not gnome, kde, or any distro specific) and get thousands of uniques per month.
You can’t get everything from webserver stats, but you can get a lot. Even if I make some very favorable assumptions for kde (like that >90% of kde users run firefox instead of konqueror), there are still more non-kde users.
Looking at other stats, normal ubuntu beats kubuntu by about 100-1. Maybe people install normal ubuntu and then install kde. I don’t know. Even if you assume that kde users in general don’t run ubuntu, you can’t get around the fact that ubuntu itself is the most popular distro by a rather large margin (on my sites ~55% run ubuntu).
Edited 2009-02-14 16:34 UTC
Do you believe your websites are representative of the whole world? They may appeal to a wide range of Linux users, but do they appeal to all Linux users. If your site was available in Spanish or Portuguese (I presume it isn’t), you might find you had more Mandriva (primarly KDE) users (given the Conectiva heritage) – likewise if you had German content you might find you had more SUSE (again primarily KDE) users.
Ignoring all that, I don’t see how having more users makes one system any more native than the other. To me, the whole thing smacks of measuring willies – just because you have the biggest willy, it doesn’t mean that yours the willy.
Edited 2009-02-16 15:10 UTC
Another good _opinion_:
http://www.purinchu.net/wp/2009/02/15/google-chrome/
is that a fact? where did you get your numbers from?
it would have been “gtk has a better license” couple of weeks ago ..now that both QT and gtk will be using the same licence, the reason is now “more people use gtk therefore its the better toolkit”? ..”more usage” means better these days?
it may make sense to you, but it doesnt to me and i suspect to most kde users
I think is more related to Nokia being the competence of Google (Android vs Qt movil).
Anyway, Im pleased they used GTK+, is light fast and well integrated with Linux. Thank you google.
This is the weirdest comment on GTK+ I’ve ever seen. GTK+ is anything but fast and light. Speed has always been the primary reason not to use GTK+ (and to use something faster, like Qt), as it is one of the slowest and heaviest GUI toolkits available. When people decide to use GTK+, it is always *despite* its performance, not because of it. People pick GTK+ because it is such a widespread toolkit, the de facto standard on Linux, and licensed under the LGPL (which, before Nokia announced that Qt 4.5 will be LGPLed, too, was the only real advantage for many people).
What native toolkit would this be, as Chrome by definition doesn’t have one as a cross-platform application?
While I won’t debate the number of users thing (not really at issue here), it doesn’t get away from the fact that porting a cross-platform application to specific native platforms, and have it work in the same way, is a world of hurt and pain we have already been through with Firefox and SWT on Linux.
You end up being a third class citizen behind the platforms and operating systems that have the most users ;-).
Chrome isn’t cross platform…yet. It was built with a lot of Windows specific libraries.
I think you’re confused. Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+ which will make the interface much more consistent with other GNOME/GTK+ applications.
This is not quite true.
Firefox suffers from trying to hook into parts of GTK+. Unfortunately, GTK+ isn’t very well-designed, so it is not possible to tell it to draw a random widget. The drawing API has no way of expressing “get me a picture of a GtkButton at this size”. The background color must be premultiplied and most themes require an actual instance of a widget as the detail string isn’t well-specified. The result is that, whenever Firefox needs to draw a widget, it must have a hidden instance of that widget, and then it must draw it twice, on both black and white background. Then the pixmaps get pulled over from the X server, every pair of pixel is compared in software to recover the original alpha, the image is sent back to the X server, and only then can it be displayed. QGtkStyle has a similar problem and caches all the pixmaps — I imagine Firefox does the same.
For added fun, since GTK+ was never designed to be embedded into anything, many themes assume they draw their own background and that’s why some of them draw ugly borders at the corners of buttons in Firefox.
SWT suffers from another problem. Unlike Firefox, they actually use GTK+ directly, but wrap it in a cross-platform API. Unfortunately, the SWT widget model is slightly different from GTK+’s (it instead matches that of… pretty much every toolkit on the planet). GTK+ itself isn’t very flexible, so SWT has to do many many hacks to get around this. As a result, it gets double the performance hit: once for using GTK+ at all and once more for the hacks.
Perhaps “emulate” wasn’t the correct word to use but you’re saying the same thing I was driving at. Firefox and SWT don’t call GTK+ directly and their UI code doesn’t align very well with GTK+ conventions. Firefox has come a long way and the 3.x versions are much better than previous versions. I haven’t used an SWT application in a while but the last time I did it wasn’t a very good experience compared to a strictly GTK+ application. Fortunately for Google Webkit has developed into a very portable library with an excellent GTK+ port. There is an abstraction layer that makes creating new bindings for it much easier.
Webkit in fact suffers from the same problems that Firefox does. You cannot use native widgets directly in a web engine. The performance is too bad. (Also, in the case of GTK, positioning your widgets is rather difficult.) Rather, you make your own widget-like system and call the widget drawing API to make your buttons look native. GTK makes this very difficult.
Firefox, in particular, extends this practice to the entire browser. This means they do not have to deal with SWT’s problems (the GTK widget model is very poor for wrapping), but the drawing API issues pervade the entire UI. They cannot directly use GTK because they want the UI written with the same, or similar technologies as the web (XUL, Javascript, etc.). This lets them do extensions and themes very cleanly. Also, it means they don’t need to write a separate UI for every platform — GTK+ is not a cross-platform toolkit and is unusable outside Linux.
I imagine Chrome will also want their various platforms to, at least at the highest level, share a lot of GUI code. Different platforms have their conventions, but the core layout of Chrome will probably be constant — it would be a real chore to maintain three versions of it. Not to mention the fact that, should they do extensions, having to rewrite the extension per-platform would be obnoxious.
However, to manage this, it would mean abstracting over the UI toolkits in some way. Here, they will either run into SWT’s issue where GTK’s widget model is messed up and cannot be wrapped, or Firefox’s issue where “emulating” GTK is nearly impossible.
Hmmmm. So it’s ‘native’……….to Windows? Kind of the point really. It tries to be native, but it isn’t at all.
No. They’re not emulating it at all, and that’s the problem. They are wrapping it so they can use ‘native’ system calls on each platform.
That won’t happen, because they will have to make cross-platform trade-offs to make it work across all platforms.
The GUI isn’t native looking but the underlying libraries are specific to Windows.
Like I said in my previous reply “emulate” wasn’t the best word to use but it’s not hard to recognize that SWT and Firefox do not draw their widgets the same way as a standard GTK+ app. If they did they wouldn’t look so awful (SWT at least, Firefox is much better now).
Not necessarily. Webkit has develped a very good abstraction layer over the years to make it extremely portable. There is already an excellent GTK+ port and Webkit is being used on several different portable devices as well.
interestingly, the answer is none, since unix’ (and then linux’) gui system has been designed the way it is (i.e. as modular as it can be, with widget look and feel implemented at the toolkit level) just to avoid being tied to a single toolkit, thus to have no “native”, privileged, toolkit
if there’s a native toolkit on unix/linux, that may have been AWT, but nobody has used it for ages and it has afaik been deprecated in 7.x Xorg releases –
apart from that, the next layer in the stack, ie the X11 protocol binding (Xlib or XCB )used to be considered the native gui library
but at a time high level widget libraries are designed to be crossplatform, and are given non-X11 rendering backends even on linux, that doesnt hold true any longer
Edited 2009-02-14 15:22 UTC
Isn’t AWT the Java Abstract Windowing Toolkit? or is there some other AWT that I am not aware of?
Actually Qt looks “native” on KDE and on Gnome/Xfce, while Gtk+ looks native on Gnome/Xfce but looks like trash on KDE, so I still believe Qt should be a better option.
By the way, just compare how gtk emulates Qt looks, on how Qt emulates gtk looks:
gtk-qt-engine:
http://i293.photobucket.com/albums/mm56/GithzeraiKDE/OOo.png
QGtkStyle from Trolltech:
http://arstechnica.com/open-source/news/2008/05/qgtkstyle-makes-kde…
I’ve not used a Qt app. under KDE for a while, but I always used to find that pure Qt apps always looked like pure Qt apps and not KDE apps. Pure GTK apps, look (to my eyes) the same as any other Gnome app.
Personally, I don’t like Chrome so I don’t care which toolkit they choose. Having said that, I have to agree that I find their statement, which implies that GTK+ is the native toolkit for Linux, is a little off putting. It isn’t even necessarily a native toolkit for Linux, it is cross platform toolkit just like Qt. Though I suppose you could argue that it is the native toolkit for GNOME it is, after all, the GNOME Tool Kit. And we all know that GNOME is the native WM for Ubuntu – and ofcourse Ubuntu === Linux, so I guess they weren’t wrong after all.
BTW, to all those arguing that GTK+ is the native toolkit, just because you believe that GNOME has more users – having more users != native. Though I suppose you could say it is “native” for more users.
Actually it’s the Gimp Toolkit, as in Gimp the image editing program. It was initially created by the Gimp team to use as a GUI toolkit for their program before Gnome existed.
Qt is the native toolkit every bit as much as GTK is.
The number of users is irrelevant since both KDE and GNOME have millions of users.
Not that it matters which one is used, but the obvious choice would have been Qt. And since they are now doing more work to port to GTK, the question of “why not Qt” is a very valid one IMO.
No big deal really – and should be easy for folks to port it regardless.
That’s gonna be one major obstacle for Qt in the future. Do you trust Nokia? Well, I don’t. Not a bit. And therefore I’d advise anyone to use GTK+ when it comes to new open source software projects. It’s basically the same situation before GTK+ appeared – now with Nokia only worse. Sorry.
Edited 2009-02-14 14:05 UTC
Right, and what harm could they possibly do? When Qt 4.5 is under the LGPL, anyone could take the LGPLed source and continue the efforts if Qt would somehow stagnate under Nokia.
In reality I see the opposite happening: Qt seems to have accelerated over the past year.
Hmmmmmm. But it was OK when Nokia were contributing, and still are, to GTK and you have the main GTK repository pretty much dominated by Red Hat with a bottleneck of bugs going back years that aren’t personally interesting to them?
I really was curious as to what people would get off the bottom of the barrel, and now I know. “We don’t trust Nokia, and, ermmm, it’s not native!”
Except that Nokia is making their repositories more open to external contributions now, and like GTK, if a situation gets untenable you fork it. It’s also licensed under the LGPL now like GTK is, so you can get to do the exact same things with a fork and appease the ‘develop for free’ brigade.
Where do we go from here I wonder?
So? Show me the point.
Qt is not the better Toolkit. It is just another Toolkit. And for all the functions Qt brings besides QT GUI there are also solutions on GTK side.
Edited 2009-02-14 20:12 UTC
There has got to be *some* reason companies were willing to pay thousands of dollars PER DEVELOPER for Qt licenses, when Gtk (& C++ bindings) and Wx were free, don’t you think?
Still, I’m not arguing that google should have used Qt to develop this. If the coders want to do it Gtk, they can probably get best results with Gtk (especially when they know it inside out). And it’s not like they will convert all of their existing code to GObject mess – just add parts that directly need to interface with toolkit, or use GTkmm.
And there we have it. QT is *expensive*. Nice strategy, as the World teeters on the brink of a World-wide economic depression.
Edited 2009-02-14 20:29 UTC
If you say that a Qt license is expensive you do not now anything about managing a company, not anything about software licences, not anything about software development and not anything about economics.
The licenses of Qt are not expensive at all.
Of course, if you’re just an amateur developer sitting in your bedroom, it IS expensive. But it is not for companies making software.
I can easily show you software that is 100 times more expensive PER USER than Qt. And even then, nobody leaves some sleep about purchasing it.
Talk to Vivainio. I was paraphrasing his statement that:
“””
There has got to be *some* reason companies were willing to pay thousands of dollars PER DEVELOPER for Qt licenses
“””
Emphasis his and not mine. Confer with your own QT advocates and try to come up with a consistent argument.
Edited 2009-02-14 20:41 UTC
Why do you think a few thousand dollars for development tools is expensive when a software vendor will spend hundreds of thousands on salaries, office space, equipment and hardware – and those aren’t even the tools they’ll be using to make the very thing (software) that will put food on their table?!
You basement programmers feeding yourselves via the licenses from some hypothetical shareware application that no one pays for make me laugh my ass off every time. It’s one of the reasons why I loiter on here really :-).
The argument is the same. Why has KDE 4 got resolution independence and has moved on in the way it has and other open source desktops haven’t? Given that we have so many brilliant cross-platform tools that allow you to develop for nothing according to people around here, why would Trolltech have been in business as an independent company for such a long time? I mean, what idiots actually pay for development tools? ROTFL.
Trolltech used to charge $1500 per developer seat for one platform, and then that would increase to about $3300 for a Windows/Mac/Linux bundle. They’ve since removed the price from their website so it’s not easy to see the price anymore.
However, $3300 for a crossplatform toolkit that works is pocket change. That’s less than a months salary for a software developer. To put it in other words, that’s less worth around 20 man days.
I can’t write a cross platform toolkit in a month. Porting any major piece of code from one platform to another is going to take longer than a month. Hell, Qt is cheap for what it does.
The funny thing is, I was/am a developer sitting in my bedroom and I bought a Qt license. Yes it was fairly expensive, but it was an investment, and made my small business possible. I can say with 100% conviction based on my experience that without Qt I wouldn’t have been successful with my software. Qt allowed me to produce something valuable with extremely limited resources (just me in my spare time, which isn’t much). I tried other toolkits previously and they didn’t allow that. It’s that simple.
Yeah it’s that simple if you have thousands of dollars to throw around on licesning costs but most small business owners don’t. A QT license is so expensive that forgoing that expense would leave you enough money alone to start a small business and then some.
That’s hilarious. When I bought Qt I had a grand total of ~$4000 to my name (having just finished my undergraduate degree). I made the investment for Qt (about $1100 US with the small business discount) because I knew it was my only chance to grow my business. If I had used wxWidgets or GTK I wouldn’t have a product to sell, because I couldn’t be as productive (believe me I tried).
So do you have a real experience with using some toolkit to start a real business? If not, I don’t see what basis you’re arguing from.
That sounds a little fishy to me considering there are a ton of products that use wxWidgets and GTK. Just because you couldn’t grasp either of them doesn’t mean that it’s not possible to start a business with them. I have used PyGTK to build a few small applications and it was incredibly easy. You were also lucky to get QT at that price. The last time I looked a small business license was near twice that.
As an aside I wish I had $4000 to my name after college instead of being over $50000 in debt. I would have been able to start my business much sooner.
Edited 2009-02-15 16:04 UTC
I was talking about my personal experience. Not saying no one can start a business based on these tools, but for _my_ application they weren’t appropriate. I know for a fact that my codebase would be much bigger using either GTK or wxWidgets just because I’m using many features of Qt that don’t have simple equivalents in these toolkits).
Lucky? That was the price in 2006. There is no luck about it.
Engineering with co-op and living within my means (many months spent living in a crappy place for < $250/month rent).
I’m still not sure where you got that price. Even with small business discounts the price is over $2000 for one platform. At least I could never find a price for less than that. That’s why I was calling you lucky.
People often lie about the prices they paid for things. Minnie Pearl was one of the few truly honest people out there. Mystery solved.
Edited 2009-02-15 18:40 UTC
Oh Steve, you really are sinking to new lows accusing me of lying here.
Eat crow: http://docs.google.com/Doc?id=dggd2d62_28c9s8b9fp
Think of it less as accusing you of lying, and more as spurring you to present some actual evidence. And It worked. 🙂
Note that my previous post was stated in as general a way as possible while still getting the point across. 😉
Edited 2009-02-16 17:13 UTC
Dunno about that. I just applied for the discount that’s what they gave me. Small business discount is 60% off the listed price (and I got just the one platform since that’s all that my customers wanted).
I think the correct tense would be “was.” QT 4.5 has been LGPLed, remember?
Yer, and the developer tools market is still one worth billions upon billions of dollars. Go figure.
He was talking about the past. Qt was pricey and lots of people still thought it was worth it, despite alternatives available for free. That speaks to its quality. Now Qt is LGPL and thus free to use. Your intentional misunderstandings and hyperbole aren’t convincing anyone.
GTK lacks (proper) OS X support.
Some commercial developers (Adobe) have produced QT-apps that doesn’t even run Linux.
It’s not just the existance of a functionality that counts, it’s how it’s implemented and how it can be accessed and used, and how well it’s documented. What you say can’t be enough to base a decision on, you have to try coding for both to see why quite a number of people prefer QT/KDE. Well, you might not see it, or see it the other way around, so what ? Be happy there’s the other(s) you can use.
Show a Gtk counterpart to QGraphicsView. One that actually matches its functionality. Also, show me how to something like WolfenQt (google for it) using Gtk.
http://www.vimeo.com/374006
Clutter is a very nice library, and this patch indeed looks nice, but is a fraction of what QGraphicsView can do. Moreover, it is trivial to accelerate QGraphicsView with Qt – just put the view inside a QGLWidget. It is even possible to put GL widget inside GL widgets inside GL widgets etc. I hope Clutter gets integrated in Gtk, since it is the way to go.
QT and GTK now have the same licensing since Nokia bought it out.
I think you have taken that out of context a little. The bit you have quoted was Ben Goodger’s reason for not using Qt for everything (Win, Mac and Linux), not his reason for not using it on Linux. He never gave a reason for not to using for the Linux version.
He did give a reason for GTK – his reason was that the dev team didn’t want to make a clone of the Windows version (presumably using Wine-lib), but rather they wanted to use GTK. Presumably GTK is what the dev team are more experienced and comfortable using.
ps. I can’t believe how much time I have wasted commenting on this article, considering I couldn’t care less about Google Chrome.
This was part of the Linux Chrome original announcement.
Damn them. I had hoped for a usable browser based on Qt (four). I chose Chrome over Firefox on Windows due to its great Aero integration and because I don’t surf on Windows so much that I’d miss AdBlock.
But on Linux… A “Firefox clone” doing less than what Firefox’s capable of… I just wish it at least lets me choose the native GTK theme over whatever they come up with.
Edited 2009-02-14 14:15 UTC
says it all.
Alas, with the Linux version of Chrome we’re going to get the same as the Linux version of Firefox – a poor third class citizen that integrates poorly, despite the ‘native’ claims, has a ton of stuff ported over from the Windows version poorly and needs a lot of work to port rather than just letting the toolkit take the workload and handle the problems.
I’m afraid this is rubbish, and it seems that Google, or some people in Google, have little experience of how difficult cross-platform development is.
Firstly, if you have a cross-platform application then you have to pick a lowest common denominator of what will work across each platform by yourself. That’s unavoidable. In practice you never find this common denominator yourself. When the bugs start rolling in you quickly find that there are some things that work on one platform that don’t work on another, you have GUI issues that happen on one platform that don’t on other, and worse, when you try and fix it it breaks behaviour on another platform. Anyone who has seen SWT’s massive bug list and has used wxWidgets to develop a complex application knows this. The net effect of this is that, in the case of SWT, Win32 is silently supported as the primary platform. Not very cross-platform.
It gets even worse the more complex things get with things like graphics and you find yourself having to write ever more cross-platform ‘glue’ to get things to work to the point where you have your own, poor, cross-platform toolkit anyway! That’s what happened to Firefox.
This is the problem you have when you develop a cross-platform toolkit and try to port it so that cross-platform applications all have native look and feel and native tie-ins. You get divergence, and with divergence you get maintenance and bugs. Lots of them. In practice, you have to concede something. Qt is the only toolkit that gets it right. It uses as much of the native system it can for look and feel, but it handles as much in the toolkit as it can get away with to ensure its integrity across all platforms and that it actually works.
Secondly, the notion that you somehow have to stick to a lowest demoninator is rubbish as well. You use a toolkit that ensures your common denominator will actually work, and you then build your platform-specific extensions on top. Qt can do that very well:
http://labs.trolltech.com/blogs/2008/05/13/introducing-qgtkstyle/
Qt is just the right platform for this kind of stuff. I explained it quite well when Qt was LGPLed as well, and I did wonder what the excuses would be next 😉 :
http://ponsaelius.blogspot.com/2009/01/qt-goes-lgpl.html
Will you ever stop using every osnews.com as your personal blog?, if you can’t express your self in less than 10 lines then you can’t express at all.
If you can’t take at least some time to make a meaningful comment and a reply to an article then……………go away. If you have something moderately useful to say to further discussion then by all means do so. That’s why we………..comment on articles and comment on comments.
If what’s been written upsets you then that’s something you’ll have to deal with on your own rather than crying your heart out here.
Some of us are over the age of ten and would like to point out and discuss the issues at hand – namely what it takes to do cross-platform development here.
Edited 2009-02-14 15:13 UTC
On the Mac, it is about as alien looking as running a windows application in Parallels.
Nothing looks right, edit boxes do not behave normally, they use very strange looking widgets. They use their own even loop, own message dispatching system, and draw most of their own widgets, and fonts are rendered just plain weird. On the Mac, QT is an absolute disaster. The few QT apps I use, I just use them under Linux in Parallels, because the Mac version is so horrendously bad.
There are some very nice cross platform apps out there, but each one uses the native toolkit on each platform, such as Transmission, and HandBrake; they use Cocoa on Mac, GTK on Linux, and WinForms on Windows, so they all end up looking right on each platform.
Every so called ‘cross platform’ user interface toolkit has these kinds of problems, although none are as bad as QT on non Unix platforms.
Cross platform non UI libraries make a lot of sense, but the UI very tied into the OS, and its tied in for a reason, Windows users want apps to behave like Windows apps, Mac users want apps to behave like Mac apps, and with these ‘cross platform’ UI toolkits, apps behave like something thats just plain strange.
If you read some of the reviews of KDE 4 on Windows, they will echo these same criticisms; that it just plain feels weird compared to a native Windows app.
I for one think Google made absolutely the correct discussion: have a cross platform core, and use the native toolkit on each platform to present it to the user.
Seconded. QT under OS X is an odd experience, some behaviors are similar to native ones but others are not. One thing in particular I see with several QT applications is they stil use the ctrl key, even under OS X, for their keyboard shortcuts. OS X users will understand, this just doesn’t fit.
The ctril v’s cmd thing is purely a developer thing.
I could make a Cocoa app that would make an OSX’s user’s toes curl with out there being a single line of code that was dedicated to doing so.
Well, maybe on Mac you have this “consistent look” people like to praise here, but it is not like things are on Windows *. Office 2003, Office 2007, Windows Media Player (9, 10 , 11), Firefox, Chrome and lots and lots of other softwares abound on Windows and are hated or beloved without showing this “holly grail” thing.
Its not just that QT is ‘odd’ on a Mac, its that nothing quite works right. Edit boxes are not drawn correctly, text is always misaligned, pretty much everything else is misaligned as well.
Not to mention how coding for QT is just plain UGLY compared to objective-c, vala, c#, or pretty much anything else I can think of, well maybe, MFC is almost as bad as QT.
Qt code actually flows really well – I wouldn’t call it ugly at all. It’s a telling fact that PyQt ui code is not all too different C++ Qt ui code (to the point where PyQt documentation is pretty much a copy of the Qt documentation). Managing that in “writing to the metal” language like C++ is no mean feat.
The alternatives you present are proprietary/specialized languages for a small target group (ok, C#’s target group is large but still limited mostly to one segment of computing, Windows), while C++ is a standardized “universal” language that delivers pretty much the best performance on all platforms.
Regarding the choice of Gtk for chrome – the toolkit choice doesn’t really play a big part here, it will use Chrome’s custom stuff for almost everything. It’s mostly about file selection dialog & the likes. I believe this is the same situation with Firefox and OOo.
Of all the toolkits I’ve used so far, Qt is the only one that was pleasant to code for. I cannot understand your comment. Perhaps you used Qt with some other different toolkit design design guidlines in mind?
They use their own even loop, own message dispatching system, and draw most of their own widgets
As do a number of the Cocoa controls, NSStepper and NSSlider for example where everything is performed in a their own event loop in their mouseDown messages. They do not even fire mouseUp, if you want to do something after the mouse button is released you code it in an overloaded mouseDown and do it after a call to the parents mouseDown.
The funniest thing is that the aqua look isn’t even Cocoa’s own native look, it’s a skin. Create a NSButton in code instead of using Interface Builder and you get a boring rectangular button. To get the lozenge look you need to call setBezelStyle.
see http://www.vargolsoft.net/2005_09_01_archive.html for an example.
Every so called ‘cross platform’ user interface toolkit has these kinds of problems, although none are as bad as QT on non Unix platforms.
Apart from GTK, wxWindows and most of the others. I’m not saying QT is perfect but seesh saying its the worst is a joke.
I feel (note this is an opinion) that most of the people who moan about the differences between toolkits wouldn’t be able to tell the differences between them if they where not told which toolkit an app used in advance. A large number of them are bandwagon jumpers following the bandwagons propaganda and if asked to explain why a toolkit apps behaviour was different would struggle to offer a reason other than ‘because it uses toolkit x’. There are only few behaviours that people expect in an app and they are mostly the same on all platforms. The big one on OSX would be the menu bar, but both GTK and QT do the right thing here though GTK requires platform specific code.
You ought to try out the latest Qt 4.5 build on Mac. It even uses the Cocoa toolkit to build 64-bit apps!
I have tried it, and no it technically does not use Cocoa
It works like QT does on all other platforms, it essentially, just creates a single Cocoa window, then does all of its own drawing to this window. It essentially just draw to a single pixmap per window, then just uses Cocoa to draw the pixmap to the screen.
This is precisely why it looks so strange, because it has all of its own controls and widgets instead of using the native OS widgets. This may not be so bad on Unix, where QT can be considered the native widget set, as X11 really does not provide for widgets, just a port to draw stuff to.
What do you mean it doesn’t look native? Specific examples?
We have clients using our Qt apps for vision research on Macs. They couldn’t tell any difference. One of them has OCD and any Mac app not behaving like one drives him nuts. In fact when coupled with the unified toolbar look they couldn’t tell any difference whatsoever.
You ought to try out the examples that come with the RC release and post the discrepancies here. That would be a more useful comment.
By the way, I have often seen comments like yours even for wxWidget apps. wxWidgets uses native carbon widgets like SWT.
I guess you can’t please the Cocoa nazis.
-Ad
Does not look native? well, text does not line up in edit boxes, none of the controls line up correctly, etc…
One of the biggest reasons I use a Mac is for Cocoa / Objective-C. On linux I use GNUStep, which is not bad, but still needs a bit of work.
One of the big reasons I still use Windows, is C# / DevStudio is such a nice development env, although WinForms with Mono is definitely coming along nicely.
So, I guess your right about not pleasing the Cocoa nazis if thats what you want to call me. So I suppose say you had a really nice car you really liked to drive, and someone came along and said we are going to take your nice car, and you have to drive a Yugo or a Pinto because they were the lowest common denominator, and you did not want to give up your nice car, then I suppose that they might call you a car nazi?
Edited 2009-02-15 19:45 UTC
Can you post/link to screenshots that show what you are talking about? Saying “it doesn’t line up” doesn’t really help get the point across as well as a picture would.
The point just passed right over your head at about 30,0000 feet.
We are talking about developing cross-platform applications here that run on Windows, Macs and on Linux and Unixes and where we are doing that in the most economical and bug-free fashion for the developer. The toolkit solves the cross-platform bugs, not the developer. We are not talking about developing native Mac applications because these aren’t native Mac applications – they are cross-platform.
They use native Mac look and feel actually, but they have to ensure that the interface looks consistent enough across the platforms you might run it on. Not sure what you’ve been looking at.
Well yer. You don’t rewrite an application for each platform to use the native loop and IPC system!
Yep, and each ‘native’ version is out of sync with each other, the developers prioritise the platforms that have the most demand, there is a ton of maintanance for the developers and you get bugs you cannot reproduce on different platforms. They are separate ports, and really, separate applications and they will end up using their own cross-platform glue to keep the common bits together. You obviously missed that part.
Considering what you get for it, Qt looks pretty decent certainly on Windows and on a Mac. Alas, there is no cross-platform toolkit that uses the ‘native’ approach for Windows, Mac and Linux that actually seem to work well enough with lots of applications written with them. Like I said, look at SWT’s bug list for a good example of what is needed for this approach.
Like I said, they made the wrong decision because you give up a certain amount of look and feel for being cross-platform, and as Chrome looks completely different to most Windows applications anyway, your arguments about native Windows and Mac applications are null and void.
I’m proved right because SWT and Firefox have all tried to follow this route and we have one outcome – endless complaints about the GTK and Linux ports of Eclipse, Eclipse applications and Firefox and a bug list that never ends.
That’s KDE apps and not Qt. Funny how I develop commercial Qt apps primarily on Windows and have never heard a single complaint about how they “feel weird”.
It’s especially hilarious that Google is harping on about native look and feel when Chrome looks anything but like a normal windows app (does that even exist these days?). Let’s face it, when even microsoft has half a dozen different visual styles for their apps on windows (compare Notepad, MSN messenger, MS Office, Expression studio, Songsmith, etc etc) then there really isn’t a “native” look. Every app does their own thing, and Qt apps look a hell of a lot more “standard” than just about everything else.
segedunum, you sure got the issue by their balls.
Another thing that Qt has is 64-bit capability on all 64-bit platforms it is available on. Which is something wxWidgets/SWT/GTK+ severely lacks.
Don’t believe that? Name me one GUI framework that works with Win64 and Cocoa 64-bit! Qt 4.5 has it!
Qt 4.5 is now in RC-1!
Edited 2009-02-14 20:34 UTC
Unfortunately, you are using very good arguments but come to the wrong conclusion. The “SWT disaster” is exactly why they do *not* want to use a cross-platform GUI toolkit. In fact, if you compare your statement and the original statement from Google, you will find that they are very similar. The essential difference is that, although Qt may “get it right”, that’s still far behind a custom-built native GUI.
> Firstly, if you have a cross-platform application then you have to pick a
> lowest common denominator of what will work across each platform by
> yourself.
You are starting from the assumption that a cross-platform application must work exactly the same on each platform. In contrast, Google is trying to make each port fit nicely into its environment, even at the cost that different ports do not work the same anymore. Looking from another point of view, such a kind of “cross-platform application” are actually different applications – one for each platform – that happen to share a lot of code.
Doing so of course requires a multiple of manpower, but I am assuming that Google can afford it. Qt, on the other hand, is a valuable tool if little manpower is available, but – according to Google – this comes at a cost.
Hmmmmm. So I want to be a developer writing a cross-platform application, wondering why my Windows users have the right layout in a dialogue box and my GTK and Mac users don’t and wondering when that open SWT bug for the problem will get fixed on specific platforms?
It’s not my idea of developer nirvana, I can tell you.
No they’re not.
The problem is that they’re not writing a native GUI. They are writing one that they want to work cross-platform in the same way with the same functionality.
If it’s the same application, and they want the same set of core functionality, then yes. That’s the whole idea behind a lowest common denominator.
I’m afraid once you have divergence like that then that’s the road to hell. Users complain that one port is behind another, you find there are some things you can do on one platform and not on another and the whole thing drops to pieces. You then prioritise the platforms that are most important to you.
I don’t think you have any idea how difficult that is to do, because how do you work out what code to share and what to make native? In the case of SWT, wxWidgets and Firefox you simply wait for the bugs to flow in and spend forever trying to fix them or hope that no one ever writes anything too complex.
There is no amount of manpower you can throw at an application once it gets past a point of no return to make it better. It’s the mythical man month.
It doesn’t come at any cost. The toolkit identifies a proven lowest common denominator which you don’t have to find and you then add platform specific extensions if you want to. It’s very doable with Qt.
I think the point is that Google wasn’t satisfied with the Lowest Common Denominator that the available toolkits offer.
Fact is, outside of Firefox & Adobe, there is no major piece of software that uses a cross-platform toolkit across Mac & Windows. And both these companies UIs have often been criticized for not behaving / appearing correct on the Mac (and I have heard similar complaints about the Windows versions as well).
And it doesn’t have to be as complicated as you make it sound. You will have one team working on the rendering engine, which will be cross-platform, and one team each working on the wrapper for each platform. Considering that there are small companies like Omni & Shiira that are able to develop their own browser for a Mac, I’m sure Google has enough guys to work on the Mac platform, Linux platform, and Windows platform.
I’m not sure you understood the original comments – using QT for all platforms would leave it a second class citizen on OS X (no idea about Windows).
Non-native apps stick out nastily – you can nearly always tell it’s ‘different’.
It’s like Java – sure you can make a working cross platform app, but it will be hated by many users because it feels so wrong.
Google have done the right thing for Chrome -> the back-end is cross platform C/C++, the front end will be ‘native’ on each platform. Unlike Firefox, which feels awful on OS X (for example).
Whether normal users care or not is debatable. All the mac users at work use Firefox because it’s a better browser than Safari, they don’t notice, much less care about any small differences in the UI. When apple can get away with all their different themes and styles, the experience isn’t nearly as consistent as some people like to think. That said, I have no experience with Qt apps on a Mac, so I don’t know the extent of the differences.
There’s a huge difference between Java and Qt though. Java doesn’t even bother trying to be native. It just looks awful on every platform.
I still think that’s a mistake. Look at Skype for example. They use Delphi on windows, Cocoa on Mac, and Qt on Linux. Their Windows client obviously and rightfully receives the most attention, but because their GUIs are completely different, this means that their Mac and especially linux clients lag far behind. The interface is wildly different on the new 4.0 release for Windows than anywhere else. The other clients and languishing and just randomly integrate some features when the Mac/Linux teams have time.
So what’s the final situation? Three GUIs that are so fundamentally different that they might as well be different apps. Massive development effort as evidenced by the fact that the other platform teams can’t keep up to windows.
If they would have used something like Qt, the windows client would be just as advanced, and the Linux/Mac clients would be up to par. I don’t know about you, but I’d rather have a full featured Mac client with a couple inconsistencies than a crappy neglected client that lags behind what Windows gets.
Of course it does. The Swing SystemLookAndFeel tries to mimick the LaF on Windows, Mac OS X and Gnome/GTK+ in the same way as Qt does.
Do not make a Linux version of your software – receive flak from the community.
Make a Linux version of your software – receive flak from the community for not picking the toolkit du jour.
I love the Linux community
.
Wouldn’t it be nice if you can find some way to make the GTK bashers take responsibility for the things that the google-sucks-because-chrome-is-not-available-on-linux people say?
Well, now Thom you know that the war between KDE and Gnome is almost as old as Linux is. It’s a family thing, and the bigger family gets, the more it squabbles. I only had two brothers growing up, but didn’t want to deal with either of them. I can’t imagine have like 10 brothers and sisters in the same household.
I suspect that many of us (kde users) are chafing under the weight of khtml. And would love to see Qt based browser that has a chance to be supported by website creators (and is really fast).Currently the khtml devs don’t really seem inclined to better integrate the webkit kpart.
We’ll see what happens in the near future.
Well, they certainly haven’t picked the right one if they really want to make Chrome cross-platform and make it work, so I wish them luck. Firefox certainly hasn’t worked in that direction so they haven’t learned any lessons.
Mind you, there’s an even bigger obstacle for Google than the toolkit – getting the damn application distributed to users and installed in the first place! 🙂 Linux is a whole world of hurt on that front.
Not exactly. Distributing commercial/precompiled applications is a pretty awful experience on Linux.
But if Google include the GTK interface in Chromium, then they will not have to even lift a finger to get it distributed to all the major distributions. There are many people out there seriously interested in getting Chrome[ium] to work on linux, and there will be no shortage of people willing to create and deliver packages once it has been released
I’m probably in the minority here, but I’m certainly pleased with their decision to use GTK+ over QT at this point. I have selfish reasons for this, I admit it. I want to be able to use Chrome under Linux, and GTK+ is the only major toolkit with true accessibility support. This should integrate with GNOME nicely and, given it’s using Webkit to boot, should make for a very nice experience. I’d love to be able to use something other than Mozilla products for browsing on Linux.
Same here. I prefer GNOME, and use only Gtk+ applications because I don’t like my stuff looking out of place. This has nothing to do with which is the better toolkit – in all honesty, I don’t give a rat’s bum about toolkits. I want what looks and works the best, and using a strictly Gtk+ desktop, I’m happy Google chose Gtk+.
Purely selfish, yes.
Out of place?
Well lets look at that, GTK+ doesn’t or hasn’t attempted a Qt theme that integrates with KDE/Qt apps by default(some third party GTK+ theme it is).
Qt4.x actually comes with a GTK+ clearlooks looking theme. It’s funny how people blame KDE for their GTK+ apps looking out of place and fail to notice Qt has this theme to fix the issue.
Says the guy who uses a Gimp avatar
I see thr smiley, still, I’m just fed up with this.
We choose apps, not toolkits.
There, you can shoot me now.
Yes we do, and toolkits and developer tools dictate applications. That’s why we have precious little that attracts people in the Linux and open source world.
I’d say it’s really the job of the operating system distributor to ensure that all the GUI toolkits provided by the OS have a consistent look. Seeing as there are only really two toolkits that are widely used, that shouldn’t present too much of a challenge.
Another thing to add to that point: Qt 4.5 will come with QGtkStyle which directly calls into GTK+ to handle the drawing (which involves quite a few hoops to jump through. GTK+’s drawing API is awful). For older Qt, you can compile it separately with some fiddling. It does its job incredibly well. Native GTK+ file dialogs, the widgets look right, etc.
There is an equivalent for GTK+, but it’s hacked together by one guy, unstable, and rather badly lacking in areas, whereas QGtkStyle is officially maintained by Trolltech.
That says a lot about the demand for such a thing.
I sincerely hope you’re happy with all three of them. With one button on each.
Which application do you like and feel works better – Firefox on Windows or Firefox on Linux?
Do you believe that having used Firefox on Windows that a user is going to be happy with Firefox on Linux and stay put? 😉
Well, hold on. Google haven’t told us how they’re actually going to get Chrome distributed and installed on your desktop yet. That might be even more fun ;-).
The words “firefox” and “better” need to be at least ten sentences apart
I have an absolute dislike for Firefox, whether it be on Windows, Linux, or the moon. Like Opera, and IE too now, it tries to be too much. A browser is a tool to show web pages. That’s it. I don’t need awesome bars. I don’t need plugin frameworks. I don’t need integrated RSS. I don’t need themeing.
I am very peculiar when it comes to browsers. The features coming in Chrome 2 have me worried that Chrome too inevitably will move towards Firefox/Opera/IE.
Ofc it will.
http://en.wikipedia.org/wiki/Ben_Goodger
Yes I know. Netscape 6 anyone? 🙂
Well yer, Firefox is not a fantastic app as they’ve treaded the line with IE familiarity.
However, it doesn’t answer the question. Do you really think that we have ports of Firefox and applications like Open Office to Linux that are as good as those on Windows, and do you really think the cross-platform crap that has been hacked on has made them better applications?
I think Linux works really well on both actually.
A bit too bad that Firefox can’t keep it’s keyhole-branding (it’s practically their GUI trademark now) on Linux, but I guess that would be difficult on GTK.
I have good news for you then. Qt 4.5 will introduce a “GtkStyle”, which will actually use Gtk internally, so all your Qt4-using apps will blend in with GNOME.
You said that you would love to be able to use non-mozilla browser on Linux.
Have you tried Epiphany with webkit? IMO, too many people overlook Epiphany.
Yep I’ve tried it, but it seems to crash quite a bit for me and I haven’t figured out why yet.
How about Midori it uses WebKit also.
http://www.twotoasts.de/index.php?/pages/midori_summary.html
Because the WebKit backend is experimental. At the earliest it will become the supported backend in Gnome 2.28.
As if it was acceptable on Linux.
Qt is much better then GTK, so I don’t see why they would pick it. With it they could develop chrome for embedded platforms plus win, linux, mac and it would still look great and be fast. And they already use Qt on Earth.
To me the reason for using GTK+ is obvious. If they had chosen QT, KDE would have not dumped Konqueror as their default browser anyway. On the other hand, using GTK+, GNOME most certainly will dump their default browser (Epiphany?) allowing them to get higher penetration in the Linux market. Don’t forget that Firefox is NOT the GNOME default browser because it doesn’t use the GTK toolkit. If Chrome becomes the default browser in GNOME there is a good chance Distros will ship it instead of Firefox or in addition to Firefox.
I can’t follow you. Why would GNOME dump their default browser but KDE wouldn’t?
Gnome treats its default browser as the redheaded stepchild. It’s quite shameful. FF is effectively both KDE’s and Gnome’s default browser, in the real world. Which, as an advocate of Epiphany, annoys me no end. The Epiphany crew is working hard on dumping Gecko for WebKit. I am hoping that once they get loose from depending directly upon their most direct (and unsympathetic) competitor, and are using a superior rendering and javascript engine, Epiphany will finally come into its own and get the support it deserves.
Edited 2009-02-14 17:10 UTC
Firefox is not the default GNOME browser, it is the default web browser of Ubuntu, openSUSE etc. Just because many people don’t understand the difference does not change the fact that the default GNOME browser is Epiphany. I know what you mean by the “real world”, but still, Ubuntu is not GNOME. (Even if it means “GNOME is not the real world” then.) The fact that Ubuntu does not care about Epiphany does not mean that GNOME does not care about it.
Edited 2009-02-14 17:27 UTC
Don’t blame Ubuntu. Granted, Ubuntu is a very important one. But is there a distro anywhere on which Epiphany is the default? I suppose, perhaps, it is on Nuisance. But I’m not even certain of that.
The browser is *very* arguably the most important app in the stack. And Gnome throws theirs crumbs just to keep it alive. I’m a Gnome advocate. But their treatment of Epiphany gets a “Boo! Hiss!” from me.
And what more can they do about it? They are working on Epiphany, they make it their default web browser and then they make it available. And then comes Ubuntu et al., pick GNOME, throw away Epiphany and include Firefox instead.
I’m not saying it’s Ubuntu’s fault, but it’s not GNOME’s fault either – the Linux distros do it not because Epiphany is bad, but because Firefox is extremely popular, most web sites don’t ignore Firefox, it’s the de facto standard non-MS browser, people expect it to be there, Windows users who try Linux for the first time are happy when they find a web browser they’re familiar with, they don’t care about alternatives…
There’s nothing GNOME can do about it (maybe except for making Epiphany 100 times better than Firefox – that’s the only way it could generate some interest, but of course that’s impossible).
Actually devote some resources to it?
To the extent that they have ignored it, it is.
Yes there is. They could try. Incompatible as it is with the web, at large, even Konqueror has fared better. Because the KDE guys do seem to care about their browser.
Edited 2009-02-14 18:08 UTC
Can’t be true, since Epiphany uses either Gecko or WebKit for rendering.
Incompatible as *Konqueror* is. Hello? *Of course* Epiphany has good compatibility with the web, at large. You are completely misinterpreting more of my posts than you realize. In fact, you are acting like a KDE fanatic in reverse gear.
Edited 2009-02-14 18:56 UTC
This is Free software. We welcome new developers with open arms but we can’t force people to work on something, you know. And unlike some other Gnome modules, no companies are interested in hiring people to work on Epiphany.
In any case, you may be interested to know that Epiphany has recently gained support for Javascript extensions with Seed: http://racarr.me/blag/?p=34
ReinoutS — Epiphany development team member
GNOME will not use Chrome for the same reason it does not use Firefox – it is not a GNOME application. The GNOME developers have very high standards when it comes to integration and strict interface guidelines – I really doubt Google Chrome will follow the GNOME Human Interface Guidelines:
http://library.gnome.org/devel/hig-book/stable/
That’s why they have Epiphany. A true GNOME application.
Why would GNOME consider dumping Epiphany? It’s a fine web browser.
Huh? Why would Gnome want to do that. I don’t see how Chrome provides any advantages over Epiphany. It’s certainly going to be less integrated into Gnome, and the speed advantage isn’t really noticeable in real world use so all that’s left is a less mature browser driven by one company, which could easily loose interest and make the project die (open source devs don’t just magically appear when you open some code).
because they possibly know it better. I do not believe they have any problem with Qt except the learning curve. GTK+ is acceptable. Nothing here to debate. I wish the Windows version used GTK+ for minimizing porting efforts.
Not sure about which one got the steepier learning curve. Although Qt is quirky with his MOC, doing OOP in C just doesn’t make sense to me. On that aspect, I hope the Chrome team will exploit one of the multiple GTK+ bindings to evolved languages.
Using GTK+ for Win32 would be a sure way to lose their userbase on that platform… GTK+ for Win32 is slow, ugly and feels awkward, even with the WIMP theme. Although GTK+ is portable, it was really meant for X-Windows. That’s okay, as I don’t want to dismiss their wfforts… but it doesn’t really meet the definition of cross-platform that I have.
I use Pidgin and although it is not perfect it feels more native than 70% of the apps on Windows.
There isn’t all that much consistency on Windows, people doesn’t seem to care as much about as Linux and OS X people…
If Chrome’s choice of GTK upsets anyone, there is the freely available option to not use it. Since it’s going to be open, I’d frankly prefer that the DE’s take a look at the goods and incorporate the good parts into their own native browsers. Google is probably hoping for downstream contributions to various front-ends, but there’s nothing to say that downstream can’t work with the Chrome backend and collaborate with upstream.
KDE already comes with Webkit integrated now. Just from playing with the Arora browser I can see a remarkable improvement in rendering and consistency over KHTML. If Chrome can help point the KDE or Nokia team to providing a low-footprint browser that’s high on performance and low on bloat and extras, and with much better compatibility that the poor, beleaguered KHTML Konqueror I’m currently using, I’d see that as being much more valuable to the KDE/Qt community.
Gnome is already moving towards webkit as the standard backend for epiphany, and they would have a similar opportunity to offer a lightweight but powerful native browser for their userbase.
Personally, I block google cookies as it is so I can’t see myself trusting Chrome regardless of the toolkit it chooses (I know, tinfoil hat and all that). But if it can help provide some real competition for Firefox, help further adoption of webkit without fracturing it, and help lead to performance improvements with things like javascript to improve the overall browsing experience, then it’s a good thing all over.
Of course, that a lot of ifs…
From Mangament point of view, I bleive that Google made a big mistake. Instead of focusing on value adding development they will spend their effort maintaining multiple version of the GUI.
Multi OS C++ development is a reallity, and we have many successful software projects running on multuiple operating systems. Instead of the need to maintain multiple versions of the GUI, they should have gone with either Qt or WxWidgets, though Qt is my prefered API.
Isn’t the real question, why does Linux need Chrome when it already has Firefox, Opera, Konqueror, Epiphany, Ice Cat, and (when all else fails) Lynx?
What this does show is one of the following:
1. Google doesn’t seem to be a company with a central management and consists out of several smaller companies.
Google Earth is made with Qt. Why did they choose Qt and not GTK+? Are the developers that create Google Earth more familiar with Qt and/or C++?
2. They experienced bad things while developing Google Earth with Qt. But it would be very nice to hear about these problems.
I suspect that they chose QT for Google Earth for reasons relating to your possibility #1: The devs on that particular project were C++ guys. And then possibility #2 took hold as reality set in.
QT always seems to be presented as the “shiny” solution. But where are the results?
Google, to its credit, is a company that learns from its past mistakes.
Yet… some companies do the exact opposite.
Nokia for example. Maybe a little bit too extreme as an example, but still.
Because they bought out a competing toolkit for a song, and then put out some encouraging press releases to appease the bought up natives? Where are the products?
Edited 2009-02-14 20:24 UTC
You can’t really expect the products to come out this quickly after they purchased Trolltech, and public discussion about technical details is prevented by NDAs.
Wow. I have one guy on one side hammering me about how QT is going LGPL and another guy on the other side hammering me about how we can’t see the wonderful benefits of QT due to NDA agreements. Fantastic community. How can I join? Is there an NDA involved?
Edited 2009-02-14 20:54 UTC
Sorry, didn’t mean to sound harsh, was just pointing out that QT 4.5 is going to be licensed under the LGPL. Therefore, it’s not expensive anymore. I’m not Pro QT, I’m Pro GNOME, just interested in having the most accurate info possible out there.
Of course you can hear about benefits of Qt – you just won’t see what Nokia is up to as far as their products (phones) go immediately.
If anything, Qt development is moving to a more open model with LGPL license and other future changes to the development flow (acceptance of outside contributions without copyright assignment etc).
So, what about all those years we were told that QT was more Free because it was GPL instead of LGPL? I think the move is good. But isn’t there a fair amount of crow to be eaten on the QT side? I’d like to observe the eating. Assuming that’s not under NDA, too.
Did anyone seriously believe that? 😉
I don’t really *know*, but I’d wager that it was not under LGPL because Trolltech was dependent of cash inflow in order to continue. This is no longer the case (Nokia can easily support Trolltech without another dime from Qt license revenues), and I don’t assume the Trolltech chose GPL because of RMS-grade Free Software fanaticism. Quite on the contrary, since they were selling proprietary licenses at the same time.
GPL is more Free for the users, LGPL is more free for the developers. So it really depends how you look at it.
Why? If Qt had been LGPL from the start, Trolltech would have gone under years ago and we wouldn’t have Qt anymore (at least not as advanced as it currently is). So you can’t argue that their licensing model was a bad idea because it allowed them to continue putting resources into Qt development.
Now that Nokia doesn’t depend on Qt license revenue to stay afloat, they can LGPL it to make it available to more people.
That’s speculation. If QT was LGPL from the start open source developers would have been working on it for years now and there is no telling what QT would look like. It might even be a better toolkit if Trolltech went under. No one really knows.
It’s not speculation, it’s reasoning. Look at Trolltech’s financial statements. They indicate that most of their revenue came from license sales.
Now lets think about the reality of developing a cross platform toolkit. It’s really hard. As evidenced by the fact that GTK is just now beginning to have some semblence of support for Windows and OSX (hell, they just recently got support for the global menu bar in OSX).
Qt on the other hand, has supported this for a while, and why? Because they had 50+ devs devoted to making it better. The only reason that happened is because they were paid to do that. If the LGPL route really would have been better, GTK would be way ahead in every aspect by now. After all, open source developers have been working on it all along, as you say.
So yes, we can’t know for sure what would have happened to Qt without Trolltech, but we can logically look at the facts and realize that lots of paid devs will move a project faster than none.
You do know that QT has been around quite a bit longer than GTK right?
People get paid to work on GTK+ too. QT is also about 7 years older than GTK+ so that’s not really a fair comparison.
Faster doesn’t always mean better. In fact this is the biggest problem with commercially developed software. They worry a lot more about getting their product to market then making sure their product works the way it is supposed to do.
Not nearly as many.
Qt is a complete class library. GTK is only a GUI toolkit, so this whole comparison is silly. Qt is closer to something like the complete Java or .NET class libraries.
You’re twisting the argument. 10 people working on a big project will move it faster than 1 person assuming the people are approximately equally qualified.
By faster I mean the pace of development, of bugfixing and adding features, not the time to make a release.
You’re the one who brought up QT as a comparison when this article was about GTK+. I was assuming you were referring to the toolkit only.
I’m not sure if you understand how open source development works these days. Important projects tend to have people getting paid to work on them from at least one company and sometimes more than one company. At the same time you can have hundreds of contributors that are not paid. Personally I think this model is much better. There are other reasons than idealogy to believe open source is a superior environment for development.
Just another small point concerning QT. If it was indeed GPL or LGPL from the start GTK+ might not have ever been created and even more developers would be working on it. That’s why I’m saying you can’t just claim that Trolltech being the sole owner of QT has been more beneficial than if it was open source. It’s just conjecture.
Unfortunately, (this I heard a year back) GTK was hurting for developers. Dunno how the situation is now. It’s apparent “openess” did not help it attract devs.
There is a reason for this…and that is most devs hate programming infrastructure (the kernel being the exception). Major case in point is xorg.
You’ve presented one questionable “case in point” that you heard “years back”, and one undeniable exception which holds to this day. I’m not sure that makes a very strong case.
Edited 2009-02-15 20:22 UTC
That rolls off the tongue nicely. But does it really mean anything?
GPL gives the copyright holder, and upstream authors in general, more control over what the downstream authors can do with the code. LGPL gives upstream less control over downstream. End users don’t even need the source; They only care about binaries. So they don’t really enter into it.
Edited 2009-02-15 01:40 UTC
Whether users care about source or not is completely irrelevant. Users have more rights with GPL code than with LGPL code (they can redistribute anything based on GPL, simply speaking). Whether they chose to care is beside the point. What are you trying to get at anyway?
Well google earth is pretty awesome. Any evidence that there are major problems with it or are you just making stuff up now?
Google acquired Google Earth technology from “Keyhole Inc”. Read this: http://www.nabble.com/Google-Earth-uses-Qt-td4842474.html (yes, you can probably google up better references).
Perhaps it is because they can make sane choice
That’s certainly possible, but I think the reverse it true here, i.e. the lead developer of Chrome, who also happens to be the main UI developer, is more familiar with GTK+.
What about freebsd? Talk about Linux not getting any love. Seriously any port to Linux is better than none at all.
FreeBSD can use Gnome … Funny how a BSD software don’t work or is not even considered natively for BSD 😉
Edited 2009-02-14 20:48 UTC
I am a Gnome user but I use a number of QT4 Apps on Gnome such as Avogadro. There is a Clearlooks theme for QT4 and then the apps look quite at home on Gnome. I wouldn’t mind Chrome being on QT4.
I think it was mad for Google not to have developed Chrome on QT as a real cross platform app in the first place. Their arguments for not doing so are pretty lame and don’t hold water.
It is time Google developers realized that they should be building applications as cross platform from the get go.
Actually, you are quite wrong. Their arguments are far from “lame”.
Google simply acknowledges that there are strengths and weaknesses in each platform, and that to use the “lowest common denominator” would be to discard some potentially useful features of other platforms. Does QT4 support Core Data or the upcoming Grand Central for example?
Really — the Linux brigade should be grateful that Google are even bothering to do more than a simple Wine-port.
What makes you think it never will?
FYI, Qt supports using Direct3D on Windows for raster operations. On Mac, they support CoreVideo/CoreAudio for media playback.
The above are examples that Qt does use subsystem features. Snow Leopard is still a while away. Thus any apps using the features you mentioned is non-existent.
With the crap Apple pulled off with Carbon-64, it would be wise not to place any bets on finalized features in Snow Leopard till it ships!
-Ad
Edited 2009-02-15 07:42 UTC
Here’s a picture of QT4 apps in Windows XP with the so-called “native” theme.
http://static.arstechnica.com/kdewin42_dolphin-xp.png
Nuff said. They may have bindings for some of the host-system’s technologies, but they haven’t quite figured out the bindings for its UI-guidelines. I know that such things don’t matter to the Linux fandom, but the comfort factor is an important thing to mainstream users.
Yup, looks pretty much like it does under X11, but at least it looks better than a QT app on the Mac:)
That’s KDE, not plain Qt.
So let’s look at Google earth then: http://www.softpedia.com/progScreenshots/Google-Earth-Screenshot-23…
Looks plenty “native” to me. A lot more “native” than something like MSN messenger or MS Office, that’s for sure. So don’t pretend like something that looks a bit different is actually a problem. Everything looks different on windows.
Really you Apple obsessives get me down. You don’t want a parallel release of Chrome for all major platforms you want one that not only uses some of the special features of OS X but also upcoming features that are not yet even implemented.
wtf should I care we can both use Crossover Chromium until the native ports come out.
I wouldn’t be interested in running Chrome on any system, if it would be a cross-platform Qt application. Not because I have anything against Qt, it’s a great toolkit and I generally love using applications using it. But the browser is a different thing. Chrome is not filling any holes, there are fantastic native browsers on any platform, and then there is Firefox.
The one selling point Chrome really has, is that it works that tiny bit faster and slicker than every other browser. It’s not any big feature that makes the difference with Chrome, it’s the tiniest details in the user interface and performance.
Much of the Chrome interface is already custom anyway, and a native port gives them the control they need to make it work just right for the browser, while also respecting platform standards. If Chrome would use exactly the same interface on Mac and Linux however, I wouldn’t want to use it, period (Firefox has exactly that problem, they band-aid the major issues, but smaller issues always remain).
I am very much looking forward to the Mac port of Chrome. A fast, native browser that beats Safari in ergonomics? I’m sold! Neither Safari nor Firefox make me entirely happy right now, but yet another cross-platform browser wouldn’t even be a competition.
On Linux/GNOME I am very curious what they will do, but I think it will be the hardest platform for them to get right.
When I read this news item my first thought was that QT would have been a better choice. Now that I have spent time and thought about it though really all I have left is apathy. I still think it might have been wiser to start with QT which would have made Windows and Linux easier at least. OS X I might still port because I find QT apps not quite right on OS X.
However the team has decided to use three API’s for the three target platforms so they might as well use the one they are most comfortable with. Further GTK+ apps are in general more ubiquitous. As someone else (sbergman?) mentioned, it is quite common for a KDE user to use GTK apps (FF in particular). It is less common for a Gnome user to use QT apps. So if GTK will get the product out faster for them than great. If the application itself is fast, even better.
I do not think the whole “the app speaks with an accent” argument floats though. Chrome does not look or behave like most windows apps. It was a conscious and premeditated decision to make the interface not fit the mold of the typical windows app, so even on the original platform (Windows) Chrome speaks with a “foreign accent.”
The Chrome team wrote their own extension of the windows layout framework for pities sake. This is being scrapped entirely from the OS X port and is of unknown status for the Linux port. It is sounding more and more like three browsers with a common engine and presumably theme for look and feel than one browser ported to three platforms. Just bring it to Linux soon please?
I think that is the idea. Chrome will be a native browser on each platform, with a common rendering engine.
I think that the reasoning for that has to be with what Google wants to achieve with Chrome:
* A browser that is light and fast. A cross platform toolkit would probably be slower
* A browser that uses multiple processes for each tab. For this, they plan to use what the OS offers, instead of developing something that would then have to work across each platform. I’m sure this would have been a pretty major undertaking.
GTK is a cross-platform toolkit.
Does it really matter which toolkit has been selected, as long as it’s a popular one? GTK is a good choice, Qt would have also been a good choice. In any case, we’re getting a native Linux version and I’m sure the Qt fans will be able to implement an optional Qt interface for Chrome that you can enable by doing “./configure –enable-qt –disable-gtk”.
What really matters is: Will Chrome for Linux be fast, will it render pages and run Javascripts correctly, will it accept D’n’D to and from KDE and Gnome programs, will it integrate with the accessibility features of both desktops, will it be stable and reliable, and how quickly will distributions adopt it or at least have it in their repositories?
That’s what matters. Not what interface toolkit it uses. Most people run a mixed desktop anyway (GTK or GTK-alike programs on KDE, or Qt/KDE programs on Gnome/XFCE).
People keeps repeating this “lowest common denominator” thing here.
First of, it is not a “use only what is available on Qt and nothing else” question. I bet most of people that used this argument here never used Qt or even wrote a multi-platform application. The real question is how much code you have to add on each platform to conquer your goals, i.e., your compromise on write more or less code, be more or less integrated on each platform and use more or less of its “sugar”.
I have nothing against them picking Gtk+, is their project and if done right it will be useful to me, I guess, but lets face it, they will for sure write more code. And to the vocals gnome users here, remember, it will be a Gtk+ application and as so have implications on how well integrated it will be in your desktop. (I actually expend most of my time on low resources environments theses days, just to put things on perspective)
Now, what about long term maintenance of the code? Well, I can talk about my experience only. C++ GUI applications are more resilient to updates on underpinnings than C only and usually easier to extend when more features arrive (from a source point of view). I think this deserves a new thread and lots of data to see if it hold water on a larger audience, but it does for me, specially when dealing with Gtk+ and Qt.
And last, but not least: will them follow the OOo and Firefox path (i.e., create a new, “internal” layer to isolate most of differences they can on each system)? I they do, they will be creating the same kind of problems we face on former apps: new layer that will stuff the code and more errors to be squashed on doing so. Should them follow this path, I really would suggest them embracing Qt and help it improve its multiplatform characteristics fixing bugs and asking changes, this way lots of projects would be beneficed altogether.
You’ve managed to adequately explain the whole situation (again), but there are still people around here who still do not and never will understand what it actually takes to write cross-platform applications. Hell, even a lot of developers have had idealistic notions of being able to port their toolkit to wrap each native API and they still refuse to admit that they’ve failed to create something that works reliably.
There are always trade-offs, and you have to identify what your lowest common denominator is and then choose to add platform specific features that preferably aren’t going to impact that core code. It’s hard enough writing an application for one platform! You are best off letting the toolkit handle that common denominator of things you want to work over all platforms and then add your own features on top. Qt’s still the best option there. But, whatever.
It’s no skin off my nose what Google uses, but we all know we’re going to get an inferior Linux port as we have with Firefox, Eclipse/SWT and Open Office (you can’t deny that Windows is the primary platform for them).
Open Office is yet another example of layer after layer of cross-platform ‘glue’ being added after the fact when an adequate toolkit could have been used to start off with so that code didn’t have to be written. Does anyone really think that Open Office is a quality application that has features added easily? No. I didn’t think so.
I’ll go straight to the point. GTK+ is ugly toolkit and I hate it. If I cannot use QT then I’d use Motif or anything else but GTK+. “GNU Image Manipulator Program Tool Kit Plus” just doesn’t cut it.
My first argument is that it wastes too much space on screen. Why does 10px font button has to have 25px edges? Using GTK+ with 120dpi fonts is just horrible experience. It’s totally unusable because you cannot see Cancel/Accept buttons on dialog because they falloff the screen. GTK+ applications do not work properly on screens smaller than 1024×768. They need 1280×1024 at least.
Can anyone explain this? Could somebody explain why Gnome still doesn’t function properly in most situation and UI is just complete mess? Even after they introduced HIG documents to help with Gnome UI design…
QT delivers. GTK+ doesn’t.
Besides C++ is better programming language than C. C is not even properly standardized on every platform.
We can see QT versus GTK+ debate best in Gnu/Linux desktops…
KDE and Konqueror do work. Gnome and Nautilus doesn’t work. Nautilus itself is most horrible file browser I’ve ever touched and is as much crap as Finder.
I’m bit sleepy so forgive me this troll.
Once again, the KDE/Qt fanboy crowd have proven themselves completely incapable of handling rejection. This happens every time a project selects anything but Qt.
To a community which handles even mild criticism so poorly, outright rejection must be totally incomprehensible. 😉
Edited 2009-02-17 06:50 UTC
Since when is GTK+ not a cross platform toolkit?
Yes, GTK+ is indeed a cross-platform toolkit. The point was that Google did not want to use the same toolkit on all three platforms because the end result is never as good as native code. In their words, the application ends up “speaking with a foreign accent”.
Instead they chose to use a different toolkit on each platform.
Edited 2009-02-19 06:59 UTC