Just one question: what does it mean for these bugs: http://code.google.com/p/chromium/issues/list?q=label:views-linux ?
(Generally they are of type "Implement *Gtk). On Fri, Mar 27, 2009 at 23:07, Ben Goodger (Google) <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
