I've closed them for now. On Tue, Mar 31, 2009 at 10:25 AM, Paweł Hajdan Jr. <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
