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+.
Order by: Score:
Why not QT?
by AnXa on Sat 14th Feb 2009 13:44 UTC
AnXa
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...

Reply Score: 12

RE: Why not QT?
by averycfay on Sat 14th Feb 2009 13:50 UTC in reply to "Why not QT?"
averycfay Member since:
2005-08-29

They didn't say that QT was bad... they said they wanted to use the native toolkit. So the question is: what is the native toolkit on Linux? While it's not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".

Reply Score: 5

RE[2]: Why not QT?
by sbergman27 on Sat 14th Feb 2009 14:45 UTC in reply to "RE: Why not QT?"
sbergman27 Member since:
2005-07-24

While it's not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".

Well, that ought to upset a number of people here. :-)

I'm wondering how many of them will show up to "debunk" your assertion, and "prove" it's just a dirty rotten lie spread by Gnome fans. I suspect that there are at least ten essays under construction even as I write this. So you might want to inspect your asbestos underwear for any imperfections, and maybe borrow a few shuttle tiles from NASA.

Edited 2009-02-14 14:46 UTC

Reply Score: 6

RE[2]: Why not QT?
by kragil on Sat 14th Feb 2009 14:47 UTC in reply to "RE: Why not QT?"
kragil Member since:
2006-01-04

gtk/gnome has more users than qt/kde


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.

Reply Score: 13

RE[3]: Why not QT?
by sbergman27 on Sat 14th Feb 2009 15:14 UTC in reply to "RE[2]: Why not QT?"
sbergman27 Member since:
2005-07-24

...Chrome was meant for windows and then after the fact they decided to go x-platform.

Citation needed.

Edited 2009-02-14 15:14 UTC

Reply Score: 2

RE[4]: Why not QT?
by Kokopelli on Sat 14th Feb 2009 15:51 UTC in reply to "RE[3]: Why not QT?"
Kokopelli Member since:
2005-07-06

The way I see it, Chrome was meant for windows and then after the fact they decided to go x-platform.


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.

Reply Score: 9

RE[4]: Why not QT?
by andrewg on Sat 14th Feb 2009 16:20 UTC in reply to "RE[3]: Why not QT?"
andrewg Member since:
2005-07-06

"...Chrome was meant for windows and then after the fact they decided to go x-platform.

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

Reply Score: 2

RE[5]: Why not QT?
by sbergman27 on Sat 14th Feb 2009 16:40 UTC in reply to "RE[4]: Why not QT?"
sbergman27 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

Reply Score: 2

RE[4]: Why not QT?
by BallmerKnowsBest on Sat 14th Feb 2009 17:18 UTC in reply to "RE[3]: Why not QT?"
BallmerKnowsBest Member since:
2008-06-02

Citation needed.


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.

Reply Score: 2

RE[5]: Why not QT?
by sbergman27 on Sat 14th Feb 2009 18:42 UTC in reply to "RE[4]: Why not QT?"
sbergman27 Member since:
2005-07-24

You know, it's generally a good idea to read a post before replying to it.

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

Reply Score: 0

RE[6]: Why not QT?
by BallmerKnowsBest on Mon 16th Feb 2009 01:41 UTC in reply to "RE[5]: Why not QT?"
BallmerKnowsBest Member since:
2008-06-02

A very interesting reply, all things considered. And your interest in this is?


Relevance?

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.


If you want to rely on inane assumptions, be my guest.

Do you have some *legitimate* interest in this thread?


At least as much as you do, dear.

Edited 2009-02-16 01:42 UTC

Reply Score: 1

RE[3]: Why not QT?
by bnolsen on Sat 14th Feb 2009 15:23 UTC in reply to "RE[2]: Why not QT?"
bnolsen 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.

Reply Score: 5

RE[4]: Why not QT?
by ardor on Sun 15th Feb 2009 11:54 UTC in reply to "RE[3]: Why not QT?"
ardor 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*.

Reply Score: 3

RE[3]: Why not QT?
by averycfay on Sat 14th Feb 2009 16:33 UTC in reply to "RE[2]: Why not QT?"
averycfay 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

Reply Score: 7

RE[4]: Why not QT?
by steogede2 on Mon 16th Feb 2009 15:00 UTC in reply to "RE[3]: Why not QT?"
steogede2 Member since:
2007-08-17

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.


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

Reply Score: 3

RE[3]: Why not QT?
by kragil on Sun 15th Feb 2009 21:30 UTC in reply to "RE[2]: Why not QT?"
kragil Member since:
2006-01-04
RE[2]: Why not QT?
by mtzmtulivu on Sat 14th Feb 2009 14:51 UTC in reply to "RE: Why not QT?"
mtzmtulivu Member since:
2006-11-14

(...) gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".


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

Reply Score: 10

RE[3]: Why not QT?
by Hiev on Sat 14th Feb 2009 14:58 UTC in reply to "RE[2]: Why not QT?"
Hiev Member since:
2005-09-27

I think is more related to Nokia being the competence of Google (Android vs Qt movil).

Anyway, Im pleased they used GTK+, is light fast and well integrated with Linux. Thank you google.

Reply Score: 5

RE[4]: Why not QT?
by J. M. on Sat 14th Feb 2009 16:47 UTC in reply to "RE[3]: Why not QT?"
J. M. Member since:
2005-07-24

Anyway, Im pleased they used GTK+, is light fast and well integrated with Linux. Thank you google.


This is the weirdest comment on GTK+ I've ever seen. GTK+ is anything but fast and light. Speed has always been the primary reason not to use GTK+ (and to use something faster, like Qt), as it is one of the slowest and heaviest GUI toolkits available. When people decide to use GTK+, it is always *despite* its performance, not because of it. People pick GTK+ because it is such a widespread toolkit, the de facto standard on Linux, and licensed under the LGPL (which, before Nokia announced that Qt 4.5 will be LGPLed, too, was the only real advantage for many people).

