Linux: the views situation

Received-SPF: pass (google.com: 
domain of ev...@google.com designates 216.239.45.13 as permitted sender) 
client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass 
(google.com: domain of ev...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=ev...@google.com; dkim=pass (test mode) header...@google.com
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77])
	by smtp-out.google.com with ESMTP id n0SJuSWT001491
	for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 11:56:28 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1233172589; bh=HFFfK1VRFzxj92ORcHOA5UMG5Xo=;
	h=DomainKey-Signature:MIME-Version:Sender:Date:X-Google-Sender-Auth:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding:
	 X-GMailtapped-By:X-GMailtapped; b=l7eL3CD9NnIV33I9QQfptrb21jfgbsjm
	RPAaR8T9KM93pAWcDT2tctEKXheRWeKheJm5m0dBT4F/91bGeSfVig==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:date:x-google-sender-auth:message-id:
	subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=Aa9dYpUvdLkSlTKpscBV1tjXx2bGzFlXZTZwM8XOtzRuuwoa9edsQ4P0592YdbJGo
	kzICDBkxze/spiqHFJi1w==
Received: from rn-out-0910.google.com (rnw45.prod.google.com [10.38.23.45])
	by wpaz13.hot.corp.google.com with ESMTP id n0SJuQkn015473
	for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 11:56:26 -0800
Received: by rn-out-0910.google.com with SMTP id 45so2854306rnw.5
        for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 11:56:26 -0800 (PST)
MIME-Version: 1.0
Sender: ev...@google.com
Received: by 10.151.43.19 with SMTP id v19mr222527ybj.158.1233172585934; Wed, 
	28 Jan 2009 11:56:25 -0800 (PST)
Date: Wed, 28 Jan 2009 11:56:25 -0800
Message-ID: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b...@mail.gmail.com>
Subject: linux: the views situation
From: Evan Martin <e...@chromium.org>
To: Chromium-dev <chromium-dev@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-GMailtapped-By: 172.24.198.77
X-GMailtapped: evanm

Chromium's UI is done with an internal library called "views", which
currently is effectively an abstraction around the (kinda
impoverished) Windows APIs for doing layout of widgets.  Effectively,
views manages double-buffering of drawing, Windows widget positioning,
and widgets not provided by Windows (like our "link" class, which
manages clickable links, like the one found on the Task manager).
Custom focusable widgets also means we have custom code for managing
focus.

In dialogs like the "Import Bookmarks and Settings" dialog, the combo
box, buttons, and squares of the check boxes are Windows native, while
other pieces (including the labels next to the check boxes) are drawn
by views.  (There's an interesting comment at the top of
chrome/views/checkbox.h as to why that is the case.)

The Mac port plans to not use views at all, and redo all the UI using
native system APIs.  It makes a lot of sense to me as a Mac UI
shouldn't feel like a Windows one; for example, the flow of an options
dialog on a Mac is not at all like Windows.  I remain curious to see
what they do with the wrench/gear menus since they'll have the huge
white bar available for menus but removing the buttons will unabalance
the look of the UI.

The Linux situation is more interesting, since there are separate
ecosystems of UI.  From a UI design perspective, one way to look at it
is like there are different OSes that happen to use the same kernel.
Contrast a screenshot of kubuntu and ubuntu:
  http://www.thecodingstudio.com/opensource/linux/screenshots/scaled/
  Kubuntu%208.10%20Intrepid%20Ibex/16.gif
  http://www.ubuntu.com/files/GutsyImages/Missing-Codecs-Install.jpg
Note that the difference is deeper than the theme: stuff like spacing,
button order, usage of frames and bold are all different.
It's easy to be consistent with one of those but impossible to work with all.

In fact, the 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.  For example, a
low-level port of views to Gtk would likely turn off Gtk's double
buffering and not make use of Gtk widgets for labels, etc. and also
need to work around Gtk trying to manage focus.

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
That already has the appropriate keyboarding handling.  Then Pawel
followed up with a patch to abstract out custom cursor handling done
by the link button.  That also would've come for free.  It makes me
kinda sad.  The GTK version would also obey the system color theme, do
better drawing of Unicode text, etc.

===

