Linked by Thom Holwerda on Tue 16th Sep 2008 14:03 UTC, submitted by John Mills
Google When Google released its Chrome web browser not too long ago, it of course emphasised that the browser was an open source product. The browser contains 24 parts originating from 3rd parties, and to some surprise, one of those parts comes from one of Google's biggest enemies - Microsoft.
Order by: Score:
They should have used Qt
by kragil on Tue 16th Sep 2008 14:20 UTC
kragil
Member since:
2006-01-04

They wanted to open source it anyway and with Qt we would be using Linux and Mac versions right now.

Reply Score: 5

RE: They should have used Qt
by Thom_Holwerda on Tue 16th Sep 2008 14:22 UTC in reply to "They should have used Qt"
Thom_Holwerda Member since:
2005-06-29

No you wouldn't. Google has stated that they want to offer fully native versions for each platform, and Qt, while a very good platform, is NOT native to Windows and OS X.

Reply Score: 2

RE[2]: They should have used Qt
by _txf_ on Tue 16th Sep 2008 14:26 UTC in reply to "RE: They should have used Qt"
_txf_ Member since:
2008-03-17

It's a shame that they couldn't make it look native then.

either way doesn't Qt use the native widgets in windows and osx? They could have done just the ui using qt instead of implementing their own.

Edited 2008-09-16 14:30 UTC

Reply Score: 3

RE[2]: They should have used Qt
by getaceres on Tue 16th Sep 2008 14:33 UTC in reply to "RE: They should have used Qt"
getaceres Member since:
2005-07-06

QT uses native widgets in Windows and OSX so QT applications feel native in those environments.

Reply Score: 6

RE[3]: They should have used Qt
by Kroc on Tue 16th Sep 2008 15:51 UTC in reply to "RE[2]: They should have used Qt"
Kroc Member since:
2005-11-10

Opera doesn't. It's UI is a disaster on OS X.
QT is anything-but "native".

Reply Score: 1

RE[4]: They should have used Qt
by getaceres on Tue 16th Sep 2008 15:55 UTC in reply to "RE[3]: They should have used Qt"
getaceres Member since:
2005-07-06

But opera doesn't try to be native on any platform. In linux, even using KDE it feels out of place. I refer to applications like Skype for example (although I don't know how it looks on OSX, it seems native on Windows).

Reply Score: 2

RE[5]: They should have used Qt
by MacMan on Tue 16th Sep 2008 16:05 UTC in reply to "RE[4]: They should have used Qt"
MacMan Member since:
2006-11-19

Skype uses QT only on Linux, On the Mac is uses Cocoa. You can find this out by looking at the exported names from the binary, only Cocoa and standard C names are used. It does not link or use QT in any way on the Mac.
.
Same with tons of other applications, such as Mathematica which uses QT on Linux, Carbon on Mac and the standard GDI functions on Windows.


A lot of people seem to think that if an app uses QT on Linux, it uses QT on all other platforms.

One of big problems with QT is that non Mac users have no idea how terrible QT applications look and behave on the Mac.

Edited 2008-09-16 16:08 UTC

Reply Score: 4

RE[6]: They should have used Qt
by -pekr- on Tue 16th Sep 2008 18:14 UTC in reply to "RE[5]: They should have used Qt"
-pekr- Member since:
2006-03-28

"how terrible", "God awful" - what is that - technical evaluation of problem domain? :-)

I really don't know, what is so terrible with apps looking differently. In fact, with REBOL, I prefer non native widgets. I even think, it is some kind of advantage - to be different, while preserve the same app across the platforms. More so nowadays, in the internet app era, when ppl are more forgiving.

What is important imo is not look, but proper (system compatible) app behavior on certain platforms ....

Reply Score: 1

RE[7]: They should have used Qt
by evangs on Tue 16th Sep 2008 19:10 UTC in reply to "RE[6]: They should have used Qt"
evangs Member since:
2005-07-07

You should have worked at Sun's PR. "Java Swing is ugly, but it's equally ugly on all platforms. Give us credit for consistency!"