Reply Score: 5

RE[2]: Why not QT?
by segedunum on Sat 14th Feb 2009 14:56 UTC in reply to "RE: Why not QT?"
segedunum Member since:
2005-07-06

They didn't say that QT was bad... they said they wanted to use the native toolkit.

What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?

While it's not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".

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

Reply Score: 8

RE[3]: Why not QT?
by abraxas on Sat 14th Feb 2009 15:36 UTC in reply to "RE[2]: Why not QT?"
abraxas Member since:
2005-07-07

What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?


Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.

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.


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.

Reply Score: 2

RE[4]: Why not QT?
by dnas.dnas on Sat 14th Feb 2009 18:58 UTC in reply to "RE[3]: Why not QT?"
dnas.dnas Member since:
2006-05-27

I think you're confused. Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+ which will make the interface much more consistent with other GNOME/GTK+ applications.


This is not quite true.

Firefox suffers from trying to hook into parts of GTK+. Unfortunately, GTK+ isn't very well-designed, so it is not possible to tell it to draw a random widget. The drawing API has no way of expressing "get me a picture of a GtkButton at this size". The background color must be premultiplied and most themes require an actual instance of a widget as the detail string isn't well-specified. The result is that, whenever Firefox needs to draw a widget, it must have a hidden instance of that widget, and then it must draw it twice, on both black and white background. Then the pixmaps get pulled over from the X server, every pair of pixel is compared in software to recover the original alpha, the image is sent back to the X server, and only then can it be displayed. QGtkStyle has a similar problem and caches all the pixmaps --- I imagine Firefox does the same.

For added fun, since GTK+ was never designed to be embedded into anything, many themes assume they draw their own background and that's why some of them draw ugly borders at the corners of buttons in Firefox.


SWT suffers from another problem. Unlike Firefox, they actually use GTK+ directly, but wrap it in a cross-platform API. Unfortunately, the SWT widget model is slightly different from GTK+'s (it instead matches that of... pretty much every toolkit on the planet). GTK+ itself isn't very flexible, so SWT has to do many many hacks to get around this. As a result, it gets double the performance hit: once for using GTK+ at all and once more for the hacks.

Reply Score: 12

RE[5]: Why not QT?
by abraxas on Sat 14th Feb 2009 22:42 UTC in reply to "RE[4]: Why not QT?"
abraxas 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.

Reply Score: 2

RE[6]: Why not QT?
by dnas.dnas on Sun 15th Feb 2009 08:19 UTC in reply to "RE[5]: Why not QT?"
dnas.dnas 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.

Reply Score: 4

RE[4]: Why not QT?
by segedunum on Sat 14th Feb 2009 21:43 UTC in reply to "RE[3]: Why not QT?"
segedunum Member since:
2005-07-06

Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.

Hmmmm. So it's 'native'..........to Windows? Kind of the point really. It tries to be native, but it isn't at all.

Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+....

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.

...which will make the interface much more consistent with other GNOME/GTK+ applications.

That won't happen, because they will have to make cross-platform trade-offs to make it work across all platforms.

Reply Score: 5

RE[5]: Why not QT?
by abraxas on Sat 14th Feb 2009 22:48 UTC in reply to "RE[4]: Why not QT?"
abraxas Member since:
2005-07-07

Hmmmm. So it's 'native'..........to Windows? Kind of the point really. It tries to be native, but it isn't at all.


The GUI isn't native looking but the underlying libraries are specific to Windows.

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.


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

That won't happen, because they will have to make cross-platform trade-offs to make it work across all platforms.


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.

Reply Score: 2

RE[2]: Why not QT?
by silix on Sat 14th Feb 2009 15:15 UTC in reply to "RE: Why not QT?"
silix Member since:
2006-03-01

They didn't say that QT was bad... they said they wanted to use the native toolkit. So the question is: what is the native toolkit on Linux?
interestingly, the answer is none, since unix' (and then linux') gui system has been designed the way it is (i.e. as modular as it can be, with widget look and feel implemented at the toolkit level) just to avoid being tied to a single toolkit, thus to have no "native", privileged, toolkit

if there's a native toolkit on unix/linux, that may have been AWT, but nobody has used it for ages and it has afaik been deprecated in 7.x Xorg releases -
apart from that, the next layer in the stack, ie the X11 protocol binding (Xlib or XCB )used to be considered the native gui library
but at a time high level widget libraries are designed to be crossplatform, and are given non-X11 rendering backends even on linux, that doesnt hold true any longer

Edited 2009-02-14 15:22 UTC

Reply Score: 3

RE[3]: Why not QT?
by steogede2 on Mon 16th Feb 2009 14:38 UTC in reply to "RE[2]: Why not QT?"
steogede2 Member since:
2007-08-17

if there's a native toolkit on unix/linux, that may have been AWT

Isn't AWT the Java Abstract Windowing Toolkit? or is there some other AWT that I am not aware of?

Reply Score: 2

RE[2]: Why not QT?
by puelocesar on Mon 16th Feb 2009 11:52 UTC in reply to "RE: Why not QT?"
puelocesar 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...

Reply Score: 2

RE[3]: Why not QT?
by steogede2 on Mon 16th Feb 2009 14:34 UTC in reply to "RE[2]: Why not QT?"
steogede2 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.

Reply Score: 0

RE[4]: Why not QT?
by dagw on Mon 16th Feb 2009 14:52 UTC in reply to "RE[3]: Why not QT?"
dagw Member since:
2005-07-06

Though I suppose you could argue that it is the native toolkit for GNOME it is, after all, the GNOME Tool Kit.

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.

Reply Score: 5