Ok, I believe all of the above is factual.  Below this paragraph lies
opinion about where we should go on Linux.
A good place to start with is acknowledging that no decision will make
everyone happy.

Options, as I see them:
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.

I think 1 is right out.  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) but at a more fundamental
level our mandate is to make good software for each platform and
behaving like Windows isn't that -- we should be working on Wine if we
want that.  Even if we picked this we'd still need to use do some work
with native controls for stuff like the omnibox.

2 was insane to me before I started writing this email but is becoming
more and more tempting.  Theme colors: the colors that Chromium uses
were chosen to look good against the default Windows themes, but
Ubuntu chose their ugly brown and it's much more common for users to
change them.  Accessibilty: works for free.  Focus: works for free.
Standard keyboard shortcuts to jump to the toolbar: works for free.
The scariest part to me is the 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;
maybe we could tint the UI to match a system color if you're on a
system that provides such a thing.
The real cost is that this is more code to maintain.  On the other
hand, porting views is also work and code to maintain; it's unclear
how much or how painful it will be.

3 is what I had intended to propose.  For dialogs, I argue it doesn't
make sense to use views, since that is where the UI ought to diverge
the most.  Stuff like the interwidget spacing looks wrong.  (For
reference, note there are strict guides on how to look like a Gnome
app: http://library.gnome.org/devel/hig-book/stable/design-window.html.en
, and similarly elsewhere.)  Views jumps through hoops to make the
Chromium UI not look like Windows, but that means we don't support the
user's theme, etc. which is worse to do on Linux.
In this proposal, we get enough of views working to make the tab strip
work, but we skip all of the native-control handling used by dialogs.
Above fears about drag'n'drop of tabs still apply.

==

I think our mandate is to make something awesome that Linux devotees
will also think is awesome.  With that in mind, I think the people
working on the Linux port are exactly the target audience of this
thing, so I expect that rather than talking about what "the user"
wants, we build something that we like, while sticking to the
principles of Chromium's UI (simple, unobtrusive, fast).

So with that in mind I'm stuck between proposal 2 and 3.  If anyone
has any good arguments, I'd like to hear them.


* On the other hand, on my modern Linux system all I use are terminals
and web browsers and a poll of my officemates is the same result.  3/4
computers use tiling window managers too.

Received-SPF: pass (google.com: 
domain of b...@google.com designates 216.239.33.17 as permitted sender) 
client-ip=216.239.33.17;
Authentication-Results: mx.google.com; spf=pass 
(google.com: domain of b...@google.com designates 216.239.33.17 as permitted sender) 
smtp.mail=b...@google.com; dkim=pass (test mode) header...@google.com
Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com 
[172.28.16.141])
	by smtp-out.google.com with ESMTP id n0SLItXt019591
	for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 21:18:55 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1233177535; bh=U7nn2aokn93Ehz5N4z2BBxT8cU4=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Cc:
	 Content-Type:Content-Transfer-Encoding:X-GMailtapped-By:
	 X-GMailtapped; b=F73qV9CZ15ejGZcdMeaA4rMnJZLcbCFzoxeS4R6ssAa+ysgpq
	Zzg/yN5Hz1hUK3CGeSqC1i/I79r9kCtLvRF5Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:cc:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=fsJui4RvQCBuGQP6EVbOHUm/eU6qbrjxGA6BNeR425yYp9JaLGZu0+KZFlnbU3Rgw
	JrFdBS4Qyy4lDCaZ5KxXQ==
Received: from rn-out-0910.google.com (rnej71.prod.google.com [10.38.161.71])
	by spaceape7.eur.corp.google.com with ESMTP id n0SLId9Z025461
	for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 13:18:52 -0800
Received: by rn-out-0910.google.com with SMTP id j71so2875696rne.19
        for <chromium-dev@googlegroups.com>; Wed, 28 Jan 2009 13:18:52 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Sender: b...@google.com
Received: by 10.151.50.11 with SMTP id c11mr2017340ybk.107.1233177531008; Wed, 
	28 Jan 2009 13:18:51 -0800 (PST)
