[chromium-dev] Re: linux: the views situation

[Miguel F Mascarenhas Sousa Filipe]

Hi there,

On Wed, Jan 28, 2009 at 7:56 PM, Evan Martin  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

[chromium-dev] Re: linux: tabs on top

[Michael Moss]

On Wed, Jan 28, 2009 at 2:24 PM, Evan Martin  wrote:
>
> On Wed, Jan 28, 2009 at 2:19 PM, Michael Moss  wrote:
>> On Wed, Jan 28, 2009 at 1:32 PM, Amanda Walker  wrote:
>>> I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen),
>>> but a Chromium-XP style window frame doesn't strike me as too out of
>>> place on, say, an Ubuntu desktop as long as the color could be changed
>>> away from bright blue...
>>
>> Yeah, and if the smooth tab/title bar is a big part of Chrome's
>> "recognizability" (to echo Ben), then it's probably worth going the
>> custom drawn route. I'd be inclined to start there, rather than put it
>> off, since I think a basic implementation shouldn't be too hard. And
>> by basic, I'm thinking mostly drag and resize support on, say, Hardy
>> Gnome and KDE (if a right-click doesn't bring up the window manager
>> menu, is anyone really going to miss it?). On a related note, would
>> dialogs use a similar custom border (it looks like they do on
>> Windows), or the regular WM border?
>
> If we're going to do some of it, may as well do all of it, I guess?

Yeah. The system dialogs (e.g. "save as") won't match, but it looks
like the Windows port doesn't care about that either.

Michael

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Evan Martin]

On Wed, Jan 28, 2009 at 2:19 PM, Michael Moss  wrote:
> On Wed, Jan 28, 2009 at 1:32 PM, Amanda Walker  wrote:
>> I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen),
>> but a Chromium-XP style window frame doesn't strike me as too out of
>> place on, say, an Ubuntu desktop as long as the color could be changed
>> away from bright blue...
>
> Yeah, and if the smooth tab/title bar is a big part of Chrome's
> "recognizability" (to echo Ben), then it's probably worth going the
> custom drawn route. I'd be inclined to start there, rather than put it
> off, since I think a basic implementation shouldn't be too hard. And
> by basic, I'm thinking mostly drag and resize support on, say, Hardy
> Gnome and KDE (if a right-click doesn't bring up the window manager
> menu, is anyone really going to miss it?). On a related note, would
> dialogs use a similar custom border (it looks like they do on
> Windows), or the regular WM border?

If we're going to do some of it, may as well do all of it, I guess?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Michael Moss]

On Wed, Jan 28, 2009 at 1:32 PM, Amanda Walker  wrote:
>
> On Wed, Jan 28, 2009 at 2:56 PM, Evan Martin  wrote:
>> Two options:
>> 1) Set the hint that turns off window frame drawing, and render
>> something that looks like the Windows one.  This would mean
>> implementing window dragging via the title bar, etc. manually.  (Ben's
>> "magic browzr" work was undoing code like this on Windows, because
>> it's endless pain.
>
> It may be endless pain, but isn't it what we still do in XP, for
> similar reasons?  And in Cole's prototypes of Mac window frames and
> tabs, we're also overriding OS window frame drawing in order to
> provide Chromium-style tab and window styling (it's designed to blend
> with native Mac windows, but it's not using the default window
> appearance).
>
> I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen),
> but a Chromium-XP style window frame doesn't strike me as too out of
> place on, say, an Ubuntu desktop as long as the color could be changed
> away from bright blue...

Yeah, and if the smooth tab/title bar is a big part of Chrome's
"recognizability" (to echo Ben), then it's probably worth going the
custom drawn route. I'd be inclined to start there, rather than put it
off, since I think a basic implementation shouldn't be too hard. And
by basic, I'm thinking mostly drag and resize support on, say, Hardy
Gnome and KDE (if a right-click doesn't bring up the window manager
menu, is anyone really going to miss it?). On a related note, would
dialogs use a similar custom border (it looks like they do on
Windows), or the regular WM border?