RE[2]: Why not QT?
by pixel8r on Tue 17th Feb 2009 04:17 UTC in reply to "RE: Why not QT?"
pixel8r Member since:
2007-08-11

They didn't say that QT was bad... they said they wanted to use the native toolkit. So the question is: what is the native toolkit on Linux? While it's not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".


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.

Reply Score: 3

v RE: Why not QT?
by deb2006 on Sat 14th Feb 2009 14:03 UTC in reply to "Why not QT?"
RE[2]: Why not QT?
by danieldk on Sat 14th Feb 2009 14:13 UTC in reply to "RE: Why not QT?"
danieldk Member since:
2005-11-18

That's gonna be one major obstacle for Qt in the future. Do you trust Nokia? Well, I don't. Not a bit. And therefore I'd advise anyone to use GTK+ when it comes to new open source software projects. It's basically the same situation before GTK+ appeared - now with Nokia only worse. Sorry.


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.

Reply Score: 12

RE[2]: Why not QT?
by segedunum on Sat 14th Feb 2009 15:06 UTC in reply to "RE: Why not QT?"
segedunum Member since:
2005-07-06

That's gonna be one major obstacle for Qt in the future. Do you trust Nokia? Well, I don't. Not a bit.

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!"

And therefore I'd advise anyone to use GTK+ when it comes to new open source software projects. It's basically the same situation before GTK+ appeared - now with Nokia only worse. Sorry.

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?

Reply Score: 11

Why QT? Why not GTK+?
by Kwitschibo on Sat 14th Feb 2009 20:09 UTC in reply to "Why not QT?"
Kwitschibo Member since:
2006-01-17

So? Show me the point.

Qt is not the better Toolkit. It is just another Toolkit. And for all the functions Qt brings besides QT GUI there are also solutions on GTK side.

Edited 2009-02-14 20:12 UTC

Reply Score: 2

RE: Why QT? Why not GTK+?
by vivainio on Sat 14th Feb 2009 20:23 UTC in reply to "Why QT? Why not GTK+?"
vivainio 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.

Reply Score: 4

v RE[2]: Why QT? Why not GTK+?
by sbergman27 on Sat 14th Feb 2009 20:28 UTC in reply to "RE: Why QT? Why not GTK+?"
RE[3]: Why QT? Why not GTK+?
by tbscope2 on Sat 14th Feb 2009 20:31 UTC in reply to "RE[2]: Why QT? Why not GTK+?"
tbscope2 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.

Reply Score: 2

RE[4]: Why QT? Why not GTK+?
by sbergman27 on Sat 14th Feb 2009 20:38 UTC in reply to "RE[3]: Why QT? Why not GTK+?"
sbergman27 Member since:
2005-07-24

If you say that a Qt license is expensive you do not now anything

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

Reply Score: 1

RE[5]: Why QT? Why not GTK+?
by segedunum on Sat 14th Feb 2009 22:40 UTC in reply to "RE[4]: Why QT? Why not GTK+?"
segedunum Member since:
2005-07-06

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

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

Confer with your own QT advocates and try to come up with a consistent argument.

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.

Reply Score: 3

RE[5]: Why QT? Why not GTK+?
by evangs on Mon 16th Feb 2009 07:42 UTC in reply to "RE[4]: Why QT? Why not GTK+?"
evangs 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.

Reply Score: 4

RE[4]: Why QT? Why not GTK+?
by leos on Sat 14th Feb 2009 23:31 UTC in reply to "RE[3]: Why QT? Why not GTK+?"
leos Member since:
2005-09-21

Of course, if you're just an amateur developer sitting in your bedroom, it IS expensive. But it is not for companies making software.


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.

Reply Score: 4

RE[5]: Why QT? Why not GTK+?
by abraxas on Sun 15th Feb 2009 00:59 UTC in reply to "RE[4]: Why QT? Why not GTK+?"
abraxas Member since:
2005-07-07

The funny thing is, I was/am a developer sitting in my bedroom and I bought a Qt license. Yes it was fairly expensive, but it was an investment, and made my small business possible. I can say with 100% conviction based on my experience that without Qt I wouldn't have been successful with my software. Qt allowed me to produce something valuable with extremely limited resources (just me in my spare time, which isn't much). I tried other toolkits previously and they didn't allow that. It's that simple.


Yeah it's that simple if you have thousands of dollars to throw around on licesning costs but most small business owners don't. A QT license is so expensive that forgoing that expense would leave you enough money alone to start a small business and then some.

Reply Score: 2

RE[6]: Why QT? Why not GTK+?
by leos on Sun 15th Feb 2009 04:28 UTC in reply to "RE[5]: Why QT? Why not GTK+?"
leos Member since:
2005-09-21

Yeah it's that simple if you have thousands of dollars to throw around on licesning costs but most small business owners don't. A QT license is so expensive that forgoing that expense would leave you enough money alone to start a small business and then some.


That's hilarious. When I bought Qt I had a grand total of ~$4000 to my name (having just finished my undergraduate degree). I made the investment for Qt (about $1100 US with the small business discount) because I knew it was my only chance to grow my business. If I had used wxWidgets or GTK I wouldn't have a product to sell, because I couldn't be as productive (believe me I tried).

So do you have a real experience with using some toolkit to start a real business? If not, I don't see what basis you're arguing from.

Reply Score: 5

RE[3]: Why QT? Why not GTK+?
by darknexus on Sat 14th Feb 2009 20:38 UTC in reply to "RE[2]: Why QT? Why not GTK+?"
darknexus Member since:
2008-07-15

And there we have it. QT is *expensive*. Nice strategy, as the World teeters on the brink of a World-wide economic depression.

I think the correct tense would be "was." QT 4.5 has been LGPLed, remember?