Reply Score: 2

RE[4]: They should have used Qt
by leos on Tue 16th Sep 2008 18:09 UTC in reply to "RE[3]: They should have used Qt"
leos Member since:
2005-09-21

Opera doesn't. It's UI is a disaster on OS X.
QT is anything-but "native".


That's funny because Opera only uses Qt on Linux, and there only in a very limited sense (mostly for stuff like printing). They actually have their own cross-platform toolkit called Swift if I remember correctly.

Reply Score: 4

RE[3]: They should have used Qt
by MacMan on Tue 16th Sep 2008 15:54 UTC in reply to "RE[2]: They should have used Qt"
MacMan Member since:
2006-11-19

Actually QT doesn't really use native widgets, it sort of does, but not really. Take a look through the source code, QT handles all of its own messaging and most if its own drawing. Essentially, each widget is connected to something like a peer, kind of like Java Swing. It is horribly complex.

Thats the reason why QT applications look absolutely God awful on the Mac and usually pretty bad on Windows (especially when compared with a true native WPF app on Windows or a Cocoa app on OSX).

And yes, I know that there is a beta version of QT that uses Cocoa, but I took a look at the source, and it does the exact same thing. It still most of its own drawing, it just draws to a Cocoa window instead of a Carbon window.

There is a reason why Apple ditched the bottom end of WebKit which was QT to a very light platform abstraction layer. There is a reason why most decent cross platform applications use the real native toolkit on each platform and not some library like QT. QT is really only truly native on Unix where QT and GTK ARE the toolkits.

Edited 2008-09-16 15:56 UTC

Reply Score: 2

modmans2ndcoming Member since:
2005-11-09

wouldn't it be nice if QT developers learned to deligate the drawing to the native widgets?

Reply Score: 2

RE[4]: They should have used Qt
by leos on Tue 16th Sep 2008 18:17 UTC in reply to "RE[3]: They should have used Qt"
leos Member since:
2005-09-21

Actually QT doesn't really use native widgets, it sort of does, but not really. Take a look through the source code, QT handles all of its own messaging and most if its own drawing. Essentially, each widget is connected to something like a peer, kind of like Java Swing. It is horribly complex.


Cross platform native apps are hard. The code to handle it will be complex. You won't find any toolkit that can do what Qt can and is any simpler.

Thats the reason why QT applications look absolutely God awful on the Mac and usually pretty bad on Windows (especially when compared with a true native WPF app on Windows or a Cocoa app on OSX).


I don't use Qt on OS X, but on Windows they are pretty much indistinguishable. Especially considering every single windows app looks slightly different, so there really is no "native" windows look. Office, WMP, Explorer, Notepad, etc all look different, and those are from the same company. I haven't received any complaints about my Qt software on windows from any clients.

There is a reason why Apple ditched the bottom end of WebKit which was QT to a very light platform abstraction layer. There is a reason why most decent cross platform applications use the real native toolkit on each platform and not some library like QT. QT is really only truly native on Unix where QT and GTK ARE the toolkits.


If you talk to normal users (not computer geeks) you will realize that no one gives a crap about what happens under the hood. However Qt does come with a lot more features, and since Chrome was supposed to be as lightweight as possible, I suspect that google went with something customized to keep down on overhead. It's more of a tech demo anyway, I don't think anyone seriously believes that Chrome will be a major browser.

Edited 2008-09-16 18:22 UTC

Reply Score: 4

RE[5]: They should have used Qt
by sbergman27 on Tue 16th Sep 2008 18:37 UTC in reply to "RE[4]: They should have used Qt"
sbergman27 Member since:
2005-07-24

It's more of a tech demo anyway, I don't think anyone seriously believes that Chrome will be a major browser.

Speak for yourself. Chrome is very likely to be a "major browser". Firefox garnered much of its popularity riding on the coattails (and pocketbook) of Google. Remember all those years Mozilla/Firefox sat at low single digit market share?

Reply Score: 1