Michael

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Accessing popup window URL from WebViewDelegate::CreateWebView()

[Evan Martin]

This isn't exactly what you want, but it might help:

The new tab page wants all links it opens to be opened in a new
process (to help avoid potential leakage of private data due to
unanticipated bugs from the new tab page into the page you're
opening).  So it blocks webkit loading of URLs and instead pushes the
URL load out into the browser process, which means the page load
effectively goes through the "typed a URL into the URL bar" code path.

The code has all changed since I last worked with it, but grepping
around for AllowDOMUIBindings might help find it.

On Wed, Jan 28, 2009 at 12:48 PM, Marshall Greenblatt
 wrote:
> Hi All,
>
> I would like to evaluate the URL that will be opened in a newly created
> popup window before the view for that window is created.  It seems that the
> WebViewDelegate::CreateWebView() method might be the appropriate place to do
> this, but that method does not get the popup URL as an argument.   This URL
> information is available in WebCore::createWindow() but is not passed into
> FrameLoader::createWindow(), etc.  Is it reasonable to pass the URL through
> the call chain to WebViewDelegate::CreateWebView() (which will require
> changes to third_party\WebKit\WebCore), or is there a more appropriate way
> to access this information before the popup window view is created in
> WebViewDelegate::CreateWebView()?
>
> Here is the relevant call chain:
>
> WebCore::createWindow() in webkit\port\bindings\v8\v8_custom.cpp
> WebCore::FrameLoader::createWindow() in
> third_party\WebKit\WebCore\loader\FrameLoader.cpp
> WebCore::Chrome::createWindow() in
> third_party\WebKit\WebCore\page\Chrome.cpp
> ChromeClientImpl::createWindow() in webkit\glue\chrome_client_impl.cc
> WebViewDelegate::CreateWebView()
>
> Thanks,
> Marshall
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Amanda Walker]

On Wed, Jan 28, 2009 at 4:38 PM, Mike Pinkerton  wrote:
> Sorry, this couldn't be further from what we're actually doing right
> now. We're inserting a view into the window's view hierarchy as a
> sibling to the contentView, which works surprisingly well. We may run
> into issues with the window title, but for right now, the OS is
> drawing everything with no custom frame drawing.

Ah, I misunderstood.  Darn clever, then :-).

--Amanda

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Mike Pinkerton]

On Wed, Jan 28, 2009 at 4:32 PM, Amanda Walker  wrote:
> It may be endless pain, but isn't it what we still do in XP, for
> similar reasons?  And in Cole's prototypes of Mac window frames and
> tabs, we're also overriding OS window frame drawing in order to
> provide Chromium-style tab and window styling (it's designed to blend
> with native Mac windows, but it's not using the default window
> appearance).

Sorry, this couldn't be further from what we're actually doing right
now. We're inserting a view into the window's view hierarchy as a
sibling to the contentView, which works surprisingly well. We may run
into issues with the window title, but for right now, the OS is
drawing everything with no custom frame drawing.

-- 
Mike Pinkerton
Mac Weenie
pinker...@google.com

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Amanda Walker]

On Wed, Jan 28, 2009 at 2:56 PM, Evan Martin  wrote:
> Two options:
> 1) Set the hint that turns off window frame drawing, and render
> something that looks like the Windows one.  This would mean
> implementing window dragging via the title bar, etc. manually.  (Ben's
> "magic browzr" work was undoing code like this on Windows, because
> it's endless pain.

It may be endless pain, but isn't it what we still do in XP, for
similar reasons?  And in Cole's prototypes of Mac window frames and
tabs, we're also overriding OS window frame drawing in order to
provide Chromium-style tab and window styling (it's designed to blend
with native Mac windows, but it's not using the default window
appearance).

I'm a casual linux-desktop user at best (mostly I ssh to Linux boxen),
but a Chromium-XP style window frame doesn't strike me as too out of
place on, say, an Ubuntu desktop as long as the color could be changed
away from bright blue...

--Amanda

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Peter Kasting]