Reply Score: 3

RE[3]: Why QT? Why not GTK+?
by segedunum on Sat 14th Feb 2009 22:26 UTC in reply to "RE[2]: Why QT? Why not GTK+?"
segedunum Member since:
2005-07-06

And there we have it. QT is *expensive*. Nice strategy, as the World teeters on the brink of a World-wide economic depression.

Yer, and the developer tools market is still one worth billions upon billions of dollars. Go figure.

Reply Score: 1

RE[3]: Why QT? Why not GTK+?
by leos on Sat 14th Feb 2009 23:27 UTC in reply to "RE[2]: Why QT? Why not GTK+?"
leos Member since:
2005-09-21

And there we have it. QT is *expensive*. Nice strategy, as the World teeters on the brink of a World-wide economic depression.


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.

Reply Score: 5

RE[2]: Why QT? Why not GTK+?
by TLZ_ on Sun 15th Feb 2009 08:57 UTC in reply to "RE: Why QT? Why not GTK+?"
TLZ_ Member since:
2007-02-05

GTK lacks (proper) OS X support.

Some commercial developers (Adobe) have produced QT-apps that doesn't even run Linux.

Reply Score: 3

RE: Why QT? Why not GTK+?
by l3v1 on Sat 14th Feb 2009 20:31 UTC in reply to "Why QT? Why not GTK+?"
l3v1 Member since:
2005-07-06

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.


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.

Reply Score: 3

RE: Why QT? Why not GTK+?
by ardor on Sun 15th Feb 2009 11:58 UTC in reply to "Why QT? Why not GTK+?"
ardor Member since:
2009-02-15

Show a Gtk counterpart to QGraphicsView. One that actually matches its functionality. Also, show me how to something like WolfenQt (google for it) using Gtk.

Reply Score: 2

RE[2]: Why QT? Why not GTK+?
by YEPHENAS on Sun 15th Feb 2009 12:20 UTC in reply to "RE: Why QT? Why not GTK+?"
YEPHENAS Member since:
2008-07-14

Show a Gtk counterpart to QGraphicsView. One that actually matches its functionality. Also, show me how to something like WolfenQt (google for it) using Gtk.

http://www.vimeo.com/374006

Reply Score: 1

RE[3]: Why QT? Why not GTK+?
by ardor on Sun 15th Feb 2009 13:03 UTC in reply to "RE[2]: Why QT? Why not GTK+?"
ardor 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.

Reply Score: 2

RE: Why not QT?
by aent on Sun 15th Feb 2009 20:52 UTC in reply to "Why not QT?"
aent Member since:
2006-01-25

QT and GTK now have the same licensing since Nokia bought it out.

Reply Score: 2

RE: Why not QT?
by steogede2 on Mon 16th Feb 2009 15:27 UTC in reply to "Why not QT?"
steogede2 Member since:
2007-08-17

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

Reply Score: 3

Not news
by noamsml on Sat 14th Feb 2009 13:56 UTC
noamsml
Member since:
2005-07-09

This was part of the Linux Chrome original announcement.

Reply Score: 2

Chrome
by sj87 on Sat 14th Feb 2009 14:13 UTC
sj87
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

Reply Score: 5

lowest common denominator
by JMcCarthy on Sat 14th Feb 2009 14:38 UTC
JMcCarthy
Member since:
2005-08-12

says it all.

Reply Score: 0

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

v RE: Bad Mistake, But Not a Surprise
by Hiev on Sat 14th Feb 2009 14:59 UTC in reply to "Bad Mistake, But Not a Surprise"
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 Score: 7

QT does not get it right
by MacMan on Sat 14th Feb 2009 15:25 UTC 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 Score: 4

RE: QT does not get it right
by darknexus on Sat 14th Feb 2009 15:32 UTC 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 Score: 4

RE[2]: QT does not get it right
by Vargol on Sat 14th Feb 2009 19:53 UTC in reply to "RE: QT does not get it right"
Vargol Member since:
2006-02-28

The ctril v's cmd thing is purely a developer thing.

I could make a Cocoa app that would make an OSX's user's toes curl with out there being a single line of code that was dedicated to doing so.

Reply Score: 1

RE: QT does not get it right
by acobar on Sat 14th Feb 2009 16:28 UTC 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 Score: 3

RE[2]: QT does not get it right
by MacMan on Sat 14th Feb 2009 17:08 UTC in reply to "RE: QT does not get it right"
MacMan 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.

Reply Score: 2

RE[3]: QT does not get it right
by vivainio on Sat 14th Feb 2009 19:35 UTC in reply to "RE[2]: QT does not get it right"
vivainio 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.

Reply Score: 2

RE[3]: QT does not get it right
by ardor on Sun 15th Feb 2009 12:01 UTC in reply to "RE[2]: QT does not get it right"
ardor Member since:
2009-02-15

Of all the toolkits I've used so far, Qt is the only one that was pleasant to code for. I cannot understand your comment. Perhaps you used Qt with some other different toolkit design design guidlines in mind?

Reply Score: 1

RE: QT does not get it right
by Vargol on Sat 14th Feb 2009 19:42 UTC 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 Score: 6

RE: QT does not get it right
by adkilla on Sat 14th Feb 2009 20:21 UTC 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 Score: 2

RE[2]: QT does not get it right
by MacMan on Sat 14th Feb 2009 21:11 UTC in reply to "RE: QT does not get it right"
MacMan 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.

Reply Score: 2

RE[3]: QT does not get it right
by adkilla on Sun 15th Feb 2009 06:32 UTC in reply to "RE[2]: QT does not get it right"
adkilla 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

Reply Score: 3

RE[4]: QT does not get it right
by MacMan on Sun 15th Feb 2009 19:43 UTC in reply to "RE[3]: QT does not get it right"
MacMan Member since:
2006-11-19