RE[6]: They should have used Qt
by leos on Tue 16th Sep 2008 18:48 UTC in reply to "RE[5]: They should have used Qt"
leos Member since:
2005-09-21

Speak for yourself. Chrome is very likely to be a "major browser". Firefox garnered much of its popularity riding on the coattails (and pocketbook) of Google. Remember all those years Mozilla/Firefox sat at low single digit market share?


Yes, Firefox has finally clawed some market share from IE, after so many years and years. And Firefox has nothing but advantages over IE. Better standards support, faster, better adblocker, better safety, better extensions (mostly adblock and flashblock for the normal user), it's open source, and works on all platforms.

I can easily make the argument to switch from IE to Firefox, but to Chrome? It's open source sure, and its faster, and it has a couple nifty features.. But it's windows only (for now), it uses more RAM (by design, and this is crucial for many people who are still running $199 computers with 256MB of RAM), it doesn't have a good adblocker, and no extensions.

So why would anyone switch? Don't get me wrong, Chrome is pretty neat, I really like some parts of it, but I can't see any real advantages over Firefox for the average Joe, while Firefox has many advantages of its own. Chrome is speedy, but in real life, you won't see that much of a difference, and every browser is getting faster there too.

It's much more likely that other browsers will absorb Chrome's ideas..

Reply Score: 4

Daniel Borgmann Member since:
2005-07-08

Oh yes, the speed does make a difference in "real life".

The overall speed, simplicity, and responsiveness make Chrome a pleasure to use, and this is something techies often underestimate. You don't need a plethora of new features to make good software. Google has the outreach to make people give it a try, and Chrome has the quality to make them want to stick with it.

Reply Score: 1

RE[4]: They should have used Qt
by ba1l on Wed 17th Sep 2008 11:08 UTC in reply to "RE[3]: They should have used Qt"
ba1l Member since:
2007-09-08

Erm... WPF is not "native" by your definition either. WPF handles all of it's own drawing, and builds it's own messaging system on top of Windows's events. Just like Qt.

Windows.Forms does this as well. So do the UI libraries used internally by Microsoft's various applications. So does Internet Explorer. So does Firefox.

Reply Score: 3

RE[3]: They should have used Qt
by mnem0 on Wed 17th Sep 2008 07:04 UTC in reply to "RE[2]: They should have used Qt"
mnem0 Member since:
2006-03-23

QT3 used native widgets but QT4 does NOT!

Reply Score: 0

RE[2]: They should have used Qt
by frood on Tue 16th Sep 2008 14:37 UTC in reply to "RE: They should have used Qt"
frood Member since:
2005-07-06

No you wouldn't. Google has stated that they want to offer fully native versions for each platform, and Qt, while a very good platform, is NOT native to Windows and OS X.


That's interesting. I always thought native just meant it was compiled for that OS and now Wine type layer was in use. If not using native widgit's means it's not native doesn't that mean Google Chrome, Nero, WMP11, etc are not native either?

Reply Score: 2

Bending Unit Member since:
2005-07-06

"Native" is one of my most hated words. The best thing is not to use it and say what you mean instead.

Reply Score: 3

RE[2]: They should have used Qt
by BSDfan on Tue 16th Sep 2008 18:14 UTC in reply to "RE: They should have used Qt"
BSDfan Member since:
2007-03-14

So what? that'll be using Xlib on Unix platforms then?

Reply Score: 3

RE[2]: They should have used Qt
by pixel8r on Thu 18th Sep 2008 02:55 UTC in reply to "RE: They should have used Qt"
pixel8r Member since:
2007-08-11

No you wouldn't. Google has stated that they want to offer fully native versions for each platform, and Qt, while a very good platform, is NOT native to Windows and OS X.


Er, yes it is. If its not native on windows, then its not native on Linux, OSX or any other OS either.

Reply Score: 1

RE[2]: They should have used Qt
by antwarrior on Fri 19th Sep 2008 13:36 UTC in reply to "RE: They should have used Qt"
antwarrior Member since:
2006-02-11

