Hi there, On Wed, Jan 28, 2009 at 7:56 PM, Evan Martin <[email protected]> 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/Kubuntu%208.10%20Intrepid%20Ibex/16.gif > 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... -- Miguel Sousa Filipe --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