What do you mean it doesn't look native? Specific examples?

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

Reply Score: 1

RE[5]: QT does not get it right
by phoenix on Mon 16th Feb 2009 04:32 UTC in reply to "RE[4]: QT does not get it right"
phoenix Member since:
2005-07-11

Does not look native? well, text does not line up in edit boxes, none of the controls line up correctly, etc...


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.

Reply Score: 2

RE: QT does not get it right
by segedunum on Sat 14th Feb 2009 21:59 UTC 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 Score: 4

RE: QT does not get it right
by leos on Sat 14th Feb 2009 23:09 UTC 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 Score: 6

RE: Bad Mistake, But Not a Surprise
by adkilla on Sat 14th Feb 2009 20:18 UTC in reply to "Bad Mistake, But Not a Surprise"
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 Score: 2

RE: Bad Mistake, But Not a Surprise
by Morin on Sat 14th Feb 2009 20:45 UTC in reply to "Bad Mistake, But Not a Surprise"
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 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 Score: 5

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

Reply Score: 1

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 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 Score: 5

YEPHENAS Member since:
2008-07-14

There's a huge difference between Java and Qt though. Java doesn't even bother trying to be native.

Of course it does. The Swing SystemLookAndFeel tries to mimick the LaF on Windows, Mac OS X and Gnome/GTK+ in the same way as Qt does.

Reply Score: 1

Comment by Thom_Holwerda
by Thom_Holwerda on Sat 14th Feb 2009 15:24 UTC
Thom_Holwerda
Member since:
2005-06-29

Do not make a Linux version of your software - receive flak from the community.

Make a Linux version of your software - receive flak from the community for not picking the toolkit du jour.

I love the Linux community ;) .

Reply Score: 17

v RE: Comment by Thom_Holwerda
by FooBarWidget on Sat 14th Feb 2009 16:50 UTC in reply to "Comment by Thom_Holwerda"
RE: Comment by Thom_Holwerda
by vitae on Sat 14th Feb 2009 18:55 UTC in reply to "Comment by Thom_Holwerda"
vitae Member since:
2006-02-20

Do not make a Linux version of your software - receive flak from the community.

Make a Linux version of your software - receive flak from the community for not picking the toolkit du jour.

I love the Linux community ;) .


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.

Reply Score: 3

RE: Comment by Thom_Holwerda
by _txf_ on Sat 14th Feb 2009 19:13 UTC in reply to "Comment by Thom_Holwerda"
_txf_ 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.

Reply Score: 5

RE: Comment by Thom_Holwerda
by segedunum on Sat 14th Feb 2009 22:16 UTC in reply to "Comment by Thom_Holwerda"
segedunum Member since:
2005-07-06

Make a Linux version of your software - receive flak from the community for not picking the toolkit du jour.

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.

Reply Score: 2

RE[2]: Comment by Thom_Holwerda
by stestagg on Sun 15th Feb 2009 16:48 UTC in reply to "RE: Comment by Thom_Holwerda"
stestagg Member since:
2006-06-03

Linux is a whole world of hurt on that front


Not exactly. Distributing commercial/precompiled applications is a pretty awful experience on Linux.

But if Google include the GTK interface in Chromium, then they will not have to even lift a finger to get it distributed to all the major distributions. There are many people out there seriously interested in getting Chrome[ium] to work on linux, and there will be no shortage of people willing to create and deliver packages once it has been released

Reply Score: 2

Yes!
by darknexus on Sat 14th Feb 2009 15:29 UTC
darknexus
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.

Reply Score: 8

RE: Yes!
by Thom_Holwerda on Sat 14th Feb 2009 15:37 UTC in reply to "Yes!"
Thom_Holwerda Member since:
2005-06-29

I'm probably in the minority here, but I'm certainly pleased with their decision to use GTK+ over QT at this point


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.

Reply Score: 3

RE[2]: Yes!
by SlackerJack on Sat 14th Feb 2009 16:47 UTC in reply to "RE: Yes!"
SlackerJack 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.

Reply Score: 2

RE[3]: Yes!
by jaebird on Sat 14th Feb 2009 20:20 UTC in reply to "RE[2]: Yes!"
jaebird Member since:
2006-09-27

Says the guy who uses a Gimp avatar ;)

Reply Score: 1

RE[4]: Yes!
by l3v1 on Sat 14th Feb 2009 20:35 UTC in reply to "RE[3]: Yes!"
l3v1 Member since:
2005-07-06

Says the guy who uses a Gimp avatar ;)


I see thr smiley, still, I'm just fed up with this.

We choose apps, not toolkits.

There, you can shoot me now.

Reply Score: 2

RE[5]: Yes!
by segedunum on Sat 14th Feb 2009 22:22 UTC in reply to "RE[4]: Yes!"
segedunum Member since:
2005-07-06

We choose apps, not toolkits.

Yes we do, and toolkits and developer tools dictate applications. That's why we have precious little that attracts people in the Linux and open source world.

Reply Score: 1

RE[3]: Yes!
by Michael on Sat 14th Feb 2009 21:22 UTC in reply to "RE[2]: Yes!"
Michael Member since:
2005-07-01

I'd say it's really the job of the operating system distributor to ensure that all the GUI toolkits provided by the OS have a consistent look. Seeing as there are only really two toolkits that are widely used, that shouldn't present too much of a challenge.

Reply Score: 2

RE[3]: Yes!
by dnas.dnas on Sat 14th Feb 2009 21:51 UTC in reply to "RE[2]: Yes!"
dnas.dnas 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.

Reply Score: 2

RE[4]: Yes!
by stestagg on Sun 15th Feb 2009 16:50 UTC in reply to "RE[3]: Yes!"
stestagg Member since:
2006-06-03

