Disney isn't calling the shots. Part of the deal between Disney and Pixar was junking the low-quality Toy Story 3 that Disney had in production. Pixar said regardless of how much money was already invested in it, they wanted it thrown out the window. In turn, Pixar agreed to make their own version up to their standards. And you know what, the Toy Story 3 teaser definitely has Pixar charm. Disney sequels are terrible. All Pixar has done is CONSISTENTLY put out high quality films.
I'm not that worried since Pixar does seem very committed to quality, as Up has demonstrated once again. What I don't understand is why Incredibles, the film that I think lends itself most to a sequel isn't getting the sequel treatment.
There have been several blog posts (on the Chromium blog) and interviews that explain the reason that Chrome was written Windows only at first was because the main devs only knew Windows.
Chrome/Chromium was a big project with tons of devs, and took something like three years (which encompassed a timespan when Google fervently denied any interest in developing a browser, much like the Android cycle featured repeated denials by Google of any interest in the phone market). So I'm sure in the several years of development, several Linux-savvy developers contributed at some point to the development of Chromium. But the lead devs copped to not knowing anything about Linux.
What I don't understand is why in the Wired article it mentions that Google didn't know which rendering engine to use (despite Android devs already working with Webkit) and the immediate apparent advantages. Webkit was really the best and only way for you to go. In much the same way, I feel Qt was the obvious path and it really baffles me how Google whiffed on this one.
Linus switched away from KDE 4 because it didn't match KDE 3 feature wise yet, and he felt it removed freedom and choice from him. Freedom and choice was the reason he chose KDE 3 over Gnome 2. Here is the funny thing. Instead of going back to KDE 3, which allowed him to customize his desktop how he wanted, he threw a fit and went to Gnome, which he publicly said he hated time after time, to make a bigger statement.
Linus is brilliant and entertaining. That doesn't mean he can't be an ass from time to time, or make irrational decisions (see Con Kolivas as a good example).
I'm watching both rekonq and arora. Arora intends to be very simple, which may not be up my alley. Rekonq is shooting for tight KDE integration, which I like.
What I'd prefer though is a Qt/Webkit browser that worked well on Windows and Linux, and had the sandboxing design of Chrome, and Chome's V8 JS engine.
A Qt version of Chromium would make me very happy indeed.
Qt ships with a Clearlooks engine that can mimic Gnome/GTK widgets pretty well out of the box. Kwin is a fantastic window manager as you pointed out, and there are some solid technologies they could build upon like Solid, Phonon, Sonnet, Akondi, Nepomuk/Strigi, etc.
As for language, obviously Qt was designed for C++, but there are language bindings for both Qt and GTK for your language of choice. In fact, a sizable chunk of Gnome development is being done with C++ and Mono these days, isn't it?
I'd assume the massive Mono-hate in Linux land would shift some developers into the KDE/Qt camp.
Qt is vastly more than a GUI toolkit. I'm saying making calls to the rendering engine is pretty trivial in Qt. You can make easy calls to Webkit with Qt, and still have the rendering engine and UI in separate processes, both written with the Qt API.
A Qt browser on Windows looks just as native as Firefox, or Opera, or Chrome. Note, every one of those browsers uses a non-standard UI. Qt provides styles to mimic native widgets and can look perfectly native. Chrome wasn't even designed to look native. They are blowing smoke to obfuscate the reality of the situation.
Chrome wouldn't have looked one ounce more "foreign" because of Qt. It looks foreign because they designed it foreign.
Building on Qt wouldn't have slowed down the browser any. The browser's "speed" comes from the JS engine. Qt would have made bindings to Webkit easier, and Qt is actually a very fast toolkit. Chrome might actually be faster on Qt.
Those looking to port Chrome to Linux said it wasn't just a matter of a new UI design, that the entire codebase of Chrome/Chromium was exceedingly Windows-centric and difficult to port.
The main reason I don't own the DS is because I don't like how it sits in my hand. I find using it to be a bit awkward, and in the 21st century, I want an analog thumbstick instead of a d-pad.
I've really been hoping for a PSP design with dual analog thumbsticks, and now I see a PSP with zero analog thumbsticks. Frankly, Sony is not going to successfully compete with Apple on the casual, portable touchscreen game market. The main advantage of gaming on the iPhone is that it does not require an additional gadget, nor a wifi connection. The PSP isn't a bad device and it has sold reasonably well. Leave Nintendo and Apple both alone and carve out your own niche.
First off, Qt apps look and operate just fine on Mac and Windows. They don't jump out as looking "foreign" to the platform, where as Chrome on Windows does look extremely foreign in its UI design. This isn't an issue here.
Secondly, Qt provides VASTLY more functionality than GTK, and wouldn't limit what Chrome could do on Windows or Linux. Chrome didn't choose seperate platform codebases to better enable those platforms. The Chrome devs admitted they wrote a very Windows-centric app because they didn't know anything about Linux and coded how they knew how to with what they were familiar with. Again, this reasoning is completely BS.
Lastly, the advantages of cross-platform development not only means no initial time to fork, but it means fewer bugs, less complexity, and the entire life of the project with have a much smaller codebase to manage. Ignoring that major advantage is foolish at best.
Then when you consider how well Qt and Webkit are natively bound, and how well Qt deals with multiple processes and multithreading, it was just plain dumb to not build Chrome on Qt from day 1.
PulseAudio is just terrible in its current state. Phonon conversely is EXTREMELY easy to program for. There was a proof-of-concept media player app written for Phonon in 5 lines of code. It has multiple engines/backends to talk directly to the hardware, which do the heavy lifting. When writing an app, you don't have to debate between support for Gstreamer, or Xine, or whatever. Just write for Phonon and then don't sweat it.
That is why Skype can build a distro-agnostic package with static linked libraries that just works on every distro, even though they also make distro-specific packages as well.
Except GTK is so poor that you have Gnome devs calling for a major restructuring, and Mark Shuttleworth of Cannonical/Ubuntu fame calling for Gnome to be built on top of KDE. Ubuntu hitched their wagon to Gnome very early on, and ships broken KDE packages to this day, but I have to wonder if Shuttleworth regrets that decision today.
Chrome should have been built on top of Qt from day 1. You'd have tight integration with Webkit, a great toolkit, and cross-platform from day 1 on Windows, Mac, Linux and Solaris.
Google opted for VERY Windows-centric design which made porting hard, and then the man tasked with porting to Linux choose a poor toolkit and then blamed the Linux platform for two bad decisions in a row made by Google.
Slashdot Mirror
Disney isn't calling the shots. Part of the deal between Disney and Pixar was junking the low-quality Toy Story 3 that Disney had in production. Pixar said regardless of how much money was already invested in it, they wanted it thrown out the window. In turn, Pixar agreed to make their own version up to their standards. And you know what, the Toy Story 3 teaser definitely has Pixar charm. Disney sequels are terrible. All Pixar has done is CONSISTENTLY put out high quality films.
I'm not that worried since Pixar does seem very committed to quality, as Up has demonstrated once again. What I don't understand is why Incredibles, the film that I think lends itself most to a sequel isn't getting the sequel treatment.
Fill all of them with porn and the recipe for free beer.
I used to hit womprats in my T-16, and they aren't much bigger than 512MB!
There have been several blog posts (on the Chromium blog) and interviews that explain the reason that Chrome was written Windows only at first was because the main devs only knew Windows.
Chrome/Chromium was a big project with tons of devs, and took something like three years (which encompassed a timespan when Google fervently denied any interest in developing a browser, much like the Android cycle featured repeated denials by Google of any interest in the phone market). So I'm sure in the several years of development, several Linux-savvy developers contributed at some point to the development of Chromium. But the lead devs copped to not knowing anything about Linux.
What I don't understand is why in the Wired article it mentions that Google didn't know which rendering engine to use (despite Android devs already working with Webkit) and the immediate apparent advantages. Webkit was really the best and only way for you to go. In much the same way, I feel Qt was the obvious path and it really baffles me how Google whiffed on this one.
Please mod parent up.
I agree that you can deliver a Gnome desktop on top of Qt, and why even suggest it in an interview if he wasn't saying it should be done?
It should be noted that Shuttleworth also pushed for a notification system right out of KDE 4 and OS X in Gnome.
Linus switched away from KDE 4 because it didn't match KDE 3 feature wise yet, and he felt it removed freedom and choice from him. Freedom and choice was the reason he chose KDE 3 over Gnome 2. Here is the funny thing. Instead of going back to KDE 3, which allowed him to customize his desktop how he wanted, he threw a fit and went to Gnome, which he publicly said he hated time after time, to make a bigger statement.
Linus is brilliant and entertaining. That doesn't mean he can't be an ass from time to time, or make irrational decisions (see Con Kolivas as a good example).
I'm watching both rekonq and arora. Arora intends to be very simple, which may not be up my alley. Rekonq is shooting for tight KDE integration, which I like.
What I'd prefer though is a Qt/Webkit browser that worked well on Windows and Linux, and had the sandboxing design of Chrome, and Chome's V8 JS engine.
A Qt version of Chromium would make me very happy indeed.
Qt ships with a Clearlooks engine that can mimic Gnome/GTK widgets pretty well out of the box. Kwin is a fantastic window manager as you pointed out, and there are some solid technologies they could build upon like Solid, Phonon, Sonnet, Akondi, Nepomuk/Strigi, etc.
As for language, obviously Qt was designed for C++, but there are language bindings for both Qt and GTK for your language of choice. In fact, a sizable chunk of Gnome development is being done with C++ and Mono these days, isn't it?
I'd assume the massive Mono-hate in Linux land would shift some developers into the KDE/Qt camp.
Qt is vastly more than a GUI toolkit. I'm saying making calls to the rendering engine is pretty trivial in Qt. You can make easy calls to Webkit with Qt, and still have the rendering engine and UI in separate processes, both written with the Qt API.
A Qt browser on Windows looks just as native as Firefox, or Opera, or Chrome. Note, every one of those browsers uses a non-standard UI. Qt provides styles to mimic native widgets and can look perfectly native. Chrome wasn't even designed to look native. They are blowing smoke to obfuscate the reality of the situation.
Chrome wouldn't have looked one ounce more "foreign" because of Qt. It looks foreign because they designed it foreign.
Building on Qt wouldn't have slowed down the browser any. The browser's "speed" comes from the JS engine. Qt would have made bindings to Webkit easier, and Qt is actually a very fast toolkit. Chrome might actually be faster on Qt.
wxWidgets has existed far longer than GTK. It isn't simply a wrapper around GTK.
Those looking to port Chrome to Linux said it wasn't just a matter of a new UI design, that the entire codebase of Chrome/Chromium was exceedingly Windows-centric and difficult to port.
The main reason I don't own the DS is because I don't like how it sits in my hand. I find using it to be a bit awkward, and in the 21st century, I want an analog thumbstick instead of a d-pad.
I've really been hoping for a PSP design with dual analog thumbsticks, and now I see a PSP with zero analog thumbsticks. Frankly, Sony is not going to successfully compete with Apple on the casual, portable touchscreen game market. The main advantage of gaming on the iPhone is that it does not require an additional gadget, nor a wifi connection. The PSP isn't a bad device and it has sold reasonably well. Leave Nintendo and Apple both alone and carve out your own niche.
I've read the BS answer, and it is BS.
First off, Qt apps look and operate just fine on Mac and Windows. They don't jump out as looking "foreign" to the platform, where as Chrome on Windows does look extremely foreign in its UI design. This isn't an issue here.
Secondly, Qt provides VASTLY more functionality than GTK, and wouldn't limit what Chrome could do on Windows or Linux. Chrome didn't choose seperate platform codebases to better enable those platforms. The Chrome devs admitted they wrote a very Windows-centric app because they didn't know anything about Linux and coded how they knew how to with what they were familiar with. Again, this reasoning is completely BS.
Lastly, the advantages of cross-platform development not only means no initial time to fork, but it means fewer bugs, less complexity, and the entire life of the project with have a much smaller codebase to manage. Ignoring that major advantage is foolish at best.
Then when you consider how well Qt and Webkit are natively bound, and how well Qt deals with multiple processes and multithreading, it was just plain dumb to not build Chrome on Qt from day 1.
He did call for it to be built on top of Qt, not KDE. I know better, and honestly can't tell you why I typed KDE instead of Qt.
Chrome/Chromium is OSS, right? Can't someone else do what Google should have done and make a Qt port?
PulseAudio is just terrible in its current state. Phonon conversely is EXTREMELY easy to program for. There was a proof-of-concept media player app written for Phonon in 5 lines of code. It has multiple engines/backends to talk directly to the hardware, which do the heavy lifting. When writing an app, you don't have to debate between support for Gstreamer, or Xine, or whatever. Just write for Phonon and then don't sweat it.
If only the Linux Standard Base existed! Oh, wait, it does!
http://www.linuxfoundation.org/collaborate/workgroups/lsb
That is why Skype can build a distro-agnostic package with static linked libraries that just works on every distro, even though they also make distro-specific packages as well.
Except GTK is so poor that you have Gnome devs calling for a major restructuring, and Mark Shuttleworth of Cannonical/Ubuntu fame calling for Gnome to be built on top of KDE. Ubuntu hitched their wagon to Gnome very early on, and ships broken KDE packages to this day, but I have to wonder if Shuttleworth regrets that decision today.
Correction, there are THREE major GUI toolkits for Linux. Qt, GTK and Wxwidgets.
Try openSUSE and the latest KDE before jumping over to Vista.
Chrome should have been built on top of Qt from day 1. You'd have tight integration with Webkit, a great toolkit, and cross-platform from day 1 on Windows, Mac, Linux and Solaris.
Google opted for VERY Windows-centric design which made porting hard, and then the man tasked with porting to Linux choose a poor toolkit and then blamed the Linux platform for two bad decisions in a row made by Google.
I have zero sympathy.