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/Ku... 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.
On Wed, Jan 28, 2009 at 11:56 AM, Evan Martin <e...@chromium.org> wrote: > 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.
(2) and (3) both sound better to me than (1), too. I don't think Views should be a cross-platform abstraction, in general.
First of all let me generally comment that 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.
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.
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/Ku... > 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.
On Wed, Jan 28, 2009 at 7:56 PM, 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/Ku... > 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.
I could not let this mail pass..
I'm a linux user for 10 years, i've used blackbox, enlightenment, gnome, kde..etc.. And I really value *exactly* what you are saying and striving. I guess that in your team you'll find exactly the kind of demanding, experienced and advanced users that you should strive to conquer and please.
A proposal 1 port, instead of 2 or 3 because of fear of wasting precious developers time on a slim quota of a 1% desktop quota (I think desktop linux is around 1-2% market share, you guys can check google.com access.log, so you tell me..) will result in shitty software. It probably won't affect your user base too much.. but it will shure make a lot of unix/linux fans/users pissed. Isn't unix/linux in the core of google's roots ? Will googlers (where linux has a big traccion) _realy_ like chrome on linux ?
> * 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.
same here.. (plus a mp3 player + pidgin..)
kind regards, from a waiting to be linux chrome user.
ps.: from a software developer, and open source suporter, this project is pleasure to follow...
On Jan 28, 8:56 pm, Evan Martin <e...@chromium.org> wrote:
> 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.
That was the first thing I thought when I started to learn how
Chromium i made.
I know Windows developers have "their ways", but if you want to do a
good port
make it look like Linux app (on the inside and outside)
> 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.
IMHO the only right way to do it is 2) with the little of 3) if
necessary.
> 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...
Exactly! If you want do it right, do something that Linux community
will accept.
And IMO the best way to do it is to make it as native as possible.
Because if it will not feel native, it will be rejected, so why to
even bother making
a port that is defective by design. Chromium should look native and
use current user theme,
otherwise no one will really like it. And it would be real loss for
Linux, because chromium is
a great piece of software. And if done right, Linux port will rock! :)
On Jan 28, 10:18 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote:
> First of all let me generally comment that 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.
Why? What do you mean by "technical constraints imposed by Linux"?
(really, I'd like to know)
Something you consider a "constraint" others may name a feature.
> 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.
To do it you must understand needs and preferences of users on etch
platform.
> My other priority is to ensure that the core essence of Chrome's
> design makes it to each of our platforms.
But you also should respect that there are different platforms because
people wants to do things in different ways, so single platform will
somehow take away their ability to have choice. And Linux is all about
choice.
> A key aspect to this is the
> "Skyline" of the browser with tabs merging with the title bar and the
> general visual design.
And that is the first thing I don't actually like in chrome, I just
like tabs bellow address bar, it makes more sense to me.
> On Linux, it seems fewer of these conditions exist.
What you call inconsistency is what I call choice.
> 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.
I realize that it's very difficult and I really hope you will make
right decisions and Chromium Linux port will rock!
> On Jan 28, 10:18 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote: >> First of all let me generally comment that 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.
> Why? What do you mean by "technical constraints imposed by Linux"? > (really, I'd like to know) > Something you consider a "constraint" others may name a feature.
They're allowed to be wrong ;-)
>> 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.
> To do it you must understand needs and preferences of users on etch > platform.
This discussion is exactly about doing that, but Linux makes it harder than other platforms. It's hard enough to build a browser, but building it once for QT/KDE, once for Gnome/GTK, etc. is pretty much out of the question. Instead we'll have to pick one set of UI behaviors that feels right to the largest proportion of Linux users that we can find. Just to re-iterate: the goal isn't to target every linux user and their preferences, but rather to figure out what will work best for *most* linux users.
This set of hard choices will *absolutely* run afoul of many personal choices that some (maybe large) percentage of Linux users may make. That's OK. Not great, but acceptable.
>> My other priority is to ensure that the core essence of Chrome's >> design makes it to each of our platforms.
> But you also should respect that there are different platforms because > people wants to do things in different ways, so single platform will > somehow take away their ability to have choice. And Linux is all about > choice.
...hence Chromium for Linux and Mac aren't being done as "ports" of the Windows UI, but rather ground-up re-implementations. The goal is absolutely to get a great *native* experience for each platform. The difficulty is that "Linux" isn't a platform. At best it's several platforms. At worst, it's a bunch of packages shipped to a distribution site and picked one-by-one by users.
For you Linux might be about *your* choices, but for software authors trying to target Linux, it's about trying to square that flexibility with the need to ship software once and be able to do all the other things that are required to guarantee stability, performance, and security.
>> A key aspect to this is the >> "Skyline" of the browser with tabs merging with the title bar and the >> general visual design.
> And that is the first thing I don't actually like in chrome, I just > like tabs bellow address bar, it makes more sense to me.
...then you don't want Chrome.
You'll be happy to know that there are some other great KHTML/Webkit based browsers for linux, should you not prefer Chrome.
>> On Linux, it seems fewer of these conditions exist. > What you call inconsistency is what I call choice.
That's ok. We can still call it inconsistency and you can do the translation between the words in your mailer. Double-plus-good Linux speak FTW!
>> 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.
> I realize that it's very difficult and I really hope you will make > right decisions and Chromium Linux port will rock!
I think everyone working on it wants exactly the same thing and is raising the point that there are hard choices to be made exactly because making them is the only way to guarantee a great, Chrome-like experience.
On Thu, Jan 29, 2009 at 10:32 AM, Paweł Prażak <kojot...@gmail.com> wrote: > On Jan 28, 10:18 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote: >> First of all let me generally comment that 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.
> Why? What do you mean by "technical constraints imposed by Linux"? > (really, I'd like to know) > Something you consider a "constraint" others may name a feature.
Paweł, I'd like to apologize on behalf of Ben and Alex. They are not as familiar with the technical constraints as you or I may be so some of their mails may not make sense.
What I think everyone means is that it's difficult to figure out what it means to "port" Chromium's UI, as many of the distinguishing aspects of it are not possible to implement on Linux. From Ben's perspective it's a technical limitation; from yours or mine it's kind of the point of the platform.
At the limit, I do agree with Alex's assertion that if you're looking for a browser that fully matches the expectations of e.g. Gnome you're better off with Epiphany. But I intend to come up with some reasonable compromises so we can revisit that question once we're closer to finishing.
Thank you for your reply, maybe I didn't choose the right words to
say what I meant (I'm not a native english speaker, but I'm
learning ;)
I didn't meant to sound rude in any way and if I sounded that way, I
apologize :)
> > Something you consider a "constraint" others may name a feature.
> They're allowed to be wrong ;-)
I asked because I'm curious what constraints we are talking about and
now I know :)
> This discussion is exactly about doing that, but Linux makes it harder
> than other platforms. It's hard enough to build a browser, but
> building it once for QT/KDE, once for Gnome/GTK, etc. is pretty much
> out of the question. Instead we'll have to pick one set of UI
> behaviors that feels right to the largest proportion of Linux users
> that we can find. Just to re-iterate: the goal isn't to target every
> linux user and their preferences, but rather to figure out what will
> work best for *most* linux users.
> This set of hard choices will *absolutely* run afoul of many personal
> choices that some (maybe large) percentage of Linux users may make.
> That's OK. Not great, but acceptable.
I would say it's easier to do it with Qt, but definitely you know
better how to do it :)
> >> My other priority is to ensure that the core essence of Chrome's
> >> design makes it to each of our platforms.
> > But you also should respect that there are different platforms because
> > people wants to do things in different ways, so single platform will
> > somehow take away their ability to have choice. And Linux is all about
> > choice.
> ...hence Chromium for Linux and Mac aren't being done as "ports" of
> the Windows UI, but rather ground-up re-implementations. The goal is
> absolutely to get a great *native* experience for each platform. The
> difficulty is that "Linux" isn't a platform. At best it's several
> platforms. At worst, it's a bunch of packages shipped to a
> distribution site and picked one-by-one by users.
> For you Linux might be about *your* choices, but for software authors
> trying to target Linux, it's about trying to square that flexibility
> with the need to ship software once and be able to do all the other
> things that are required to guarantee stability, performance, and
> security.
I know it not about my choices, I just wanted to point out that
diversity is something important to Linux, but as I see now, I was
pointing out something obvious to you. :)
> >> A key aspect to this is the
> >> "Skyline" of the browser with tabs merging with the title bar and the
> >> general visual design.
> > And that is the first thing I don't actually like in chrome, I just
> > like tabs bellow address bar, it makes more sense to me.
> ...then you don't want Chrome.
> You'll be happy to know that there are some other great KHTML/Webkit
> based browsers for linux, should you not prefer Chrome.
I know there are other browsers, and I've tested most of them, it's
just they are all similar, in sense of design, and chrome is unique.
So I want to use chrome and please consider making it possible to
customize Chrome look/layout, things like toolbars and stuff, it would
make it even better.
> > I realize that it's very difficult and I really hope you will make
> > right decisions and Chromium Linux port will rock!
> I think everyone working on it wants exactly the same thing and is
> raising the point that there are hard choices to be made exactly
> because making them is the only way to guarantee a great, Chrome-like
> experience.
Thank you for this and thank you for your effort of making ground-up
re-implementation.
I'd really like to help you in some way, (unfortunately I don't have
years of experience in C++ :/ ) and I'd like to try play chromium
code, and try to make a Qt based test-shell, I know it's probably too
difficult for me to do it off hand, but I really would like to try.
So could you give me any hints on where to start? (I'm reading
documentation and code but it's huge and maybe it would be easier to
know where to start) I was thinking of merging somehow QtWebkit port
with chromium or something like that, and thy to run/port QtWebKit
simle demo/test browser.
On Thu, Jan 29, 2009 at 12:10 PM, Paweł Prażak <kojot...@gmail.com> wrote: > I'd really like to help you in some way, (unfortunately I don't have > years of experience in C++ :/ ) and I'd like to try play chromium > code, and try to make a Qt based test-shell, I know it's probably too > difficult for me to do it off hand, but I really would like to try. > So could you give me any hints on where to start? (I'm reading > documentation and code but it's huge and maybe it would be easier to > know where to start) I was thinking of merging somehow QtWebkit port > with chromium or something like that, and thy to run/port QtWebKit > simle demo/test browser.
This will be difficult, but it may be possible:
- You will need to port the message pump in base/. This means writing a version of what would happen if you were to call QApplication::exec(). Too much of our code requires our own custom message loop and some of the threading support it has. You might want to get this part down before anything else because I have vague memories of not being able to re-implement the main Qt runloop on one of my side projects.
- You will need to modify all of the Qt widget rendering code to draw into a skia buffer. I don't know how difficult this is in Qt. Webkit renders the webpage into this buffer, along with native widgets for the form controls. (So add grabbing the Qt parts of webkit and forking them for Chromium).
- The following files came up on a grep of the source tree for gtk and looked particularly relevant: -- base/clipboard_linux.cc -- chrome/common/gfx/chrome_font_gtk.cc -- webkit/glue/webcursor_gtk.cc -- webkit/glue/webkit_glue_gtk.cc -- webkit/tools/test_shell/test_shell_gtk.cc -- webkit/tools/test_shell/test_shell_main.cc -- webkit/tools/test_shell/test_webview_delegate_gtk.cc -- webkit/tools/test_shell/webwidget_host_gtk.cc
Again, difficult, but if you can get the message pump working, probably doable.
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.
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.
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.
> 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.
> -BenOn 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.
And thats exactly of what the guy from g company was afraid of if You
go
for gtk, You antagonize the qt fundamentalists and vice versa, I do
personally support
the choice of gtk and for a quicker development gtk+. Id have a
special perspective on
gtk and gtk+ on directfb as it might be an important runner up as if
You were aiming for
those in the end.
All the best with Chromium.
On Feb 16, 4:31 pm, vida18 <vincent.dagous...@gmail.com> wrote:
> On 5 fév, 05:27, "Ben Goodger (Google)" <b...@chromium.org> wrote:
> > 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.
> > -BenOn 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.
Lol, seems I got the same name in the first place. Anyways moving
towards the
explanation of Bens points pointed in direction of linux (and in
general I do share
his views wholeheartedly).
On Jan 29, 7:32 pm, Paweł Prażak <kojot...@gmail.com> wrote:
> On Jan 28, 10:18 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote:
> > First of all let me generally comment that 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.
> Why? What do you mean by "technical constraints imposed by Linux"?
> (really, I'd like to know)
> Something you consider a "constraint" others may name a feature.
The gtk, gtk+, qt, gtk on directfb, wx shall I say more? If You start
project like this,
which one do You select, why do You so? No, Google is almighty but not
that mighty... ;-)
> > 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.
> To do it you must understand needs and preferences of users on etch
> platform.
And they seem to be all different even inside the linux itself, know
the diffs between pure DirectFB, gtk,
and gtk on directfb, right?
> > My other priority is to ensure that the core essence of Chrome's
> > design makes it to each of our platforms.
> But you also should respect that there are different platforms because
> people wants to do things in different ways, so single platform will
> somehow take away their ability to have choice. And Linux is all about
> choice.
Linux is a whole lot more hassle in some areas as it provides
different apis for all
different subusers. pure fb against accelerated fb against
acceleratedfb with widgets against pure c++ gtk+ or qt.
Shitty, doesnt it sound so to You bro?
> > A key aspect to this is the
> > "Skyline" of the browser with tabs merging with the title bar and the
> > general visual design.
> And that is the first thing I don't actually like in chrome, I just
> like tabs bellow address bar, it makes more sense to me.
De gustibus non est disputandum. Thats their projects views, quite
innovative and
important to make the project diff. Shall be respected in first place
as one of the key biz decisions (imho).
> > On Linux, it seems fewer of these conditions exist.
> What you call inconsistency is what I call choice.
Too much of choice is what might make one end in eternal loop. Too
much choice is worse than
lack of those. In some cases (written in intelligible small font)....
> > 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.
> I realize that it's very difficult and I really hope you will make
> right decisions and Chromium Linux port will rock!
And there doesnt seem more to be said in the conclusion. Rock on Pawel
+Google+Chrome.
> Lol, seems I got the same name in the first place. Anyways moving
> towards the
> explanation of Bens points pointed in direction of linux (and in
> general I do share
> his views wholeheartedly).
> On Jan 29, 7:32 pm, Paweł Prażak <kojot...@gmail.com> wrote:
> > On Jan 28, 10:18 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote:
> > > First of all let me generally comment that 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.
> > Why? What do you mean by "technical constraints imposed by Linux"?
> > (really, I'd like to know)
> > Something you consider a "constraint" others may name a feature.
> The gtk, gtk+, qt, gtk on directfb, wx shall I say more? If You start
> project like this,
> which one do You select, why do You so? No, Google is almighty but not
> that mighty... ;-)
> > > 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.
> > To do it you must understand needs and preferences of users on etch
> > platform.
> And they seem to be all different even inside the linux itself, know
> the diffs between pure DirectFB, gtk,
> and gtk on directfb, right?
> > > My other priority is to ensure that the core essence of Chrome's
> > > design makes it to each of our platforms.
> > But you also should respect that there are different platforms because
> > people wants to do things in different ways, so single platform will
> > somehow take away their ability to have choice. And Linux is all about
> > choice.
> Linux is a whole lot more hassle in some areas as it provides
> different apis for all
> different subusers. pure fb against accelerated fb against
> acceleratedfb with widgets against pure c++ gtk+ or qt.
> Shitty, doesnt it sound so to You bro?
> > > A key aspect to this is the
> > > "Skyline" of the browser with tabs merging with the title bar and the
> > > general visual design.
> > And that is the first thing I don't actually like in chrome, I just
> > like tabs bellow address bar, it makes more sense to me.
> De gustibus non est disputandum. Thats their projects views, quite
> innovative and
> important to make the project diff. Shall be respected in first place
> as one of the key biz decisions (imho).
> > > On Linux, it seems fewer of these conditions exist.
> > What you call inconsistency is what I call choice.
> Too much of choice is what might make one end in eternal loop. Too
> much choice is worse than
> lack of those. In some cases (written in intelligible small font)....
> > > 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.
> > I realize that it's very difficult and I really hope you will make
> > right decisions and Chromium Linux port will rock!
> And there doesnt seem more to be said in the conclusion. Rock on Pawel
> +Google+Chrome.