On Wed, Jan 28, 2009 at 1:17 PM, Evan Martin  wrote:

> Sorta like this screenshot:
> http://userstyles.org/styles/11000


LOL @ that guy's lousy attempt to blur out "Warez-BB.org".

I bet he's just getting Linux ISOs.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: the views situation

[Ben Goodger (Google)]

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  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

[chromium-dev] Re: linux: tabs on top

[Evan Martin]

On Wed, Jan 28, 2009 at 1:05 PM, Michael Moss  wrote:
>> 2) Give up, and just make the tabs flush with the top of the window we
>> have.  This is probably ugly in the general case (since there will be
>> an edge between the title bar and tabs), but will work in all
>> situations.
>
> I'm not sure I understand what this "ugly edge" is. Do you mean the
> line/bevel that window managers typically draw under the title bar?

Yeah.  What I meant was that the other chromiums have a single fluid
title bar from top of the window to bottom of the tabs, and this
proposal would instead just have them adjacent.
Sorta like this screenshot:
http://userstyles.org/styles/11000

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: tabs on top

[Michael Moss]

> 2) Give up, and just make the tabs flush with the top of the window we
> have.  This is probably ugly in the general case (since there will be
> an edge between the title bar and tabs), but will work in all
> situations.

I'm not sure I understand what this "ugly edge" is. Do you mean the
line/bevel that window managers typically draw under the title bar?

Michael

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Responsibility reviewing patches with multiple reviewers

[Erik Kay]

This feels like a tools issue to me.  In Mondrian, the review has an
overall score on it (or at least it did the last time I used it).  If
a reviewer replied without a LGTM, then it subtracted 1.  A reply with
a LGTM added 1.  It didn't allow you to commit the change until you
had at least a +1, so with multiple reviewers asking for changes, it
was clear whether you had something still pending or not.  I'm not
convinced that this precise mechanism is what we'd want, but perhaps
something related would help.

Erik


On Tue, Jan 27, 2009 at 10:04 PM, Brett Wilson  wrote:
>
> There are a lot of patches lately with a lot of reviewers on them,
> especially related to porting since a lot of people might need to be
> in the loop for some changes.
>
> The problem is that there's no clear responsibility given in these
> reviews. If I'm the sole reviewer on a change, I know I have to do a
> good job. When there are three other people, I sometimes assume that
> somebody else must have looked carefully at some part of the review.
> I'm sure sometimes all the reviewers think this and the change isn't
> reviewed properly.
>
> In other cases, some reviewers say LGTM for a patch, while others are
> still expecting changes. The author can get confused as to the status
> of the review, and I also know some patches have been checked in
> lately where at least one reviewer expected further changes before
> checkin.
>
> At the same time, we want to encourage many people to participate in
> the review process and keep tabs on what's going on. I propose several
> changes to best practices:
>
> 1. When a patch author requests more than one reviewer, they should
> make clear in the review request email what they expect the
> responsibility of each reviewer to be. Example:
>  agl: bitmap changes
>  evanm: process hacks
>  everybody else: FYI
> In this case, I might be on the review list because I've asked to be
> in the loop for multiprocess changes, but I wouldn't be the primary
> reviewer and the author and other reviewers wouldn't be expecting me
> to review all the diffs in detail.
>
> 2. If you get a review that includes many other people, and the author
> didn't do (1), please ask them what part you're responsible for if you
> don't want to review the whole thing in detail.
>
> 3. The author should wait for approval from everybody on the reviewer
> list before checking in.
>
> 4. People who are on a review without clear review responsibility
> should be super responsive and not hold up the review. The patch
> author should feel free to ping them mercilessly if they are.
>
> 5. If you're on "FYI" person on a review and you didn't actually
> review in detail (or at all), but don't have a problem with the patch,
> note this. You could say something like "rubber stamp" or "ACK"
> instead of "LGTM." This way the real reviewers know not to trust that
> you did their work for them, but the author of the patch knows they
> don't have to wait for further feedback from you.
>
> Hopefully we can still keep everybody in the loop but have clear
> ownership and detailed reviews. It might even speed up some patches
> since I can quickly ACK patches I don't care about, and the patch
> author knows they don't have to wait for feedback from me. Or do you
> think this has too much overhead?
>
> Comments?
>
> Brett
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Accessing popup window URL from WebViewDelegate::CreateWebView()

