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+.
Post a Comment
Member since:
2008-02-10
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...
Member since:2005-08-29
Member since:2005-07-24
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
Member since:2006-01-04
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.
Member since:2005-07-24
Member since:2005-07-06
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.
Member since:2005-07-06
Citation needed. "
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'.
Member since:2005-07-24
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
Member since:2008-06-02
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.
Member since:2005-07-24
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
Member since:2008-06-02
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
Member since:2006-01-06
<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.
Member since:2009-02-15
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*.
Member since:2005-08-29
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
Member since:2007-08-17
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.
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
Member since:2006-01-04
Another good _opinion_:
http://www.purinchu.net/wp/2009/02/15/google-chrome/
Member since:2006-11-14
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
Member since:2005-09-27
Member since:2005-07-24
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).
Member since:2005-07-06
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 ;-).
Member since:2005-07-07
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.
Member since:2006-05-27
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.
Member since:2005-07-07
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.
Member since:2006-05-27
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.
Member since:2005-07-06
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.
Member since:2005-07-07
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.
Member since:2006-03-01
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
Member since:2007-08-17
Member since:2008-10-30
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...
Member since:2007-08-17
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.
Member since:2005-07-06
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.
Member since:2007-08-11
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.
Member since:2005-11-18
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.
Member since:2005-07-06
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?
Member since:2006-01-17
Member since:2008-12-26
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.
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.
RE[2]: Why QT? Why not GTK+?
Member since:2009-02-14
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.
Member since:2005-07-24
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
Member since:2005-07-06
"""
There has got to be *some* reason companies were willing to pay thousands of dollars PER DEVELOPER for Qt licenses
"""
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.
Member since:2005-07-07
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.
Member since:2005-09-21
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.
Member since:2005-07-07
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.
Member since:2005-09-21
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.
Member since:2008-07-15
Member since:2005-07-06
Member since:2005-09-21
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.
Member since:2007-02-05
Member since:2005-07-06
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.
Member since:2009-02-15
Member since:2008-07-14
http://www.vimeo.com/374006
Member since:2009-02-15
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.
Member since:2006-01-25
Member since:2007-08-17
The way I see this is an extremely bad excuse for not using QT for Chrome linux variant.
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.
Member since:
2005-07-09
Member since:
2007-12-16
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
Member since:
2005-08-12
Member since:
2005-07-06
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
RE: Bad Mistake, But Not a Surprise
Member since:2005-07-06
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
Member since:2006-11-19
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.
Member since:2008-07-15
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.
Member since:2006-02-28
Member since:2005-11-15
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.
Member since:2006-11-19
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.
Member since:2008-12-26
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.
Member since:2009-02-15
Member since:2006-02-28
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.
Member since:2005-07-07
Member since:2006-11-19
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.
Member since:2005-07-07
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
Member since:2006-11-19
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
Member since:2005-07-11
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.
Member since:2005-07-06
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.
Member since:2005-09-21
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.
Member since:2005-07-07
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
Member since:2005-12-31
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.
Member since:2005-07-06
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.
Member since:2006-07-30
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.
Member since:2006-02-09
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).
Member since:2005-09-21
Non-native apps stick out nastily - you can nearly always tell it's 'different'.
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.
Member since:2008-07-14
Member since:
2005-06-29
RE: Comment by Thom_Holwerda
Member since:2006-02-20
Make a Linux version of your software - receive flak from the community for not picking the toolkit du jour.
I love the Linux community
. 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.
Member since:2008-03-17
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.
Member since:2005-07-06
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.
Member since:2006-06-03
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
Member since:
2008-07-15
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.
Member since:2005-06-29
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.
Member since:2005-11-12
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.
Member since:2006-09-27
Member since:2005-07-06
Member since:2005-07-06
Member since:2005-07-01
Member since:2006-05-27
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.
Member since:2006-06-03
Member since:2005-07-06
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 ;-).
Member since:2005-06-29
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.
Member since:2006-03-16
Ofc it will.
http://en.wikipedia.org/wiki/Ben_Goodger
Member since:2005-07-06
Member since:2005-07-06
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?
Member since:2007-02-05
Member since:2009-02-15
Member since:2007-08-24
Member since:2008-07-15
Member since:2008-10-21
How about Midori it uses WebKit also.
http://www.twotoasts.de/index.php?/pages/midori_summary.html
Member since:2005-07-20
Member since:
2008-07-14
Member since:
2009-02-07
Member since:
2006-10-02
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.
Member since:2008-07-14
Member since:2005-07-24
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
Member since:2005-07-24
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
Member since:2005-07-24
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.
Member since:2005-07-24
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).
Member since:2005-07-24
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
Member since:2008-07-14
Member since:2005-07-20
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
Member since:2005-07-24
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.
Member since:2007-08-24
Member since:2005-09-21
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).
Member since:
2006-01-22
Member since:2005-06-30
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.
Member since:2007-02-05
Member since:
2005-07-13
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...
Member since:
2009-02-14
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.
Member since:
2006-02-20
Member since:
2009-02-14
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.
Member since:2005-07-24
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.
Member since:2009-02-14
Member since:2005-07-24
Member since:2008-12-26
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.
Member since:2005-07-24
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
Member since:2008-07-15
Member since:2008-12-26
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).
Member since:2005-07-24
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.
Member since:2005-09-21
QT always seems to be presented as the "shiny" solution. But where are the results?
Well google earth is pretty awesome. Any evidence that there are major problems with it or are you just making stuff up now?
Member since:2008-12-26
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++?
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).
Member since:2005-07-06
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+.
Member since:
2008-06-29
Member since:2005-07-06
Member since:
2005-11-02
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.
Member since:2006-06-02
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.
Member since:2005-07-07
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
Member since:2006-06-02
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.
Member since:2006-11-19
Member since:2005-09-21
http://static.arstechnica.com/kdewin42_dolphin-xp.png
Nuff said.
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.
Member since:2005-11-02
Really -- the Linux brigade should be grateful that Google are even bothering to do more than a simple Wine-port.
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.
Member since:2005-07-08
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.
Member since:
2005-07-06
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?
Member since:2006-07-30
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.
Member since:2005-08-18
Member since:
2008-05-26
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).
Member since:
2005-11-15
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.
Member since:2005-07-06
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.
Member since:
2008-02-10
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 1024x768. They need 1280x1024 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. 
Member since:
2005-07-06
Member since:2005-07-24
Member since:
2008-10-24
Member since:2005-07-06
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