or Linux? QT is not native to Windows, OS X or Linux. From the way you use the word. Linux also qualifies. I'm not saying thats what you meant but thats what it sounds like to me. What do people mean when they say native anyway?

Reply Score: 1

...
by Manuma on Tue 16th Sep 2008 15:50 UTC
Manuma
Member since:
2005-07-28

Making it with Qt would abligate Google to release it under the GPL, and it is abvious the didn't want that, They could have a Qt license an release it under the license they want it but anyone who wanted to contribute would have to buy a Qt license too. So please, stop the Qt non sense. Is to limitant.

Reply Score: 3

RE: ...
by getaceres on Tue 16th Sep 2008 15:58 UTC in reply to "..."
getaceres Member since:
2005-07-06

No, since version 4.X (X is something I don't remember) QT license has an exception for open source projects so basically, if your project is open source, then you can use QT for free and apply to your sources the license you like.

Reply Score: 4

v RE[2]: ...
by Manuma on Tue 16th Sep 2008 16:16 UTC in reply to "RE: ..."
RE[2]: ...
by raboof on Wed 17th Sep 2008 11:06 UTC in reply to "RE: ..."
raboof Member since:
2005-07-24

The details of that arrangement, well hidden-away, are at http://doc.trolltech.com/4.4/license-gpl-exceptions.html

Reply Score: 2

Highlight from the article
by Morph on Tue 16th Sep 2008 16:10 UTC
Morph
Member since:
2007-08-20

From Chrome source http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/dep.cc?...

// Completely undocumented from Microsoft. You can find this information by
// disassembling Vista's SP1 kernel32.dll with your favorite disassembler.
enum PROCESS_INFORMATION_CLASS {
ProcessExecuteFlags = 0x22,
}

Reply Score: 3

RE: Highlight from the article
by fithisux on Tue 16th Sep 2008 19:38 UTC in reply to "Highlight from the article"
fithisux Member since:
2006-01-22

There is Java and there is Lobo. And once upon a time there was HotJava. If they wnted to innovate they could sta HotGoogle. Otherwise I stay with my very native Kmeleon/Epiphany/Konqueror and Seamonkey/FFox.

Reply Score: 2

Comment by Kroc
by Kroc on Tue 16th Sep 2008 16:18 UTC
Kroc
Member since:
2005-11-10

Uh, so what?
Isn't this what Open Source is supposed to be about?

Anyone can modify and reuse it.

There's no clause to say "* except competitors".

This is not news, it's flame-bait.

Reply Score: 3

RE: Comment by Kroc
by Thom_Holwerda on Tue 16th Sep 2008 16:34 UTC in reply to "Comment by Kroc"
Thom_Holwerda Member since:
2005-06-29

This is not news, it's flame-bait.


It's interesting. Click the read more, and read the last line.

"It's always interesting to see open source at work. Hanselman's article is an interesting read, as it takes a closer look at how, exactly, the WTL code is being used by Chrome."

Reply Score: 4

v RE[2]: Comment by Kroc
by Kroc on Tue 16th Sep 2008 16:46 UTC in reply to "RE: Comment by Kroc"
RE[3]: Comment by Kroc
by Thom_Holwerda on Tue 16th Sep 2008 16:50 UTC in reply to "RE[2]: Comment by Kroc"
Thom_Holwerda Member since:
2005-06-29

Trying to paint WTL in Chrome as some kind of unholy matrimony is just pandering to Microsofties and Haters alike.


What are you talking about? Who's painting what as what? It's just a funny, interesting coincidence, that's all. And to make it even more interesting, the source article takes a detailed look at the code in question, and seeing quite a few of our readers are developers, this is a perfectly fine item to post.

Reply Score: 4

v RE[4]: Comment by Kroc
by Kroc on Tue 16th Sep 2008 16:53 UTC in reply to "RE[3]: Comment by Kroc"
RE[5]: Comment by Kroc
by Thom_Holwerda on Tue 16th Sep 2008 16:57 UTC in reply to "RE[4]: Comment by Kroc"
Thom_Holwerda Member since:
2005-06-29

I'm referring to the OSNews article title/summary rather than the article itself. OSNews is clearly looking for page views here.


I honestly have no idea what brought you to that conclusion. Heck, not even sbergman took it that way, and that really says it all ;) . If I was looking for page views, I could have made the OSNews summary/headline a lot more sensationalist than this humble little text.