In-Reply-To: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b...@mail.gmail.com>
References: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b...@mail.gmail.com>
Date: Wed, 28 Jan 2009 13:18:50 -0800
Message-ID: <f4e041d00901281318l340ece63g46588e34b141d...@mail.gmail.com>
Subject: Re: [chromium-dev] linux: the views situation
From: "Ben Goodger (Google)" <b...@chromium.org>
To: e...@chromium.org
Cc: Chromium-dev <chromium-dev@googlegroups.com>
X-GMailtapped-By: 172.28.16.141
X-GMailtapped: beng

First of all let me generally comment that this entire situation is a
clusterfuck. I am not happy with the technical constraints imposed by
Linux and its assorted UIs on Chrome's UI and feature set.

For me, one priority is to ensure we deliver a good experience to most
users and while doing so we're able to rapidly improve Chrome over the
course of time. As such decisions like these should include a
component of how valuable it is to spend time maintaining something
different on different platforms, where maintenance includes feature
development, bug fixing and testing.

My other priority is to ensure that the core essence of Chrome's
design makes it to each of our platforms. A key aspect to this is the
"Skyline" of the browser with tabs merging with the title bar and the
general visual design. There are other aspects too mainly related to
how certain features work. To me, it's important that the product be
recognizable from a distance as "Chrome" - e.g when seen on TV or over
someone's shoulder. I do believe it's possible to achieve this and
still be harmonious with the target operating system.

For MacOS X, we've been following a trajectory that will lead us to a
different View implementation despite these concerns because of a few
things, including 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.

On Linux, it seems fewer of these conditions exist. 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.

However, I don't think there's an easy answer here. It'd be a shame to
have to spend a long time retrofitting views to support a HIG that
doesn't represent consensus on Linux. The Mozilla project has spent a
decade now trying to make XUL look good on different platforms, and to
my eye there are still many problems.

So how best to achieve the objectives? The most expedient path I had
thought would be to port the Windows UI (Option 1). Yes there will be
some number of people that squeal. But honestly how bad will it be? As
long as Chrome is as fast as it is on Windows (and by fast I include
lack of UI jank as a key metric) I seriously doubt people will care.
The primary alternative is to do something like your option 3. (Option
2 seems to be out, since it means we won't be able to get our
distinctive Chrominess - doesn't mean someone else can't do it
though). I'll leave it to you to decide which you want to do though,
given all of the above constraints.

The one piece of advice I'll give to you is to be realistic about how
much work it is to maintain a forked front end. Talk to Pink about the
series of events that led to XUL. Not saying that'll happen here, but
it's worth hearing.

-Ben