There is an equivalent for GTK+, but it's hacked together by one guy, unstable, and rather badly lacking in areas


That says a lot about the demand for such a thing.

Reply Score: 2

RE[2]: Yes!
by segedunum on Sat 14th Feb 2009 22:21 UTC in reply to "RE: Yes!"
segedunum Member since:
2005-07-06

I prefer GNOME, and use only Gtk+ applications because I don't like my stuff looking out of place.

I sincerely hope you're happy with all three of them. With one button on each.

This has nothing to do with which is the better toolkit - in all honesty, I don't give a rat's bum about toolkits.

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? ;-)

I want what looks and works the best, and using a strictly Gtk+ desktop, I'm happy Google chose Gtk+

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

Reply Score: 2

RE[3]: Yes!
by Thom_Holwerda on Sat 14th Feb 2009 22:37 UTC in reply to "RE[2]: Yes!"
Thom_Holwerda Member since:
2005-06-29

Which application do you like and feel works better - Firefox on Windows or Firefox on Linux?


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.

Reply Score: 1

RE[4]: Yes!
by TQH ! on Sun 15th Feb 2009 09:35 UTC in reply to "RE[3]: Yes!"
TQH ! Member since:
2006-03-16
RE[5]: Yes!
by segedunum on Sun 15th Feb 2009 14:03 UTC in reply to "RE[4]: Yes!"
segedunum Member since:
2005-07-06

Yes I know. Netscape 6 anyone? :-)

Reply Score: 2

RE[4]: Yes!
by segedunum on Sun 15th Feb 2009 14:08 UTC in reply to "RE[3]: Yes!"
segedunum Member since:
2005-07-06

The words "firefox" and "better" need to be at least ten sentences apart

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?

Reply Score: 2

RE[3]: Yes!
by TLZ_ on Sun 15th Feb 2009 09:11 UTC in reply to "RE[2]: Yes!"
TLZ_ Member since:
2007-02-05

I think Linux works really well on both actually.

A bit too bad that Firefox can't keep it's keyhole-branding (it's practically their GUI trademark now) on Linux, but I guess that would be difficult on GTK.

Reply Score: 2

RE[2]: Yes!
by ardor on Sun 15th Feb 2009 12:04 UTC in reply to "RE: Yes!"
ardor Member since:
2009-02-15

I have good news for you then. Qt 4.5 will introduce a "GtkStyle", which will actually use Gtk internally, so all your Qt4-using apps will blend in with GNOME.

Reply Score: 2

RE: Yes!
by bloodandsoil on Sat 14th Feb 2009 15:51 UTC in reply to "Yes!"
bloodandsoil Member since:
2007-08-24

You said that you would love to be able to use non-mozilla browser on Linux.

Have you tried Epiphany with webkit? IMO, too many people overlook Epiphany.

Reply Score: 4

RE[2]: Yes!
by darknexus on Sat 14th Feb 2009 15:55 UTC in reply to "RE: Yes!"
darknexus Member since:
2008-07-15

Yep I've tried it, but it seems to crash quite a bit for me and I haven't figured out why yet.

Reply Score: 1

RE[3]: Yes!
by Kazuki on Sat 14th Feb 2009 16:46 UTC in reply to "RE[2]: Yes!"
Kazuki Member since:
2008-10-21

How about Midori it uses WebKit also.
http://www.twotoasts.de/index.php?/pages/midori_summary.html

Reply Score: 3

RE[3]: Yes!
by reinouts on Sun 15th Feb 2009 23:47 UTC in reply to "RE[2]: Yes!"
reinouts Member since:
2005-07-20

Because the WebKit backend is experimental. At the earliest it will become the supported backend in Gnome 2.28.

Reply Score: 1

Comment by YEPHENAS
by YEPHENAS on Sat 14th Feb 2009 15:41 UTC
YEPHENAS
Member since:
2008-07-14

"A Windows-clone would most definitely not be acceptable on MacOS X," Goodger says

As if it was acceptable on Linux.

Reply Score: 6

Qt rules
by ariarinen on Sat 14th Feb 2009 16:09 UTC
ariarinen
Member since:
2009-02-07

Qt is much better then GTK, so I don't see why they would pick it. With it they could develop chrome for embedded platforms plus win, linux, mac and it would still look great and be fast. And they already use Qt on Earth.

Reply Score: 1

OBVIOUS CHOICE
by bandido55 on Sat 14th Feb 2009 16:44 UTC
bandido55
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.

Reply Score: 2

RE: OBVIOUS CHOICE
by YEPHENAS on Sat 14th Feb 2009 16:53 UTC in reply to "OBVIOUS CHOICE"
YEPHENAS Member since:
2008-07-14

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?)

I can't follow you. Why would GNOME dump their default browser but KDE wouldn't?

Reply Score: 1

RE[2]: OBVIOUS CHOICE
by sbergman27 on Sat 14th Feb 2009 17:08 UTC in reply to "RE: OBVIOUS CHOICE"
sbergman27 Member since:
2005-07-24

I can't follow you. Why would GNOME dump their default browser but KDE wouldn't?

Gnome treats its default browser as the redheaded stepchild. It's quite shameful. FF is effectively both KDE's and Gnome's default browser, in the real world. Which, as an advocate of Epiphany, annoys me no end. The Epiphany crew is working hard on dumping Gecko for WebKit. I am hoping that once they get loose from depending directly upon their most direct (and unsympathetic) competitor, and are using a superior rendering and javascript engine, Epiphany will finally come into its own and get the support it deserves.

Edited 2009-02-14 17:10 UTC

Reply Score: 3