Seriously now, though, I think that if you try hard enough, you can see every item as looking for page views. Which would be rather idiotic, since we get nothing in return for having more page views at all.

This is a perfectly fine, normal item.

Reply Score: 2

RE[6]: Comment by Kroc
by Kroc on Tue 16th Sep 2008 17:05 UTC in reply to "RE[5]: Comment by Kroc"
Kroc Member since:
2005-11-10

Fair enough; the community have spoken.

Reply Score: 2

Good to hear
by sbergman27 on Tue 16th Sep 2008 16:37 UTC
sbergman27
Member since:
2005-07-24

Wow. I had to recheck the story headline to confirm that it was about Chrome and WTL and not about QT.

Think about it. A piece of truly OSS code (with a BSDish license), released by Microsoft, has found genuine use in a major product from an industry competitor. A few years ago we all would have been stunned. Instead, today, we start quibbling about the relative benefits of QT.

While I am hardly a Microsoft fan, and in fact actively dislike them, I think that a "Welcome to the FOSS community, Microsoft" is in order at this point.

Reply Score: 6

RE: Good to hear
by evangs on Tue 16th Sep 2008 17:45 UTC in reply to "Good to hear"
evangs Member since:
2005-07-07

It is not surprising that they've chosen to use WTL since many other projects already use it. On Windows if you're using Visual C++, the choice really boils down to MFC, pure Win32 or WTL. MFC is alright but it is fairly huge and it forces you to use it's DocView architecture. Nobody really writes in pure Win32 anymore so that leaves WTL, which is actually a very nice library.

The major drawback of WTL is the lack of any decent documentation. There's nothing on MSDN, there are no books, there isn't a complete list of classes and what each method does. And this is what annoys me about Microsoft's approach to WTL.

Instead of focusing manpower on documenting and developing WTL, they've just dropped the whole thing on Sourceforge. No documentation. No official support. Nada. That makes the barrier to entry for using WTL since the only reliable documentation is the code. That also means you need to be an expert at the Win32 API, ATL and MFC.

Nevertheless, there are many commercial products that use WTL. Once you get the hang of it, nothing beats it for developing WIN32_LEAN_AND_MEAN applications ;) .

Reply Score: 2

RE[2]: Good to hear
by tomcat on Wed 17th Sep 2008 03:24 UTC in reply to "RE: Good to hear"
tomcat Member since:
2006-01-06

The major drawback of WTL is the lack of any decent documentation. There's nothing on MSDN, there are no books, there isn't a complete list of classes and what each method does. And this is what annoys me about Microsoft's approach to WTL. Instead of focusing manpower on documenting and developing WTL, they've just dropped the whole thing on Sourceforge. No documentation. No official support. Nada. That makes the barrier to entry for using WTL since the only reliable documentation is the code. That also means you need to be an expert at the Win32 API, ATL and MFC. Nevertheless, there are many commercial products that use WTL. Once you get the hang of it, nothing beats it for developing WIN32_LEAN_AND_MEAN applications ;) .



http://msdn.microsoft.com/en-us/magazine/cc163305.aspx

It seems pretty straightforward.

Reply Score: 3

google pwned!
by casuto on Tue 16th Sep 2008 18:06 UTC
casuto
Member since:
2007-02-27

google pwned!

Reply Score: 2

osx app integration
by versekiller on Tue 16th Sep 2008 18:32 UTC
versekiller
Member since:
2008-09-16

4 those of you who said qt does not integrate well into osx and integrates well with windows and kde

http://img60.imageshack.us/my.php?image=picture6bh5.png

http://code.google.com/p/arora/

please bear in mind its fairly new browser

Reply Score: 2