[Marshall Greenblatt]

Hi All,

I would like to evaluate the URL that will be opened in a newly created
popup window before the view for that window is created.  It seems that the
WebViewDelegate::CreateWebView() method might be the appropriate place to do
this, but that method does not get the popup URL as an argument.   This URL
information is available in WebCore::createWindow() but is not passed into
FrameLoader::createWindow(), etc.  Is it reasonable to pass the URL through
the call chain to WebViewDelegate::CreateWebView() (which will require
changes to third_party\WebKit\WebCore), or is there a more appropriate way
to access this information before the popup window view is created in
WebViewDelegate::CreateWebView()?

Here is the relevant call chain:

WebCore::createWindow() in webkit\port\bindings\v8\v8_custom.cpp
WebCore::FrameLoader::createWindow() in
third_party\WebKit\WebCore\loader\FrameLoader.cpp
WebCore::Chrome::createWindow() in
third_party\WebKit\WebCore\page\Chrome.cpp
ChromeClientImpl::createWindow() in webkit\glue\chrome_client_impl.cc
WebViewDelegate::CreateWebView()

Thanks,
Marshall

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Portable keyboard codes

[Paweł Hajdan Jr .]

There is ongoing discussion about what views/ should really be. It's quite
possible it will make keyboard_codes.h instantly obsolete. Maybe let's wait
before using them until we have some decisions about views/

Paweł

2009/1/28 Paweł Hajdan Jr. 

> I just checked in r8804 (Add portable keyboard codes). If you want to use
> VK_ constants in your code, or are changing code which uses them, please
> instead use portable equivalents from base/keyboard_codes.h.
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux: the views situation

[Peter Kasting]

On Wed, Jan 28, 2009 at 11:56 AM, Evan Martin  wrote:

> 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.
>

(2) and (3) both sound better to me than (1), too.  I don't think Views
should be a cross-platform abstraction, in general.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] linux: tabs on top

[James Hawkins]

On Wed, Jan 28, 2009 at 11:56 AM, Evan Martin  wrote:
>
> (This is discussion of the UI independent of how it's implemented with
> views or not.)
>
> On Linux the window frame, if one even exists, is managed and drawn by
> a different process than the application.  Additionally, people use a
> variety of window managers and so there's no guarantees for the way a
> frame will look.  So there's no way to draw into it like we do on
> Windows.
>
> Two options:
> 1) Set the hint that turns off window frame drawing, and render
> something that looks like the Windows one.  This would mean
> implementing window dragging via the title bar, etc. manually.  (Ben's
> "magic browzr" work was undoing code like this on Windows, because
> it's endless pain.  I think it may be less pain for us but it'd still
> be bad.)  The right-click menu on the frame would be wrong.
>
> 2) Give up, and just make the tabs flush with the top of the window we
> have.  This is probably ugly in the general case (since there will be
> an edge between the title bar and tabs), but will work in all
> situations.
>

What about rolling out 2) initially, then implement 1) as a 'group 20%
project', the group being the linux team?  That work could be done in
a branch, and if we get it working, merge the branch and start
testing; otherwise, drop it if it ends up being a waste of time.

--
James Hawkins

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] linux: tabs on top

[Evan Martin]

(This is discussion of the UI independent of how it's implemented with
views or not.)