On Wed, Jan 28, 2009 at 11:56 AM, Evan Martin <e...@chromium.org> wrote:
>
> Chromium's UI is done with an internal library called "views", which
> currently is effectively an abstraction around the (kinda
> impoverished) Windows APIs for doing layout of widgets.  Effectively,
> views manages double-buffering of drawing, Windows widget positioning,
> and widgets not provided by Windows (like our "link" class, which
> manages clickable links, like the one found on the Task manager).
> Custom focusable widgets also means we have custom code for managing
> focus.
>
> In dialogs like the "Import Bookmarks and Settings" dialog, the combo
> box, buttons, and squares of the check boxes are Windows native, while
> other pieces (including the labels next to the check boxes) are drawn
> by views.  (There's an interesting comment at the top of
> chrome/views/checkbox.h as to why that is the case.)
>
> The Mac port plans to not use views at all, and redo all the UI using
> native system APIs.  It makes a lot of sense to me as a Mac UI
> shouldn't feel like a Windows one; for example, the flow of an options
> dialog on a Mac is not at all like Windows.  I remain curious to see
> what they do with the wrench/gear menus since they'll have the huge
> white bar available for menus but removing the buttons will unabalance
> the look of the UI.
>
> The Linux situation is more interesting, since there are separate
> ecosystems of UI.  From a UI design perspective, one way to look at it
> is like there are different OSes that happen to use the same kernel.
> Contrast a screenshot of kubuntu and ubuntu:
>  http://www.thecodingstudio.com/opensource/linux/screenshots/scaled/
>  Kubuntu%208.10%20Intrepid%20Ibex/16.gif
>  http://www.ubuntu.com/files/GutsyImages/Missing-Codecs-Install.jpg
> Note that the difference is deeper than the theme: stuff like spacing,
> button order, usage of frames and bold are all different.
> It's easy to be consistent with one of those but impossible to work with all.
>
> In fact, the 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.  For example, a
> low-level port of views to Gtk would likely turn off Gtk's double
> buffering and not make use of Gtk widgets for labels, etc. and also
> need to work around Gtk trying to manage focus.
>
> 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
> That already has the appropriate keyboarding handling.  Then Pawel
> followed up with a patch to abstract out custom cursor handling done
> by the link button.  That also would've come for free.  It makes me
> kinda sad.  The GTK version would also obey the system color theme, do
> better drawing of Unicode text, etc.
>
> ===
>
> Ok, I believe all of the above is factual.  Below this paragraph lies
> opinion about where we should go on Linux.
> A good place to start with is acknowledging that no decision will make
> everyone happy.
>
> Options, as I see them:
> 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.
>
> I think 1 is right out.  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) but at a more fundamental
> level our mandate is to make good software for each platform and
> behaving like Windows isn't that -- we should be working on Wine if we
> want that.  Even if we picked this we'd still need to use do some work
> with native controls for stuff like the omnibox.
>
> 2 was insane to me before I started writing this email but is becoming
> more and more tempting.  Theme colors: the colors that Chromium uses
> were chosen to look good against the default Windows themes, but
> Ubuntu chose their ugly brown and it's much more common for users to
> change them.  Accessibilty: works for free.  Focus: works for free.
> Standard keyboard shortcuts to jump to the toolbar: works for free.
> The scariest part to me is the 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;
> maybe we could tint the UI to match a system color if you're on a
> system that provides such a thing.
> The real cost is that this is more code to maintain.  On the other
> hand, porting views is also work and code to maintain; it's unclear
> how much or how painful it will be.
>
> 3 is what I had intended to propose.  For dialogs, I argue it doesn't
> make sense to use views, since that is where the UI ought to diverge
> the most.  Stuff like the interwidget spacing looks wrong.  (For
> reference, note there are strict guides on how to look like a Gnome
> app: http://library.gnome.org/devel/hig-book/stable/design-window.html.en
> , and similarly elsewhere.)  Views jumps through hoops to make the
> Chromium UI not look like Windows, but that means we don't support the
> user's theme, etc. which is worse to do on Linux.
> In this proposal, we get enough of views working to make the tab strip
> work, but we skip all of the native-control handling used by dialogs.
> Above fears about drag'n'drop of tabs still apply.
>
> ==
>
> I think our mandate is to make something awesome that Linux devotees
> will also think is awesome.  With that in mind, I think the people
> working on the Linux port are exactly the target audience of this
> thing, so I expect that rather than talking about what "the user"
> wants, we build something that we like, while sticking to the
> principles of Chromium's UI (simple, unobtrusive, fast).
>
> So with that in mind I'm stuck between proposal 2 and 3.  If anyone
> has any good arguments, I'd like to hear them.
>
>
> * On the other hand, on my modern Linux system all I use are terminals
> and web browsers and a poll of my officemates is the same result.  3/4
> computers use tiling window managers too.
>
> >
>

MIME-Version: 1.0
Date: Wed, 4 Feb 2009 20:20:46 -0800 (PST)
In-Reply-To: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b750@mail.gmail.com>
References: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b750@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <2e903bdd-28d3-42ab-b2e5-fe2c7b66839e@z6g2000pre.googlegroups.com>
Subject: Re: linux: the views situation
From: Peter Petrov <onest...@gmail.com>
To: Chromium-dev <chromium-dev@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This thread sounds really scary. Although it was initially claimed
that Chrome was designed to be cross-platform from the ground up, it's
obviously full of windows-isms at almost every level. Now it seems you
will be forced to maintain a separate UI port for each platform.

I sincerely wonder, why didn't you just use Qt for the UI from the
beginning? It blends very well with the native look&feel on each
platform, while still letting you implement the distinctive Chrome
features. Qt 4.5 will even have native look in GNOME.

