First of all let me generally comment that this entire situation is a clusterf*ck. I am not happy with the technical constraints imposed by Linux and its assorted UIs on Chrome's UI and feature set.
For me, one priority is to ensure we deliver a good experience to most users and while doing so we're able to rapidly improve Chrome over the course of time. As such decisions like these should include a component of how valuable it is to spend time maintaining something different on different platforms, where maintenance includes feature development, bug fixing and testing. My other priority is to ensure that the core essence of Chrome's design makes it to each of our platforms. A key aspect to this is the "Skyline" of the browser with tabs merging with the title bar and the general visual design. There are other aspects too mainly related to how certain features work. To me, it's important that the product be recognizable from a distance as "Chrome" - e.g when seen on TV or over someone's shoulder. I do believe it's possible to achieve this and still be harmonious with the target operating system. For MacOS X, we've been following a trajectory that will lead us to a different View implementation despite these concerns because of a few things, including the general consensus on that platform surrounding Cocoa as the UI toolkit, the high quality of available Mac software, past experiences of failures with cross-platform user interface toolkits on OS X, the exceptional capabilities of Cocoa (ask Cole for a demo), and the growing market share of the Mac platform in general. On Linux, it seems fewer of these conditions exist. There isn't dominant consensus around toolkit and HIG, there seems to be variance in commonly used software as to how it's constructed and what it matches, and I've not heard anyone glow about how they can create the coolest looking UIs with GTK. However, I don't think there's an easy answer here. It'd be a shame to have to spend a long time retrofitting views to support a HIG that doesn't represent consensus on Linux. The Mozilla project has spent a decade now trying to make XUL look good on different platforms, and to my eye there are still many problems. So how best to achieve the objectives? The most expedient path I had thought would be to port the Windows UI (Option 1). Yes there will be some number of people that squeal. But honestly how bad will it be? As long as Chrome is as fast as it is on Windows (and by fast I include lack of UI jank as a key metric) I seriously doubt people will care. The primary alternative is to do something like your option 3. (Option 2 seems to be out, since it means we won't be able to get our distinctive Chrominess - doesn't mean someone else can't do it though). I'll leave it to you to decide which you want to do though, given all of the above constraints. The one piece of advice I'll give to you is to be realistic about how much work it is to maintain a forked front end. Talk to Pink about the series of events that led to XUL. Not saying that'll happen here, but it's worth hearing. -Ben On Wed, Jan 28, 2009 at 11:56 AM, 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. > > > * 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. > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