On Linux the window frame, if one even exists, is managed and drawn by
a different process than the application.  Additionally, people use a
variety of window managers and so there's no guarantees for the way a
frame will look.  So there's no way to draw into it like we do on
Windows.

Two options:
1) Set the hint that turns off window frame drawing, and render
something that looks like the Windows one.  This would mean
implementing window dragging via the title bar, etc. manually.  (Ben's
"magic browzr" work was undoing code like this on Windows, because
it's endless pain.  I think it may be less pain for us but it'd still
be bad.)  The right-click menu on the frame would be wrong.

2) Give up, and just make the tabs flush with the top of the window we
have.  This is probably ugly in the general case (since there will be
an edge between the title bar and tabs), but will work in all
situations.

Thoughts?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] linux: the views situation

[Evan Martin]

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 o

[chromium-dev] Stabilization Effort Daily Report

[Jon]

*Report for 2009-1-28*

Recent merges have taken a bit of a toll on our layout test passing rate.
 For the last few days we have been more or less flat on our progress.  We
are still on pace but we are losing that buffer that we will certainly need
as we get into the harder bugs.

In the last few days we have made significant progress on the Issues with
label:stable, as you can see by the graph at the bottom of this email.  I
really appreciate everyone who has contributed fixes recently.  I have been
trying very hard to review each of the open issues to throw out issues that
do not apply and to ask for reductions or repro steps on everything.  I hope
when you pull up a bug to work on it that you have the information you need.
 If you don't -- email me.

If you are frustrated with http://crash you may want to try Dremel with
Crash.  Anthony sent out an email about this a little while ago.  It
provides you with a SQL-ish interface to Crash.  If you have a useful query
I would appreciate it if you would share it with the class.  :)


*Layout Tests*

Our progress over the last few days has been flat.  We need to get below
that 300 bug line.  I am working on making the spreadsheet better.
 Hopefully I will get those changes in today.

[image: All+Tests=78.1][image: Want+To+Pass=95.6]



[image: History of passing tests
%]
  Be sure to sign up at
http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJA&hl=en if you
are going to work on a layout test.  We don't want to step on each other's
toes.

All Tests is based on all available layout tests including those that we are
currently not trying to pass.  There are tests in this group which are known
to be bad or relate to future technologies.


Want to Pass is based on the tests that we need to be passing before we will
ship a revision of the browser.  Getting this number as high as possible is
the goal of the stabilization effort.  Some of these tests are failing due
to subtle changes that require the test to be re-baselined.



Crashers

Of the 26 crashers we have assigned to "stable" we have resolved 18!


*Purify Bugs (Memory)*

We have resolved 35 of the 77 Purify issues.


*Regressions*

We have resolved 21 of 26 regressions.  The bad news here is that there
appear to be some regressions that are missing the stable label and not
showing up in the query.  I will be looking for those over the next couple
days.


*Other bugs*

We have also resolved 22 of the 53 "other" bugs.


So our bug burndown chart looks like this:

   I reset the blue line after a bunch of Purify bugs from UI tests landed
all at once.  As long as we keep the red line below the blue line we are on
track for the bugs.  Keep in mind that this does not include the work on
Layout Tests.

You will find a lot more information about the Stabilization effort on the
Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on the default plugin

[Marshall Greenblatt]

The patch is now available for review:  http://codereview.chromium.org/19625

Thanks,
Marshall

On Tue, Jan 20, 2009 at 3:27 PM, John Abd-El-Malek  wrote:

