[ale] google chrome

Ned Williams nedj10 at gmail.com
Sat Jun 6 09:33:23 EDT 2009


One angle not looked at here I think is that had google actually CHOSEN one
the various ui methods they could have finally helped make that the dominate
methodology for linux ui dev. Truly one of the great things about linux is
its ability to adapt to such forces.

Ned

On Jun 5, 2009 4:07 PM, "Brian Pitts" <brian at polibyte.com> wrote:

Richard Bronosky wrote: > I think that Google's experience with trying to
develop chrome for > Linux...
I think the media's take on this story wasn't very accurate.

When I read about Google's experience [0], I see Chrome developer Evan
Martin calling the Windows APIs "kinda impoverished". Because of
Window's deficiencies, Google wrote a library called "views" that
implements their custom widgets and manages all the stuff Windows
doesn't. Specifically, "various toolkits (Qt, Gtk, Wx, etc.) do pretty
much exactly what views does while also including the widgets that views
tries to wrap. If you're unfamiliar with the Windows API, you should
know it doesn't provide any standard way of doing resizable layouts;
apps typically implement custom code for it.  Similarly for
double-buffering.  If you're unfamiliar with the Linux toolkit APIs, you
should know that all of this stuff is built-in."

So, they have this app that's built on top of an abstraction for the
Windows API. How to get it running on OS X and Linux? Evan saw three
possible approaches

1) As close to Windows as possible, porting views.
2) As close to native as possible, avoiding views.
3) Something in the middle, hacking views.

Their OS X porting team decided on #2. "A Mac UI
shouldn't feel like a Windows" and thus they could completely ditch
views and use Cocoa. In Ben Goodger'swords "the general consensus on
that platform surrounding Cocoa as the UI toolkit, the high quality of
available Mac software, past experiences of failures with cross-platform
user interface toolkits on OS X, the exceptional capabilities of Cocoa
(ask Cole for a demo), and the growing market share of the Mac platform
in general" determined their approach.

Now, what about their linux approach?

Evan didn't think #1 would work. "Some parts just can't work as they do
on Windows (we can't put tabs in the title bar -- heck, lots of people
don't even have title bars on their windows)". It's not clear to me if
this would have been possible on OS X either (meaning that there are
deficiencies int he Linux toolkits) or not (meaning views was just very
tied to Windowsisms).

He prefered 2 or 3. Using GTK, theme colors, accessibility, focus, and
keyboard shortcuts all "work for free". The question was "what to do
with the main browser window and stuff like the star button popup, since
that's all custom-drawn widgets and animations. You could imagine either
doing a boring native-widget port of those or trying to figure out
custom drawing" So, porting to linux requires reimplementing their
custom widgets they implemented for Windows. That's hardly surprising or
damning of linux.

What seems to be getting all the attention is this comments from Ben
Goodger, the head of the UI team:

"this entire situation is a clusterf*ck. I am not happy with the
technical constraints imposed by Linux and its assorted UIs on Chrome's
UI and feature set... There isn't dominant consensus around toolkit and
HIG, there seems to be variance in commonly used software as to how it's
constructed and what it matches, and I've not heard anyone glow about
how they can create the coolest looking UIs with GTK."

He preferred option #1. His concern seems to be that Chrome retain its
"distinctive Chrominess" across platforms as much as possible. On OS X
he was willing to deviate because of the consensus around Cocoa and
Apple's HIG, but since there's no consensus on Linux they should try to
port views and replicate the Windows UI.

I can see the appeal of this argument. They were able to make such a
distinctive UI on Windows because it isn't a cohesive platform from a UI
perspective. If Linux isn't either, why not just make all the same UI
choices you made before. Porting the views code could be less work than
rebuilding the UI using a native toolkit directly.

However, the team porting it to linux "stood up and made their case for
a GTK UI", so that's what is happening.

[0]
http://groups.google.com/group/chromium-dev/browse_thread/thread/b89ab99a0c848b89

--
All the best,
Brian Pitts

_______________________________________________ Ale mailing list Ale at ale.org
http://mail.ale.org/mai...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20090606/97a58bb7/attachment.html 


More information about the Ale mailing list