Received-SPF: pass 
(google.com: domain of b...@google.com designates 216.239.45.13 as permitted sender) 
client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass 
(google.com: domain of b...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=b...@google.com; dkim=pass (test mode) header...@google.com
Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com 
[172.28.16.141])
	by smtp-out.google.com with ESMTP id n154ReWO009738
	for <chromium-dev@googlegroups.com>; Wed, 4 Feb 2009 20:27:41 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1233808061; bh=7XEELLctNUfBiVqyj/q+HAO3rTM=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Cc:
	 Content-Type:Content-Transfer-Encoding:X-GMailtapped-By:
	 X-GMailtapped; b=n+GeGGymdKrTpCoVXpYk3/YVeh0uCbKzOQtNUduainjRIo7fH
	xu5o8RY3NcIlWwoINYul9G35TDEKN3RpklKHQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:cc:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=p41TrX+KkZz+JQh4suXelf1TvHcYFZINgQUgTvxtTl8JeJ2hxtTGk8C4GnwV2/qm6
	vhQDQpxPNm/+L4fIQMWbg==
Received: from yx-out-1718.google.com (yxi3.prod.google.com [10.190.3.3])
	by spaceape7.eur.corp.google.com with ESMTP id n154RZmc027747
	for <chromium-dev@googlegroups.com>; Wed, 4 Feb 2009 20:27:36 -0800
Received: by yx-out-1718.google.com with SMTP id 3so39518yxi.64
        for <chromium-dev@googlegroups.com>; Wed, 04 Feb 2009 20:27:35 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Sender: b...@google.com
Received: by 10.150.216.3 with SMTP id o3mr171740ybg.1.1233808055392; Wed, 04 
	Feb 2009 20:27:35 -0800 (PST)
In-Reply-To: <2e903bdd-28d3-42ab-b2e5-fe2c7b668...@z6g2000pre.googlegroups.com>
References: <9f43d19d0901281156j4b3f0bdfybdadb0bcf0e6b...@mail.gmail.com>
	 <2e903bdd-28d3-42ab-b2e5-fe2c7b668...@z6g2000pre.googlegroups.com>
Date: Wed, 4 Feb 2009 20:27:35 -0800
Message-ID: <f4e041d00902042027t49dd358u4d0f79d4f5627...@mail.gmail.com>
Subject: Re: [chromium-dev] Re: linux: the views situation
From: "Ben Goodger (Google)" <b...@chromium.org>
To: onest...@gmail.com
Cc: Chromium-dev <chromium-dev@googlegroups.com>
X-GMailtapped-By: 172.28.16.141
X-GMailtapped: beng

In general, we've avoided cross platform UI toolkits because while
they may offer what superficially appears to be a quick path to native
looking UI on a variety of target platforms, once you go a bit deeper
it turns out to be a bit more problematic. As Amanda says, your app
ends up "speaking with a foreign accent".

Our experience is that using these frameworks also limits what you can
do to a lowest common denominator subset of what's supported by that
framework on each platform.

My initial thought was that a Windows-clone would be acceptable on
Linux provided the performance of the app itself was outstanding,
given the general reluctance of some of the team working on Linux
towards UI. But they stood up and made their case for a GTK UI, and so
if you read the other thread on this topic posted to this list
yesterday, you'll see that that's what we've decided to do. A
Windows-clone would most definitely not be acceptable on MacOS X,
where the APIs for UI development are highly evolved and have many
outstanding features. So that's always been the plan there. views is
still theoretically portable, but it's unlikely we'll ever use this
capability. The architecture of Chrome has converged over the past few
months on a solid separation of view from state, and this has given us
the flexibility to make these decisions and choose from the widest
range of alternatives.

-Ben

On Wed, Feb 4, 2009 at 8:20 PM, Peter Petrov <onest...@gmail.com> wrote:
>
> This thread sounds really scary. Although it was initially claimed
> that Chrome was designed to be cross-platform from the ground up, it's
> obviously full of windows-isms at almost every level. Now it seems you
> will be forced to maintain a separate UI port for each platform.
>
> I sincerely wonder, why didn't you just use Qt for the UI from the
> beginning? It blends very well with the native look&feel on each
> platform, while still letting you implement the distinctive Chrome
> features. Qt 4.5 will even have native look in GNOME.
> >
>