> Perhaps something like PluginList::AddExtraPluginPath can be added which
> takes the parameters you mentioned.  This should be easy to do, I'd be happy
> to review it if you send me a patch :)
>
>
> On Tue, Jan 20, 2009 at 12:00 PM, Marshall Greenblatt <
> magreenbl...@gmail.com> wrote:
>
>> I agree, registering with a WebPluginInfo and function pointers would be
>> the ideal solution :-).
>>
>>
>> On Tue, Jan 20, 2009 at 2:57 PM, Avi Drissman  wrote:
>>
>>> In that case, registering with a WebPluginInfo/function pointers would be
>>> better than keeping around PluginVersionInfo. Real data structures FTW.
>>>
>>> Avi
>>>
>>>
>>> On Tue, Jan 20, 2009 at 2:51 PM, Marshall Greenblatt <
>>> magreenbl...@gmail.com> wrote:
>>>
 My immediate usage case is for the chromium embedded framework (CEF):
 http://code.google.com/p/chromiumembedded/

 CEF supports plugins that are an integrated part of the container
 application.  For instance, consider a medical viewing application where 
 the
 complete user interface is an embedded browser window.  An internal plugin
 is embedded in the browser window for viewing medical scan images.  The
 plugin depends on the medical viewing application (cannot function
 independently), and so we compile both the viewing application and the
 plugin into a single executable.

 Currently, CEF must duplicate the entire webkit\glue\plugins directory
 in order to make the minor changes necessary to support this capability.  
 If
 we could dynamically register internal plugins via PluginLib then we could
 eliminate the code duplication.

 I imagine dynamically registering internal plugins (as part of an
 extension, for instance) might also be a useful capability once the 
 chromium
 extension framework is in place.



 On Tue, Jan 20, 2009 at 2:29 PM, Avi Drissman  wrote:

> I'm trying to figure out a way to get away from PluginVersionInfo as
> it's very Win32-centric.
>
> BTW, what's the scenario that you have in mind that dynamic
> registration would help with? If we're making changes here, we should take
> your usage needs into account.
>
> Avi
>
>
> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
> magreenbl...@gmail.com> wrote:
>
>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> It would also be nice if we had a public method for registering
>>> internal plugins dynamically, instead of having to modify the
>>> g_internal_plugins array in plugin_lib.cc.
>>>
>>> For instance (based on the current code):
>>>
>>> PluginLib::RegisterInternalPlugin(PluginVersionInfo version_info,
>>> NP_GetEntryPointsFunc
>>> np_getentrypoints,
>>> NP_InitializeFunc
>>> np_initialize,
>>> NP_ShutdownFunc
>>> np_shutdown);
>>>
>>> This would be functionally equivalent to adding an entry to the
>>> existing g_internal_plugins array, but would be run-time accessible from
>>> elsewhere in the code base.
>>>
>>> On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek >> > wrote:
>>>
 It seems that the only reason this code is needed is to get the
 function pointers for the internal plugin.  Perhaps the 
 PluginVersionInfo &
 InternalPluginInfo stuff could be taken out of the platform independent
 code.  ReadWebPluginInfo can be modified to return both the 
 WebPluginInfo &
 the three function pointers (if it's an internal plugin).  What do you
 think?


 On Tue, Jan 20, 2009 at 9:33 AM, Avi Drissman wrote:

> I'm looking at InternalPluginInfo in plugin_lib.h. Its first
> component is a PluginVersionInfo, which is basically the Win32 
> version of
> the NPAPI data. Right now my plugin info parsing code pulls info from 
> either
> a plist (via CFBundle) or resources, and neither is easy to reuse to 
> parse a
> set of strings. What format does Linux have? Could we reuse the code?
>
> Avi
>
>
>



>>>
>>
>>
>>
>

>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Portable keyboard codes

[Paweł Hajdan Jr .]

I just checked in r8804 (Add portable keyboard codes). If you want to use
VK_ constants in your code, or are changing code which uses them, please
instead use portable equivalents from base/keyboard_codes.h.

This change will make possible porting few more files in chrome/views/, for
example link.cc (I'm going to submit a changeset).

Constant values in base/keyboard_codes_posix.h might change in the future,
when we'll be getting some keyboard codes from GTK.

Paweł

(convenient link to revision:
http://src.chromium.org/viewvc/chrome?view=rev&revision=8804)

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---