RE[3]: OBVIOUS CHOICE
by J. M. on Sat 14th Feb 2009 17:22 UTC in reply to "RE[2]: OBVIOUS CHOICE"
J. M. 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

Reply Score: 2

RE[4]: OBVIOUS CHOICE
by sbergman27 on Sat 14th Feb 2009 17:33 UTC in reply to "RE[3]: OBVIOUS CHOICE"
sbergman27 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.

Reply Score: 2

RE[5]: OBVIOUS CHOICE
by J. M. on Sat 14th Feb 2009 17:54 UTC in reply to "RE[4]: OBVIOUS CHOICE"
J. M. 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).

Reply Score: 1

RE[6]: OBVIOUS CHOICE
by sbergman27 on Sat 14th Feb 2009 18:05 UTC in reply to "RE[5]: OBVIOUS CHOICE"
sbergman27 Member since:
2005-07-24

And what more can they do about it?

Actually devote some resources to it?

but it's not GNOME's fault either

To the extent that they have ignored it, it is.

There's nothing GNOME can do about it

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

Reply Score: 3

RE[7]: OBVIOUS CHOICE
by YEPHENAS on Sat 14th Feb 2009 18:41 UTC in reply to "RE[6]: OBVIOUS CHOICE"
YEPHENAS Member since:
2008-07-14

Incompatible as it is with the web, at large

Can't be true, since Epiphany uses either Gecko or WebKit for rendering.

Reply Score: 0

RE[7]: OBVIOUS CHOICE
by reinouts on Mon 16th Feb 2009 00:03 UTC in reply to "RE[6]: OBVIOUS CHOICE"
reinouts 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

Reply Score: 1

RE: OBVIOUS CHOICE
by J. M. on Sat 14th Feb 2009 17:07 UTC in reply to "OBVIOUS CHOICE"
J. M. 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.

Reply Score: 1

RE: OBVIOUS CHOICE
by bloodandsoil on Sat 14th Feb 2009 18:04 UTC in reply to "OBVIOUS CHOICE"
bloodandsoil Member since:
2007-08-24

Why would GNOME consider dumping Epiphany? It's a fine web browser.

Reply Score: 1

RE: OBVIOUS CHOICE
by leos on Sat 14th Feb 2009 23:15 UTC in reply to "OBVIOUS CHOICE"
leos Member since:
2005-09-21

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.


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

Reply Score: 2

The use GTK+
by fithisux on Sat 14th Feb 2009 17:54 UTC
fithisux
Member since:
2006-01-22

because they possibly know it better. I do not believe they have any problem with Qt except the learning curve. GTK+ is acceptable. Nothing here to debate. I wish the Windows version used GTK+ for minimizing porting efforts.

Reply Score: 3

RE: The use GTK+
by Wrawrat on Sat 14th Feb 2009 19:35 UTC in reply to "The use GTK+"
Wrawrat 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.

Reply Score: 3

RE[2]: The use GTK+
by TLZ_ on Sun 15th Feb 2009 09:15 UTC in reply to "RE: The use GTK+"
TLZ_ Member since:
2007-02-05

I use Pidgin and although it is not perfect it feels more native than 70% of the apps on Windows.

There isn't all that much consistency on Windows, people doesn't seem to care as much about as Linux and OS X people...

Reply Score: 4

Does it really matter?
by elsewhere on Sat 14th Feb 2009 17:58 UTC
elsewhere
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...

Reply Score: 4

Bad choice
by SimLab on Sat 14th Feb 2009 18:39 UTC
SimLab
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.

Reply Score: 2

Um
by vitae on Sat 14th Feb 2009 18:52 UTC
vitae
Member since:
2006-02-20

Isn't the real question, why does Linux need Chrome when it already has Firefox, Opera, Konqueror, Epiphany, Ice Cat, and (when all else fails) Lynx?

Reply Score: 1

Google is not one company
by tbscope2 on Sat 14th Feb 2009 19:28 UTC
tbscope2
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.

Reply Score: 1

RE: Google is not one company
by sbergman27 on Sat 14th Feb 2009 20:05 UTC in reply to "Google is not one company"
sbergman27 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.

Reply Score: 1

RE[2]: Google is not one company
by tbscope2 on Sat 14th Feb 2009 20:16 UTC in reply to "RE: Google is not one company"
tbscope2 Member since:
2009-02-14

Yet... some companies do the exact opposite.

Nokia for example. Maybe a little bit too extreme as an example, but still.

Reply Score: 1

sbergman27 Member since:
2005-07-24

Yet... some companies do the exact opposite. Nokia for example.

Because they bought out a competing toolkit for a song, and then put out some encouraging press releases to appease the bought up natives? Where are the products?

Edited 2009-02-14 20:24 UTC

Reply Score: 2

RE[4]: Google is not one company
by vivainio on Sat 14th Feb 2009 20:49 UTC in reply to "RE[3]: Google is not one company"
vivainio Member since:
2008-12-26

Because they bought out a competing toolkit for a song, and then put out some encouraging press releases to appease the bought up natives? Where are the products?

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.

Reply Score: 1

sbergman27 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

Reply Score: 2

RE[6]: Google is not one company
by darknexus on Sat 14th Feb 2009 20:59 UTC in reply to "RE[5]: Google is not one company"
darknexus Member since:
2008-07-15

Sorry, didn't mean to sound harsh, was just pointing out that QT 4.5 is going to be licensed under the LGPL. Therefore, it's not expensive anymore. I'm not Pro QT, I'm Pro GNOME, just interested in having the most accurate info possible out there.

Reply Score: 2

RE[6]: Google is not one company
by vivainio on Sat 14th Feb 2009 21:06 UTC in reply to "RE[5]: Google is not one company"
vivainio Member since:
2008-12-26

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?

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

Reply Score: 2

