Sunday, February 01, 2009

Chromium On Linux (Part 2)

I have been following the Chromium development the past six months as Google attempts to get Chrome working on the non-Windows platforms. In the process I have watched as they rediscovering that creating cross platform application from scratch is hard. Following up on my first blog entry on why you don't have Chrome on Linux today as a Linux user recent Unix platform discussions are just too amazing not to share.

On OS X the plans is to redo all of the UI and use native Cocoa API. There seems to be very little debate on this as there are many positives including a strong consistent API with a growing fickle user base. They still plan on doing their own window painting and not using the OS X theme though.

But on Linux is it a different story. Linux has very few users and those users like to use many different things and have different expectations. Rather then using a library one options would be to re-use the code from Windows. Chrome has an internal library called "Views" which wraps some Windows API/widgets and implements from scratch others. On the mailinglist Evan (one of the kick ass Linux Chrome devs) mentions how they are already duplicating work that already exists in Gtk.

"Pawel recently posted a patch to abstract out the views keyboard event handling for our "button that looks like an HTML link object". Well, there's a built-in one we could've used: http://library.gnome.org/devel/gtk/unstable/GtkLinkButton.html"

Not only Gtk, but Qt also has a widget that can do this. But this is just the tip of the iceberg as they are forced to port each feature from focus handling to widgets. The biggest thing though is that Chrome's tabs go all the way to the window boarder on Windows. On Linux this means to get this they would have to turn off the window manager decoration and do all the painting and window handling on their own. Even though they admit that "it's endless pain" they are pushed to do this for branding and experience reasons. One of the developers even suggested that this would be something for the Linux developers to do in their 20% time.

"What about rolling out [using the window manager] initially, then implement [drawing everything] as a 'group 20% project', the group being the linux team" (1)

Google developers have reported that many never actually use the 20% time contrary to Google's HR marketing and I guess it has gone to such extremes internally that now the 20% time is thought of as time you get to spend doing project tasks.

Working on Arora I planed from the start to have Arora working on different platforms. Even switching between Gnome and KDE icons, button order, shortcuts and more will change. Looking through the screenshots you can see that Arora does a decent job of integrating with each desktop. Many Linux users are geeks, the very type that would download Chrome's source, improve it, write plugins and more. Actively not wanting to fit into their desktop doesn't seem the best route to take.

While they can always change their mind, for now the push in Chrome seems to be to do their own window boarder painting and handling, porting the views (creating a new cross platform toolkit?) and not bothering about real integration with any Linux platform until later.

Or to sum up in the words of Ben Goodger:

"Yes there will be some number of people that squeal. But honestly how bad will it be?"

1) http://groups.google.com/group/chromium-dev/msg/9146805bb27ba30c?dmode=source
2) http://groups.google.com/group/chromium-dev/browse_thread/thread/b89ab99a0c848b89#

1 comment:

Dan Kegel said...

Update: see
http://groups.google.com/group/chromium-dev/browse_thread/thread/61e7d5705c31dbc8#

We're going with native Views implementations for each platform.
For now, we're doing a Gtk one for Linux,
but nothing's stopping anyone from
doing a Qt one in parallel.
Patches welcome.

Popular Posts