I just read an article on Ars about Google Chrome for Linux where Ryan Paul writes:
"After extensive discussion, the Chromium developers decided to build the Linux port with GTK+, the toolkit that is used by the popular GNOME desktop environment. This will eventually make it look and feel somewhat native on GNOME-based Linux distributions, such as Ubuntu."
The rest of the article goes on to document the woes of developing on Linux, including Ben Goodger's "situation is a clusterf*ck" comment about developing on Linux. It was the above quote that really struck me, though, as it's the right idea (to "fit in") meeting a less-right idea ("ergo we ought to use Gtk+").
The mistake isn't so much in using Gtk+ itself (I know a number of people who really like working with it and there are some great apps written using it), but rather in expecting the use of Gtk+ to make an app fit in well on the Linux (let alone the broader F/OSS) desktop or feeling that you have to make a choice to target one desktop system and forgo the rest.
There's a much better solution: choose them all by using Qt.
Qt does quite a bit to Work Natively(tm) for you these days, right down to using the platform's widget styles, file dialogs and even dialog button orders (Ok/Cancel vs Cancel/Ok) without any special application code or user settings. That means you'll look and work native on Windows, Mac, KDE and GNOME if you write using Qt. On Linux, one binary gives you the Qt, KDE and GNOME looks all in one go.
So instead of Chrome looking and feeling native at some point on one desktop, it could look and feel native on them all. This is due to the Qt development team caring deeply about the whole platform, not just pieces of it. Gtk+ strives to do well in its own world, but that's where it basically ends. For that reason, if you want your app to look good on F/OSS desktops regardless of what is being used, you probably want to be using Qt.
And Ben G.: people glow on a regular basis about how they can make the coolest looking UIs using Qt.
(You have to read the Ars article to get that last one. :)
50 comments:
We all known the reson for that.
The Gtk+ have a shit support for crss-development, unlike Qt4.
If they choose to develop it using the Qt, there a probability that someone fork it and create a awesome browser that run in all plataforms, including the Windows.
And Google don´t want that. They want to control at least the windows one, so they can ship with how many spyware, track-ware .... what they want.
So they develop the open-source branch using something to keep it closed on linux. Or looking zoobie in any other plataform.
I agree with you completely. Much props. You know the reason it's going to be in Gtk+ because "everyone uses Ubuntu". And you can't argue about that.
I personally don't see what Gtk+ offers that Qt4 doesn't? Nothing, it just offers a ton of disadvantages. Last time I used Gtkmm, it wasn't fully supported, the documentation totally lacks, very confusing, and when was the last time you seen an up to date version on Windows of Gtk+, Gtkmm unless you compiled yourself, then again that is a total pain.
It's not as if they're using GTK+ widgets heavily, either. They are doing quite a bit of the actual drawing themselves.
But, I don't really feel Qt apps look & feel native while running under GNOME here. Am I missing something obvious?
http://kov.eti.br/~kov/gnome-qt.png
As for why GTK+, I tend to agree with ComaWhite there: the 'Linux' users they are targetting are those who use Ubuntu, and GNOME.
@Bruno: i don't think it's a conspiracy or malice, just our own fault for not spreading the word broadly enough that Qt is the best-of-breed cross platform toolkit, bar none, regardless of your target platform. so people make logical, but ill-informed, decisions which turn out to be sub-par.
@ComaWhite: "You know the reason it's going to be in Gtk+ because "everyone uses Ubuntu". And you can't argue about that."
well, that's actually untrue (KDE has single deployments that are bigger than the entire Ubuntu user base; not all Ubuntu installs are desktops; not all Ubuntu installs are GNOME; etc..)
but it, of course, misses the point that you can satisfy GNOME users _and_ non-GNOME users instead of only GNOME users.
@Gustavo: when in GNOME, it should be using the new QtGtkStyle (and the icon theme set to whatever the desktop in question is using).
Man, I've been thinking the exact same thing since the initial announcement of Google Chrome more than a year ago. I was dismayed that they weren't using Qt - and I guessed even then that because of this, the linux version would end up getting less attention and fewer resources. Sure enough, a year later development is only starting to move. The technical reasons stated for not using Qt weren't entirely valid either.
you and your damn birthday suit! Put it away already! :)
And Love? I will tell you what i tell my daycare children. Take your attitude and put it in your pocket.
@Arron
Yeah a little pun there. Well I know not /everyone/ uses Ubuntu, I use Gentoo ;P. But if you was managed to get a linux pc (if you can without windows). You're more than likely given a Ubuntu disk. And novice linux users are often of the time, suggested Ubuntu because of the simplicity.
@I Love
Yeah, I bet if Google did go to Qt, I bet you be complaining "Why oh why they didn't use Gtk+", it's pretty biased. But then again, what does Gtk+ offer that Qt doesn't?
Still it's very frustrating that Gtk+ developers don't give a crap about how bad the Gtk+ apps look in KDE, but many developers still think about it as THE Linux toolkit
Smart ass Chrome developer chooses GTK because he has some experience with it, and masks it by saying something like "we want our browser to be fully native, and not speak a foreign language".
The next day the smart ass developer notices that maybe GTK is not that good after all, well what would be the best thing to do?
Well he should admit that he was wrong and ignorant, when he made the choice.
Did he do that?
No, he said that "linux sux" just because there are stuff, he couldn't do with GTK.
Well no we have both ignorance and arrogance at the same time, the only sad thing is, that this is coming from google.
Can anyone explain to me how google can consistently fail to figure out that there is a better option (Qt) instead of coding all their applications in strange, unusual, and ineffective ways?
Google Earth uses QT, isn't it? So Google devs (at least those who are developing GEarth) should know very well the QT framework.
Do you really think that the choice of GTK+ in Chrome was done for a lack of information about QT?
@gustavo:
"But, I don't really feel Qt apps look & feel native while running under GNOME here. Am I missing something obvious?"
what version of qt is? it really works only since 4.5 (actually using gtk to draw)
with older versions you can use the cleanlooks qt theme that is somewhat similar even if not identic (set it with qtconfig command)
Strangest of all, Google already relies very much on QT for Google Earth...
http://www.qtsoftware.com/qt-in-use/story/app/google-earth
But GE was bought and not started in in house.
I think we should remember that we are talking about Chromium/Crome, that is a codebase that produces a software that is free and one that is closed source.
So they needed a toolkit under the LGPL, and IIRC QT wasn't LGPL back then.
Yes, they could have bought a license for closed source development, but they probably thought it wasn't worth it for something that would be included only in a small portion of the interface.
I have to admit I did find the choice odd but it must have been because he had experience with Gtk+ from his Mozilla days. That said if his previous experience was negative and there's only two real choices when why didn't he investigate QT.
As a matter of interest (hopefully not flame insighting) as the Windows version was an attempt to make a browser as fast as possible was the native Windows toolkit any faster than QT?
I remember when Google first announced that they are to use Gtk+ for Linux and Cocoa on Mac. There were some FUD going around that announcement -- like using Qt will limit developers in something or Gtk+ is easier to use... Well, here is that announcement actually: http://groups.google.com/group/chromium-dev/msg/f3507e2ded99b354?pli=1
Then I found a FAQ on Chromium site, it honestly stated that Chromium developers use Gtk+ because they had experiecne earlier with it and know it better than anything else. Also Ben G. was involved with developing Firefox in past, that's why he is biased towards Gtk+
@Skarn86
I don't know how license issue would be a problem if it's open source and what not?
@Skarn86
Trolltech announced its intention to move to LGPL in January and the Chrome toolkit choice was announced in Feb. Its pretty clear it was chosen as he had experience of it in the past from Mozilla and chose not to try QT properly before finding out that GTK didn't do what he wanted all that well but stuck with the GTK choice as he had already made his announcement.
I was curious about the GTK-over-Qt choice also. I figured it probably had to do with something related to Qt licensing. The story has changed since the Chromium port began I'm sure - I wonder if anyone has started a fork of Chromium+Qt?
I'm primarily paid to write applications for Windows, which typically means MFC. At a previous job, I had evaluated but not used Gtk, Qt, WxWidgets, and more in looking at cross-platform development; and while researching was quickly sold on the signals-slots concept.
Recently I (finally) had the opportunity to start developing under Qt, and I must admit that Qt is certainly OO and messaging done right.
Signals-Slots is far superior to Message Maps (Gtk, MFC; WxWidgets does both methods), and the intuitiveness and documentation for Qt is just outstanding.
Now, I'm not surprised that the Chrome guys used Gtk+ since Message Maps are so heavily used by most GUI APIs - and its what's native on Windows.
But I also have to agree with Aaron here that Qt is certainly the way to go when developing cross platform. Presently I am writing an app under Windows (Qt4+MSVC2008) but also test myself under Kubuntu, while colleagues use it under GNOME - oh, and everyone else is using Linux binaries I provide them.
The other really cool thing, is that with a quick compile I also get an application ready for an embedded device - especially since Nokia/TrollTech is merging Qt Embedded into the mainline.
I'm not sure any other toolkit does that.
There is a lot of "marketing" from the GTK+ community. Given enough comments on Slashdot, people start to believe it. Stuff like "OO is better with C than C++", "GTK+ is language neutral", "GTK is non-commercial and thus 'free' of corporate influence", etc.
@mart my friends from qtwebkit helped me find out that the issue was that kcachegrind seems to force a style; running with -style GTK+ by hand made it look much less alien (although it doesn't feel as gnomish as even firefox3)
Speaking of which, I think it's worth pointing out that Google decided to basically write their own cross-platform toolkit, and port it to the various toolkits, for Chrome, just like Mozilla/Firefox indeed.
@behavedave
Chromium is open source, Google Chrome is closed source.
This is the reason why they needed a toolkit under the LGPL license.
However as ComaWhite has pointed, that doesn't appear to be the reason.
To all you people claiming that Qt looks just as good as native apps on all platforms, sorry to burst your bubble, but that is simply not true. You are living in a fantasy land. Qt looks like crap on both Windows and Mac OS X. It has all those weird little quirks that make you feel "no, this isn't using native widgets, it's just pretending to be".
The Chrome devs have made one of their primary objectives to build a browser with the cleanest possible user interface on every platform they support. For Windows and OS X, this requires the use of native UI APIs, period. Yes, it's more work, but the end result is a quality product that doesn't make compromises in its user experience (and possibly performance, too).
As for Linux, well, whenever you release a UI-intensive app for Linux you're always a loser. No matter which toolkit you choose, roughly one half of the Linux population will whine that you have made the wrong choice, and that THEIR toolkit is BETTER. Like what is happening right now. Had Chrome decided to use Qt, you'd have the same complaints from GNOME/GTK+ people, claiming that Qt is the inferior toolkit of the Linux desktop.
Some would argue that Linux is not a platform, KDE and GNOME are. Yes, I agree to some degree. However both platforms can run each other's apps just fine, so why bother supporting both? It would be a major waste of time. Hence the need to pick one. Toolkit holy wars be damned.
You should be thankful that they care about Linux AT ALL, despite how much of a burden it is to release apps for it.
@Intergalactic Walrus: "As for Linux, well, whenever you release a UI-intensive app for Linux you're always a loser."
since Qt uses Gtk+ or KDE libs to paint widgets and provide things like file dialogs, you're wrong.
whereas Qt on win/mac doesn't use the native widget drawing but emulates it (though i don't think it looks ugly at all; most people who use skype or google earth for instance never notice), it does use the "native" libraries to the desktop environment.
"you'd have the same complaints from GNOME/GTK+ people, claiming that Qt is the inferior toolkit of the Linux desktop."
except that when it comes to things like "Uses the native widgets everywhere" or "API beauty", which is my point with Qt, you simply can't say the same thing with Gtk+.
"I agree to some degree. However both platforms can run each other's apps just fine, so why bother supporting both?"
that's sort of the point isn't it? you don't have to if you select Qt. you write one codebase and it works nicely and natively on both platforms.
i don't think you have a firm grasp of the technology you are talking about, despite doing so with great apparent authority in your voice. :)
Aaron - you say "KDE has single deployments that are bigger than the entire Ubuntu user base". That's a fairly extravagant sounding claim - can you elaborate?
@Simon: Brazillian school system, 52 million students. last i heard, Canonical claimed less than 10 million *buntu users.
we also have a handful of deployments in the 100s of 1000s of users range each.
Red Flag sold 4 million desktops with KDE on them via retail channels in S. America and Asia in '07, with an estimated Linux retention rate somewhere between 70% and 80%, and that was not a fluke year for them.
as one can see, there are marketing numbers and then are market numbers. ;) marketing numbers are usually more like statistics: they are carefully chosen (e.g. context, what is measured, how it is measured) and often involve some "put your finger in the air and guess the wind speed"; market numbers are usually lot less fun and interesting (e.g. they rarely accompany the phrase "most popular" and come on boring spread sheets, at best you might get some pie charts ;) but they tend to be better for making actual measurements and basing actual decisions on.
NO. NO. NO. NO. NO.
I've said it once and I'll say it a thousand more times: Qt does not look native on Mac OS X.
As a matter of fact it currently (4.5) looks like the bastard step-child of 10.3,4, 5, and something else.
I can't exactly pin-point what something else is but it has to do with wherever those weird gradients in the title bar came from.
So please, stop saying that Qt looks native on a Mac. It doesn't. Furthermore it never will if people keep telling the trolls (Nokianites?) that it does.
Even if (when?) the Trolls get that sorted, KDE will still be a big bundle of visual fail because of the requirement for Qt3Support. Using the Cocoa APIs, which I surmise is necessary to use replicate the OS X UI, does not work if Qt3Support is compiled in. I say surmise, because currently, whether you compile Qt with cocoa or not, it's the same old horrid visuals on OS X.
The choice then is +cocoa, -qt3support (-kde). Or -cocoa, +qt3support (+kde). Fukitol. I'm going to just make a blog post.
@illogic-al: i didn't say it was pixel perfect on mac, nor did i even say it "looked native" (i don't have a mac to compare *shrug* i do know most people don't seem to notice, in any case).
you'll have to ask the mac people @ Qt Software about it.
but ... this post wasn't about Mac (or Windows) now was it?
instead of rushing off to shout "NO" a bunch of times, let's try and not lose the topic.
@aseigo: You're right about this not being about the mac. but: "That means you'll look and work native on Windows, Mac..." :-)
Didn't intend to "hijack the thread" but if something isn't right, it should be called out. Vociferously. Which is why you should keep an eye on the Planet or http://illogic-al.org/blog/look-before-you-leap . *sigh*
P.S. Caps are my way of saying I love you.
Actually it's me being lazy and using that for emphasis instead of type out < strong > (yes, I ended up doing it anyway)
@illogic-al: ah, yes, in the main blog entry. fair enough.
i still don't think most people notice, but better would be .. erm. .. better.
@Aaron
You are pretty delusional if you think that all GNOME users are going to be satisfied with a Qt-pretending-to-be-GTK+ app. Not only will it likely violate all GNOME HIGs, it will be very inefficient performance-wise, due to having two toolkits stacked on top of each other. It's going to have all sorts of weird quirks, just like how Qt looks and acts under Windows (and we're not even talking about the OS X version here, which looks completely awful).
In the end a KDE/Qt app is a KDE/Qt app. You can't escape that cold hard fact, no matter how much you dress it up. In the end people will still complain that it is not in line with their environment of choice.
Also, "API beauty" is highly subjective opinion. Claiming that "you simply can't say the same thing with Gtk+" is foolish at best.
Don't get me wrong, I love Qt. I just hate it when people think of it as a silver bullet that will satisfy 100% of all graphical user interface needs. It's very cool that we have an open source, cross-platform toolkit, but the truth remains that on all non-KDE platforms it produces a less than flawless user experience, which is acceptable for most applications (Skype and Google Earth do look good enough, at least outside of OS X), but in cases when you really want to give your users the very best possible native user interface (which is what the Chrome devs strive for), it just doesn't cut it.
@IntergalaticWalrus: "You are pretty delusional if"
you're getting closer and closer to my civil discussion limit. keep up the insults and you'll find your comments disappearing into the aether. you can make your points without them.
"Not only will it likely violate all GNOME HIGs, it will be very inefficient performance-wise, due to having two toolkits stacked on top of each other."
have you actually measured this? if not, beware of "the first rule of optimizing software" (which is to not optimize what you haven't measured, because it's often not what you'd expect).
and saying "inefficient" in the same breath as "multi-process web browser" is pretty odd; chrome is far heavier on its own in this way than any toolkit stacking would every likely be. the kind of machines people will be running chrome on won't even sneeze at having both toolkits happening.
many people already have both toolkits running in memory anyways. skype, google earth and popular KDE apps all get Qt on many GNOME desktops, and similar examples can be found for Gtk+ in KDE.
so i find this particular argumentation unlikely.
"It's going to have all sorts of weird quirks, just like how Qt looks and acts under Windows"
as i already mentioned, how Qt works under Windows is completely different to how it works vis-a-vis Gtk+. completely. one is emulation, the other is using the actual toolkit directly.
you can't use an pear to prove an orange. prove apples with apples.
"I just hate it when people think of it as a silver bullet that will satisfy 100% of all graphical user interface needs."
i don't think Qt is such a thing. you are reading far more into what i wrote than is actually there, to the point where you are beginning to put words in my mouth.
i simply think, and have a set of pretty solid reasons for doing so, that Qt was the _better_ solution in this case relative to what has been ultimately selected.
that's very different than saying it's a silver bullet for all that ails you.
"but in cases when you really want to give your users the very best possible native user interface (which is what the Chrome devs strive for), it just doesn't cut it."
they can use Cocoa on Mac, the Windows API on Windows, if that's what meets their standards .. (personally i think they probably have better things to do with their time given the results (cost/benefit and all that), but hey, it's their time).
but on UNIX/Linux, Qt would have been a better choice .. which is kind of the point of my blog: the choice of Gtk+ in this situation.
because by choosing Gtk+ they satisfy one segment of users and generally shaft another (and it seems have worked themselves into a spot they aren't happy with anyways); by choosing Qt they would have served both user segments well (and likely could have ignored things like the sound system mayhem by just using phonon's API which uses whatever sound system is there).
... continued
"Also, "API beauty" is highly subjective opinion. Claiming that "you simply can't say the same thing with Gtk+" is foolish at best."
it's pretty well accepted that Qt's API is it's strength (and not just compared to Gtk+).
i'm sure we can find people who disagree (we can find someone to agree with just about anything; people are great like that), but the overwhelming consensus among people who have used various toolkits, including even people who continue to use Gtk+, is that API consistency and clarity is a win for Qt.
there are usually other reasons for people picking Gtk+ (it's what they know; it's what their associates know; it's what they were recommended by $PERSON; they use GNOME and so default to it as their choice; it's C and they prefer C; they start with a code base already using Gtk+; it is LGPL (in the days before Qt was); they were convinced to do so via company politics (my personal "favorite" was a certain UNIX vendor who no longer exists going around to companies and threatening not to ship their apps unless they were written using Gtk+)) ... there are many reasons people pick Gtk+ out there, including defensible ones, but it's not usually because the API is dazzling relative to Qt.
ah, one more point on the "it won't follow the GNOME HIG": that has precisely nothing to do with Gtk+ and eveything to do with following the guidelines.
you can just as easily make a GNOME HIG compliant app with Qt, if that's your goal, as you can with Gtk+.
interestingly, Qt now has QFormLayout. to allows you to lay out forms with some automatic HIG compliance; it's not 100% perfect (i doubt it can be), but gets one even closer without per-platform code.
so they could have a GNOME HIG following app that would look far better under KDE and use the proper dialogs under KDE as well (which to me is even more important).
I guess that calling you "delusional" was indeed inappropriate wording in this discussion. For that I apologize. It wasn't meant as an insult, but in retrospect I now realize it sounds pretentious and aggressive.
Anyway, to make things brief (and civil!), my point was that no matter how good your intentions are towards the Linux desktop, you will always face opposition. It is impossible to escape it, due to its heavy decentralized and two-partied nature. The promise of a fully "DE-agnostic" user interface is an utopia. We just have to deal with it. There are great KDE/Qt applications, and there are great GNOME/GTK+ applications. Everyone can use both of them under the same system, so why all this petty drama, I ask? It's pointless.
Of course the good news with Chrome is that it's open source anyway, so if enough people are motivated enough, a true KDE/Qt native branch is a possibility! Hurrah! And if it proves to be more popular, it could even replace the original GTK+ UI as the official build in the future! That's the great thing about open source right here. If you are unhappy with the current situation, you are not stuck. You can make it better (from your own viewpoint).
Anyway I've rambled enough now so I'll leave it at that.
(Oh, just one quick footnote: Chrome uses multiple processes due to a greater need for reliability. The interesting thing for me with Chrome is that the Google engineers figured out that nowadays, a web browser is now expected to be a full-fledged software platform. Would you run a complete KDE desktop in a single process? Of course not. Chrome applies the same paradigm to its tabs, because essentially, all tabs are seperate applications, under a same platform. It makes sense, really.)
Perhaps an other reason for Google choice is Nokia : Qt is "controlled" (not competely since it's open-source now, but still they control the official repesitory) by Nokia.
And Nokia-Qt's smartphones and perhaps netbooks will compete with Google-Android's one. So if Qt succeed as a cross-platform API it's a problem for Google, because it will be an advantage for a concurrent platform. Can you imagine them doing a Qt browser working on S60 phones but not on Android one's ?
Gtk is no danger for Android...
I vote for Qt as well, I don't think Gtk+ has a point any more.
I think QT needs more evangelism.. nice marketing if you will, about its inherent advantages over GTK....
so in future any project needs to decide on toolkit, they are better aware to make the choice...
As a personal opinion from a developer who worked using both toolkits, I think that Qt is much easier and why don't say "beautiful" in terms of code than writing using Gtk API. There's already the fact that Qt supports *natively* webkit, so the guys from Google could also contribute with Qt to help webkit support get even better. IMHO, take a look at Arora, it's becoming a great browser and it's totally based on Qt+webkit :) Go Arora!!!
According to this: http://groups.google.com/group/chromium-dev/browse_thread/thread/1dfd7c3508b5460c/f45d97ba74a75142?lnk=gst&q=Qt#f45d97ba74a75142
A qt frontend is quite achievable. I think I'll dedicate my creative friday time tommorow to just that. Anyone else interested in money-mouthing?
@Bruno: well, there's WebKitGTK+ (http://webkitgtk.org/), which is just as native as QtWebKit (in fact, we usually work close together =)).
Despite WebKitGTK+ existing, the google guys wanted way more control, and they did their own port of WebKit, that lives besides qtwebkit and webkitgtk+ in WebKit's repository. _That_ code is what they then ported to win32, cocoa, and GTK+. That is why I'm saying that Google decided to write their own cross-platform toolkit.
If you want to take a look at WebKitGTK+, you can look at Midori and Epiphany trunk, by the way =).
I think a webbrowser is not the best example to promote Qt as portability layer. It takes quite long to lauch a Qt4 based application on a GNOME desktop (but only the first time). Considering that a browser is the most important "everyday application", this might be annoying. I'm not happy with VLC switching to Qt4 either. The GTK+ frontend was more snappy and reliable.
However, for other - perhaps more specialized applications - using such a portability layer might be a very good idea. And i hope that Qt will emabrace GIO, to allow access to "network mounts".
@J. Blow: "It takes quite long to lauch a Qt4 based application on a GNOME desktop (but only the first time)."
.. and it takes no time at all on a KDE one. (just to show what an odd argument that is.) there's a lot more out there than GNOME desktops, something that becomes rapidly apparent when we lift our eyes up from the in-the-community hype and look at what's going on in the real world.
_that_ said, Firefox, far and away the most popular web browser on Linux, does not exactly start up in a flash either.
i do begin to wonder, however, when the "reason to not use Qt" of the day (and there has always been one from people who don't use it; an odd obsessive, not to mention divisive, quality at work there) is "the start up time isn't to my liking in this particular OS configuration".
if there aren't more compelling reasons than that, it's probably a telltale sign of the state of things.
"I'm not happy with VLC switching to Qt4 either."
and yet many of us are, including, apparently, the VLC developers.
now, i respect your viewpoint and the right for each of us to speak from that personal viewpoint, but i do have to admit that i have very little interest in sample sizes of one or samples made up of carefully selected demographics.
big picture or no picture.
> Qt will emabrace GIO
GIO isn't the only game in town and it's certainly not the most mature, tested or used solution in that space out there either.
The Google guys can stew in their own juice as far as I'm concerned and we'll end up with a vastly inferior Linux and Mac port to the Windows one - in that order. People just have no clue whatsoever what is needed in creating a cross-platform application, and especially one as hideously complex as Chrome and a browser where Google will probably want to do lots of cool UI stuff, animations etc. now and in the future........and make it work cross-platform.........relatively bug free!
No one seems to have learned from Firefox's mistakes or those of SWT or wxWidgets. We then get the usual rubbish of looking 'native' on each platform at the expense of bugs and stuff actually working, or the start up time...... They're very poor reasons versus getting a reliably working app.
As they've already said, the Linux port of Chrome is a 500 megabyte executable that draws a blank window and where they have made basically zero progress thus far, and is likely to stay that way for a while. I wonder why............
@segedunum:
Clearly you do not know what you're talking about. I'm posting this comment from the linux port of Chrome. Granted, it's missing features, but it's working better than Firefox for me, and hasn't crashed even once.
Clearly you do not know what you're talking about.
Brilliant, because most of what I posted, including the quote about the Linux port, comes from the Google developers themselves and the difficulties they have encountered.
I'm posting this comment from the linux port of Chrome.
Good for you.
Granted, it's missing features
There you are then.
it's working better than Firefox for me, and hasn't crashed even once.
Apart from the fact that it is pre-alpha and they recommend people don't use it in 'productionat all, right now?
Thanks. You really changed my mind.
What toolkit I think it is irrelevant for the end user. Heck, most users don't event know what a toolkit is. If Google wants to use something more or less technically inferior but that makes more sense for them it's mostly their business. What I would like to see is Linux apps written in any toolkit but that work consistently in KDE or Gnome. That means: same VFS, using KDE file open dialog when in KDE and GTK dialog when in Gnome. Same goes for print dialog and so on. Fancy graphics are nice but in the end if I can not get the job done easily I'll just go back to the Windows desktop that is boring but it gets the job done.
@Vld
>What I would like to see
>is Linux apps written in
>any toolkit but that work
>consistently in KDE or Gnome.
>I can not get the job done
>easily I'll just go back to
>the Windows desktop that is
>boring but it gets the job done.
Where on earth have you seen windows apps that behave consistently? Even microsoft application use mostly non standard widgets and any "big" application will use even custom windows borders to mantain a distinct brand.
If people try a GNU/Linux they will have 2 save dialog: the KDE one and the GTK one.
If you spend a week on Windows you will find that Nero file dialog is different from Office file dialog, which is in turn different from Photoshop file dialog.
It seems to me that you don't use Windows that much.
Lucky you!
Post a Comment