sbergman27 Member since:
2005-07-24

If anything, Qt development is moving to a more open model with LGPL license

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.

Reply Score: 2

RE[2]: Google is not one company
by leos on Sat 14th Feb 2009 23:24 UTC in reply to "RE: Google is not one company"
leos Member since:
2005-09-21

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?


Well google earth is pretty awesome. Any evidence that there are major problems with it or are you just making stuff up now?

Reply Score: 4

RE: Google is not one company
by vivainio on Sat 14th Feb 2009 20:16 UTC in reply to "Google is not one company"
vivainio Member since:
2008-12-26

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++?


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

Reply Score: 3

RE: Google is not one company
by j-kidd on Sun 15th Feb 2009 00:15 UTC in reply to "Google is not one company"
j-kidd Member since:
2005-07-06

Google Earth is made with Qt. Why did they choose Qt and not GTK+?


Perhaps it is because they can make sane choice ;)

Are the developers that create Google Earth more familiar with Qt and/or C++?


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

Reply Score: 1

freebsd port?
by zenulator on Sat 14th Feb 2009 20:17 UTC
zenulator
Member since:
2008-06-29

What about freebsd? Talk about Linux not getting any love. Seriously any port to Linux is better than none at all.

Reply Score: 2

RE: freebsd port?
by Moulinneuf on Sat 14th Feb 2009 20:47 UTC in reply to "freebsd port?"
Moulinneuf Member since:
2005-07-06

FreeBSD can use Gnome ... Funny how a BSD software don't work or is not even considered natively for BSD ;-)

Edited 2009-02-14 20:48 UTC

Reply Score: 1

QT4 apps on Gnome
by chemical_scum on Sat 14th Feb 2009 23:18 UTC
chemical_scum
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.

Reply Score: 5

RE: QT4 apps on Gnome
by nobody on Sun 15th Feb 2009 00:50 UTC in reply to "QT4 apps on Gnome"
nobody 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.

Reply Score: 2

RE[2]: QT4 apps on Gnome
by adkilla on Sun 15th Feb 2009 07:39 UTC in reply to "RE: QT4 apps on Gnome"
adkilla Member since:
2005-07-07

Does QT4 support Core Data or the upcoming Grand Central for example?

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

Reply Score: 3

RE[3]: QT4 apps on Gnome
by nobody on Sun 15th Feb 2009 23:01 UTC in reply to "RE[2]: QT4 apps on Gnome"
nobody 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.

Reply Score: 3

RE[4]: QT4 apps on Gnome
by MacMan on Sun 15th Feb 2009 23:09 UTC in reply to "RE[3]: QT4 apps on Gnome"
MacMan Member since:
2006-11-19

Yup, looks pretty much like it does under X11, but at least it looks better than a QT app on the Mac:)

Reply Score: 2

RE[4]: QT4 apps on Gnome
by leos on Mon 16th Feb 2009 00:29 UTC in reply to "RE[3]: QT4 apps on Gnome"
leos Member since:
2005-09-21

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.


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.

Reply Score: 5

RE[2]: QT4 apps on Gnome
by chemical_scum on Sun 15th Feb 2009 13:11 UTC in reply to "RE: QT4 apps on Gnome"
chemical_scum Member since:
2005-11-02

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.


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.

Reply Score: 2

RE: QT4 apps on Gnome
by Daniel Borgmann on Sun 15th Feb 2009 14:14 UTC in reply to "QT4 apps on Gnome"
Daniel Borgmann 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.

Reply Score: 2

Honestly, is it a big deal?
by Kokopelli on Sun 15th Feb 2009 04:28 UTC
Kokopelli
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? ;)

Reply Score: 2

RE: Honestly, is it a big deal?
by arpan on Sun 15th Feb 2009 07:51 UTC in reply to "Honestly, is it a big deal?"
arpan 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.

Reply Score: 1

Soulbender Member since:
2005-08-18

A browser that is light and fast. A cross platform toolkit would probably be slower


GTK is a cross-platform toolkit.

Reply Score: 2

Does the toolkit really matter?
by 3rdalbum on Sun 15th Feb 2009 08:38 UTC
3rdalbum
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).

Reply Score: 2

Lots of nonsense
by acobar on Sun 15th Feb 2009 09:32 UTC
acobar
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.

Reply Score: 3

RE: Lots of nonsense
by segedunum on Sun 15th Feb 2009 13:48 UTC in reply to "Lots of nonsense"
segedunum 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.

Reply Score: 4

Qt versus GTK+
by AnXa on Sun 15th Feb 2009 23:22 UTC
AnXa
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. ;)

Reply Score: 0

Fanboys *sigh*
by kelvin on Tue 17th Feb 2009 06:43 UTC
kelvin
Member since:
2005-07-06

Once again, the KDE/Qt fanboy crowd have proven themselves completely incapable of handling rejection. This happens every time a project selects anything but Qt.

Reply Score: 1

RE: Fanboys *sigh*
by sbergman27 on Tue 17th Feb 2009 06:50 UTC in reply to "Fanboys *sigh*"
sbergman27 Member since:
2005-07-24

Once again, the KDE/Qt fanboy crowd have proven themselves completely incapable of handling rejection.

To a community which handles even mild criticism so poorly, outright rejection must be totally incomprehensible. ;-)

Edited 2009-02-17 06:50 UTC

Reply Score: 2

Cross Platform Toolkit
by Codester on Wed 18th Feb 2009 23:49 UTC
Codester
Member since:
2008-10-24

Since when is GTK+ not a cross platform toolkit?

Reply Score: 1

RE: Cross Platform Toolkit
by kelvin on Thu 19th Feb 2009 06:58 UTC in reply to "Cross Platform Toolkit"
kelvin 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

Reply Score: 2