After further discussion, the Linux team feels strongly that the best approach for building Google Chrome on Linux is to stay the course with a solution using gtk for layout, so that's what they'll do.
As a refinement to this, there will not be any attempts to refactor views code to share with the gtk front end unless the Mac engineers would also find such a refactoring to be useful. -Ben On Sat, Mar 21, 2009 at 5:57 PM, Ben Goodger (Google) <[email protected]> wrote: > Summary: > > The Google Chrome team should build the Linux front end for Google > Chrome using Views and Gtk rather than using Gtk alone. > > Operational Details > > This week, Elliot will continue to stub out some of the basic widget > and top level window framework. I will continue vacuuming some of the > other constructs we have (NativeControl and a few things in browser/). > I've put together a basic work list that will bring almost everything > up under the label "views-linux": > http://code.google.com/p/chromium/issues/list?q=label:views-linux > Feel free to sign up for aspects that you're interested in working on. > > Rationale > > From a product perspective, the Google Chrome leadership has a strong > desire to have the browser that Google delivers as "Google Chrome" > share the clearly identifiable aesthetic of Chrome on other platforms. > > On MacOS it is possible to do this while blending in fairly well with > the surrounding environment. The prototypes that Cole has been > building and that have been making their way into the Mac ToT bear > this out. On Linux, the variety of window managers in use mean that to > achieve our unique skyline, in all likelihood the window manager frame > would have to be disabled and we would provide our own. Because there > isn't a consistent window manager appearance, there's no stable target > for what the browser frame and hence UI (which derives its appearance > from the frame) should look like. Because of this, the Linux team has > been copying the Windows UI appearance using Gtk and friends for the > widgets, layout and rendering. > > It's my opinion that the engineering work in doing this is not worth > it considering the tradeoffs: > > - It requires maintaining a front end that looks identical to Windows > but which has entirely different code, which includes writing a new > custom layout and event propagation system for things like the > TabStrip, where one already exists on Windows. > - Regardless of whether the underlying browser UI were implemented > entirely in Gtk using its own layout system or with a combination of > Gtk+views, it's likely that there'll be a number of Linux users who > don't like what we produce because to get the "Chrome look" we will > have to disable the frame and use non-standard button appearances. > > For these reasons I think the best investment of time is to bring up > Views so that we can share code with Windows. We will retain Gtk > widgets everywhere where the Windows front end uses Windows Common > Controls - for native buttons, checkboxes, text fields, some menus, > etc - so that we don't need to roll our own IME or accessibility. > Views is used to provide the containing layout engine and custom > rendering system. > > Over the past week Elliot and I have been investigating bringing up > the the base elements of the Views system on Linux. I had some reason > to believe that it may be easier to do so now since over the past > month or so I've made some improvements to the views::Window class > hierarchy that simplifies the arrangement considerably. From the work > Elliot's been able to do, I believe it should be possible to bring up > Views widgets relatively easily. I am investing time in helping clear > the path in the Views code to do so (See my earlier emails about > native controls). > > What this means for Gtk-only and Qt: > > I am actually very supportive of Gtk- and Qt-only front ends. I am > supportive of them not looking like Chrome if it means they fit in > better with the GNOME and KDE environments. I would love to see the > Chromium project deliver (and host the source of) something that each > of those environments feel is worthy of being a first class browser > for their system. This work should not be encumbered by having to have > Chrome's exact aesthetic. My comments above are related to where I > think the efforts of the Google development team's effort should be > directed at this time. > > -Ben > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
