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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
