Linked by Thom Holwerda on Sat 14th Feb 2009 12:55 UTC
Google 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+.
Thread beginning with comment 348886
To read all comments associated with this story, please click here.
Bad Mistake, But Not a Surprise
by segedunum on Sat 14th Feb 2009 14:56 UTC
segedunum
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.

"[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."....."limits what you can do to a lowest common denominator subset of what's supported by that framework on each platform."

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

Reply Score: 16

segedunum 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

Reply Parent Score: 7

QT does not get it right
by MacMan on Sat 14th Feb 2009 15:25 in reply to "Bad Mistake, But Not a Surprise"
MacMan 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.

Reply Parent Score: 4

RE: QT does not get it right
by darknexus on Sat 14th Feb 2009 15:32 in reply to "QT does not get it right"
darknexus 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.

Reply Parent Score: 4

RE: QT does not get it right
by acobar on Sat 14th Feb 2009 16:28 in reply to "QT does not get it right"
acobar 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.

Reply Parent Score: 3

RE: QT does not get it right
by Vargol on Sat 14th Feb 2009 19:42 in reply to "QT does not get it right"
Vargol 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.

Reply Parent Score: 6

RE: QT does not get it right
by adkilla on Sat 14th Feb 2009 20:21 in reply to "QT does not get it right"
adkilla Member since:
2005-07-07

You ought to try out the latest Qt 4.5 build on Mac. It even uses the Cocoa toolkit to build 64-bit apps!

Reply Parent Score: 2

RE: QT does not get it right
by segedunum on Sat 14th Feb 2009 21:59 in reply to "QT does not get it right"
segedunum Member since:
2005-07-06

On the Mac, it is about as alien looking as running a windows application in Parallels.

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.

Nothing looks right, edit boxes do not behave normally, they use very strange looking widgets.

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.

They use their own even loop, own message dispatching system...

Well yer. You don't rewrite an application for each platform to use the native loop and IPC system!

......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.

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.

Every so called 'cross platform' user interface toolkit has these kinds of problems, although none are as bad as QT on non Unix platforms.

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.

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.

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.

Reply Parent Score: 4

RE: QT does not get it right
by leos on Sat 14th Feb 2009 23:09 in reply to "QT does not get it right"
leos Member since:
2005-09-21

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.


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.

Reply Parent Score: 6

adkilla 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

Reply Parent Score: 2

Morin 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.

Reply Parent Score: 2

segedunum Member since:
2005-07-06

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.

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.

In fact, if you compare your statement and the original statement from Google, you will find that they are very similar.

No they're not.

The essential difference is that, although Qt may "get it right", that's still far behind a custom-built native GUI.

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.

You are starting from the assumption that a cross-platform application must work exactly the same on each platform.

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.

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.

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.

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.

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.

Doing so of course requires a multiple of manpower, but I am assuming that Google can afford it.

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.

Qt, on the other hand, is a valuable tool if little manpower is available, but - according to Google - this comes at a cost.

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.

Reply Parent Score: 5

grabberslasher 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).

Reply Parent Score: 1

leos Member since:
2005-09-21

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'.


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.

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.


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.

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.


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.

Reply Parent Score: 5