RE: osx app integration
by evangs on Tue 16th Sep 2008 19:08 UTC in reply to "osx app integration"
evangs Member since:
2005-07-07

When people talk about integration, they generally mean look and feel. Screenshots can only convey the "look". You'll only get to appreciate the "feel" when you're sat down and using the software on the target platform.

Reply Score: 2

RE[2]: osx app integration
by andrewg on Tue 16th Sep 2008 20:32 UTC in reply to "RE: osx app integration"
andrewg Member since:
2005-07-06

I know what you mean. Qt apps on Windows and OSX feel snappier i.e. respond more quickly than native windows and especially Cocoa apps. So they feel lighter whereas Cocoa apps feel solid / heavy.

But I like Qt apps so it does not bother me.

Reply Score: 2

RE[3]: osx app integration
by evangs on Tue 16th Sep 2008 20:52 UTC in reply to "RE[2]: osx app integration"
evangs Member since:
2005-07-07

Qt apps on Windows and OSX feel snappier i.e. respond more quickly than native windows and especially Cocoa apps. So they feel lighter whereas Cocoa apps feel solid / heavy.


I don't know if you're being sarcastic, or if you're serious. What applications are you using that feel so much snappier?

Reply Score: 1

v RE[4]: osx app integration
by MacMan on Tue 16th Sep 2008 23:43 UTC in reply to "RE[3]: osx app integration"
RE[5]: osx app integration
by BluenoseJake on Wed 17th Sep 2008 00:54 UTC in reply to "RE[4]: osx app integration"
BluenoseJake Member since:
2005-08-11

"[q]Qt apps on Windows and OSX feel snappier i.e. respond more quickly than native windows and especially Cocoa apps. So they feel lighter whereas Cocoa apps feel solid / heavy.



This has got to be a joke. Cocoa is the native toolkit, Carbon is a backwards compatibility wrapper around cocoa, and QT is a widget set that does most if its own drawing on top of carbon. So, QT on Mac is a wrapper on top of a wrapper on top of a wrapper. Plus, QT is a MASSIVE library that duplicates all of the standard c++ stuff, the libs alone are what about 15 MB, all that has to be loaded into memory.
"


15M???? oh my gods, I don't know if there is enough left to open any other apps...how will a person get by with only 1019M of ram left.

Oh, the humanity

Reply Score: 2

RE[6]: osx app integration
by evangs on Wed 17th Sep 2008 12:30 UTC in reply to "RE[5]: osx app integration"
evangs Member since:
2005-07-07

You use only one application at a time? That's good to know.

Reply Score: 1

RE[7]: osx app integration
by BluenoseJake on Wed 17th Sep 2008 12:56 UTC in reply to "RE[6]: osx app integration"
BluenoseJake Member since:
2005-08-11

No, I use several, my point is, that 15M of ram is not a lot for an app/framework/toolkit to use. It's not 1995

Reply Score: 2

RE[4]: osx app integration
by MacMan on Tue 16th Sep 2008 23:49 UTC in reply to "RE[3]: osx app integration"
MacMan Member since:
2006-11-19

"Qt apps on Windows and OSX feel snappier i.e. respond more quickly than native windows and especially Cocoa apps. So they feel lighter whereas Cocoa apps feel solid / heavy.


I don't know if you're being sarcastic, or if you're serious. What applications are you using that feel so much snappier?
"


This has got to be a joke. Cocoa is the native toolkit, Carbon is a backwards compatibility wrapper around cocoa, and QT is a widget set that does most if its own drawing on top of carbon. So, QT on Mac is a wrapper on top of a wrapper on top of a wrapper. Plus, QT is a MASSIVE library that duplicates all of the standard c++ stuff, the libs alone are what about 15 MB, all that has to be loaded into memory.

Reply Score: 0

gtk desktop environment integration
by versekiller on Tue 16th Sep 2008 23:02 UTC
versekiller
Member since:
2008-09-16

as you can see it looks good in a gtk desktop environment 2
http://img255.imageshack.us/my.php?image=frereffegfxw4.png

Reply Score: 2