Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
I'm fine with the Firefox way. It seems OK for command line inputs to require more strictly validated inputs for URLs, and to follow shell semantics for handling files. -Ben On Wed, Jan 13, 2010 at 7:42 AM, Paweł Hajdan jr phajdan...@gmail.com wrote: Michał, Chris: could you comment on security aspects and give some recommendations? Ben, could you comment on the user interaction / usability aspect? We have few choices here, I'm not sure which one is preferred. On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Recovering from browser crashes
And in that case we can hopefully use this for session restore too. -Ben On Sun, Dec 20, 2009 at 10:20 PM, Darin Fisher da...@chromium.org wrote: It's already been said, but this was something we considered in the very beginning. There's a lot of state in the browser buried in classes that are not designed to be restarted. We have had enough trouble resetting state in the browser corresponding to a tab that crashed and reloaded. One thing that might help is to factor the browser process into two. If we can carve off a meaningful chunk, perhaps we can also design that chunk to be restartable. It might help to look at what parts of the browser process have had the most crash bugs. Maybe anything that doesn't happen on the UI thread (gross approximation)? -Darin On Fri, Dec 18, 2009 at 9:13 AM, Adam Barth aba...@chromium.org wrote: Currently our multiprocess architecture lets the browser keep going when one of its tabs crash, but why can't we keep the tabs going when the browser crashes? At a high level, imagine we had a watchdog process that kept track, essentially, of the tab model and the navigation controllers. When the browser process crashes, we could use this information to do something like session restore, but instead of reloading the tabs from the network, we could re-attach to the tab processes that are already running. There's some trickiness revolving around in-flight requests from the renderer processes to the browser process (such as synchronous XMLHttpRequests), but that seems like a solvable problem. Basically, the approach would be to respond to any in-flight requests with failure messages. Thoughts? Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline -open-in-new-window switch
Why do we need to provide parity with other apps?
Do you understand how bloated we will become if we extend this to every
feature someone likes?
-Ben
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher da...@chromium.org wrote:
The popup blocker might interfere with that, but even if it doesn't, it
seems
unsavory to reveal these navigations to an existing page. (The page could
override and intercept the 'open' method.)
I think for parity with other apps, we should provide a command line switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
we could expose other dispositions.
-Darin
On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin e...@chromium.org wrote:
On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting pkast...@google.com
wrote:
On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth
clem...@endorphin.org
wrote:
http://codereview.chromium.org/464060 adds the small one-line feature
to open an URL in a new window from commandline
I wonder if you could hack it without a code change by converting URLs
into something like javascript:window.open('http://myurl') or
however that function works.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline -open-in-new-window switch
Ah, OK in that case it sounds fine.
-Ben
On Mon, Dec 14, 2009 at 10:48 AM, Darin Fisher da...@chromium.org wrote:
This was explained by Mike Mammarella above.
-Darin
On Mon, Dec 14, 2009 at 10:46 AM, Ben Goodger (Google)
b...@chromium.orgwrote:
What does proper desktop integration mean?
-Ben
On Mon, Dec 14, 2009 at 10:44 AM, Darin Fisher da...@chromium.orgwrote:
This seems like a very small addition to support proper desktop
integration.
-Darin
On Mon, Dec 14, 2009 at 10:38 AM, Ben Goodger (Google) b...@chromium.org
wrote:
Why do we need to provide parity with other apps?
Do you understand how bloated we will become if we extend this to every
feature someone likes?
-Ben
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher da...@chromium.orgwrote:
The popup blocker might interfere with that, but even if it doesn't, it
seems
unsavory to reveal these navigations to an existing page. (The page
could
override and intercept the 'open' method.)
I think for parity with other apps, we should provide a command line
switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
we could expose other dispositions.
-Darin
On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin e...@chromium.orgwrote:
On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting pkast...@google.com
wrote:
On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth
clem...@endorphin.org
wrote:
http://codereview.chromium.org/464060 adds the small one-line
feature
to open an URL in a new window from commandline
I wonder if you could hack it without a code change by converting URLs
into something like javascript:window.open('http://myurl') or
however that function works.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
My opinion remains the same. Note that the dialog box as presented seems to have some layout issues that cause it to be taller than needed (see formatting in the sync section at the top). However, I suggest having the dialog box move (scroll) on screen as you move your mouse to the screen edge. -Ben On Tue, Dec 8, 2009 at 3:30 PM, Evan Stade est...@chromium.org wrote: On Tue, Dec 8, 2009 at 3:22 PM, Tony Chang t...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=18949 Yes, I suppose this problem is not new, but it has gotten worse. Has recent progress been made on that bug? It has been Started for months, seemingly. Also, does Matt M intend to fix it on all platforms? Is the scroll view his solution? Seems strange, since Ben's last response on the bug was: None of our dialog panels other than under the hood should be scrollable. I suggest ignoring this bug for now. This comment was posted on Sep 29, so, let's revisit it. On Tue, Dec 8, 2009 at 3:18 PM, Evan Stade est...@chromium.org wrote: With the addition of bookmark sync and form autofill, this tab is getting rather tall (see attachment, ignore the blank space above synchronize bookmarks, which is a separate bug). Do we need to move some stuff to Under the Hood, or add a scroll bar? -- Evan Stade -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev http://code.google.com/p/chromium/issues/detail?id=18949 -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
On Tue, Dec 8, 2009 at 3:45 PM, Evan Stade est...@chromium.org wrote: On Tue, Dec 8, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: My opinion remains the same. Note that the dialog box as presented seems to have some layout issues that cause it to be taller than needed (see formatting in the sync section at the top). so, despite that it is taller than the screen for netbooks, or even many notebooks by now, hanging off the edge of the screen is better than a scrollbar or a new tab? Yes. However, I suggest having the dialog box move (scroll) on screen as you move your mouse to the screen edge. I'm not really sure what this means, is there an example of this UI somewhere? The closest thing I can think of is on some displays where you set the resolution to larger than what the display can do, the display becomes a view port and slides the viewport around as you touch the screen edges. I recommend doing that for this dialog box. -Ben -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
BTW I am being a curmudgeon here for two reasons: - I have a deep aesthetic opposition to scrollbars in dialog boxes. Yes, I know Under the Hood has one, but that panel is sort of exempt because it's a) a sewer, and b) it has a white background that makes it look like a scrolling list. To me, a scrolling dialog box looks like my first Visual Basic app. Just because it only appears on small screen sizes doesn't make me feel any better about it. - I don't want to make it easy to add more crap. Providing the capability to scroll adds a crutch that allows this to be done. We could also push the password saving options into the password manager sub-dialog. Ditto for autofill once James is done improving it and adding a more elaborate autofill manager window. We could also get rid of the horizontal rules in the dialog and bring the sections slightly closer together. As a general comment, I am somewhat resentful that manufacturers are shipping these diabolical screen resolutions. -Ben On Tue, Dec 8, 2009 at 4:18 PM, Peter Kasting pkast...@google.com wrote: On Tue, Dec 8, 2009 at 4:11 PM, Evan Stade est...@chromium.org wrote: proposals on which of these options (again, see original attachment) to rip out are welcome and within the scope of this thread. Off the top of my head: * We have crazy word wrapping. The bookmark sync text could fit on one line. Why does it wrap? etc. elsewhere * What is with the blank line below that text? * Show Saved Passwords button should be vertically level with offer to save passwords radio button, horizontally on right side of dialog (a la Firefox) * Save passwords/save form values could perhaps be combined into one section heading * Does the explanatory text under browsing data add much? Maybe rip it out and make the button text longer if we need clarity (Import data from another browser...) * Appearance section is a mess. Why are there buttons for GTK/Classic theme when it looks like what's desired is a radio button pair? Why are there these other options? We should decide, based on what the user's windowmanager best supports, which combo of settings will work best and just do it. We don't give Windows Aero users a button called use classic theme or Mac users a button to use the system-style (down-hanging, square-edged) tabs. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
BTW I think the Use Gtk Theme button should be replaced by a special theme that triggers this mode, much like the default theme we have in the theme gallery. This would make the selection of this mode vs. others feel more natural wrt the others. -Ben -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
I like this idea too. -Ben On Tue, Dec 8, 2009 at 5:00 PM, Tony Chang t...@chromium.org wrote: I think the real long term goal here is to make the GTK+ theme fast and make it the default theme. Users can still add the blue classic theme via the themes page. On Tue, Dec 8, 2009 at 4:55 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I think the Use Gtk Theme button should be replaced by a special theme that triggers this mode, much like the default theme we have in the theme gallery. This would make the selection of this mode vs. others feel more natural wrt the others. -Ben -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
Oops, I'll clarify and say I like the idea of getting the frame tint from the OS and making that be the default. I think you will probably still want to have the special theme to trigger the the Gtk icon mode. -Ben On Tue, Dec 8, 2009 at 5:04 PM, Ben Goodger (Google) b...@chromium.org wrote: I like this idea too. -Ben On Tue, Dec 8, 2009 at 5:00 PM, Tony Chang t...@chromium.org wrote: I think the real long term goal here is to make the GTK+ theme fast and make it the default theme. Users can still add the blue classic theme via the themes page. On Tue, Dec 8, 2009 at 4:55 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I think the Use Gtk Theme button should be replaced by a special theme that triggers this mode, much like the default theme we have in the theme gallery. This would make the selection of this mode vs. others feel more natural wrt the others. -Ben -- 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: Multiple constrained windows
How is it implemented now? -Ben On Sat, Nov 7, 2009 at 10:18 PM, Nico Weber tha...@chromium.org wrote: Hi, some pages try to show multiple http auth dialogs at the same time ( one example is in http://crbug.com/26900 ). On linux, that happens to work fine, but on OS X it doesn't. I could change the OS X code to queue constrained windows and show only one window at a time per tab, or I could do the same thing for all platforms by putting the code in tab_contents. Any opinions out there? Nico --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
it'd be nice to have a gclient config lean or something like that. -Ben On Thu, Nov 5, 2009 at 11:42 AM, Jeremy Orlow jor...@google.com wrote: In general, it might be interesting to document how to get a more lean checkout of Chromium. On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
+1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
We should include a VM image that these tests get run inside of. ;D -Ben On Thu, Nov 5, 2009 at 12:56 PM, Pam Greene p...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:50 PM, Ben Goodger (Google) b...@chromium.org wrote: +1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). chrome/tools/test/smoketests.py Runs all the available unit tests, layout tests, page-cycler tests, etc. for a build of Chrome, imitating a buildbot. - Pam I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
Meant to hit reply-all I want to caveat this on having less flakiness. ;-) See my comments on IRC about some tests randomly making a mess of themselves then going green again. -Ben I'll also add this could be done automatically based on the set of tests we define as not flaky. I always feel less bad about being reverted when it's a mindless script doing it. ;D -Ben On Wed, Nov 4, 2009 at 12:02 PM, Peter Kasting pkast...@google.com wrote: On Wed, Nov 4, 2009 at 11:56 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: I don't think anyone suggested immediate auto revert. Ben Goodger: I am supportive of auto-revert as long as we apply it universally Kenneth Russell: I completely support immediate backouts of changes that break the tree Try bots are not perfect. They won't get all the failures. But even if it's not entirely your fault, it does not mean that your change deserves to be in the tree. Irrelevant to the argument I'm making. I claim that irrespective of what happened on the trybots, authors who break something should have a brief grace period to fix their problems. at least it won't keep the tree closed until you try to figure out what the problem is. This is why I suggested reverting if the author hasn't immediately jumped on the problem and determined the fix. I think everyone agrees that we don't want breaking changes to sit clogging the pipeline for long period of time. 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: revert now, ask questions later? WAS: Reverting a change, the fast way
The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Fwd: Switching vs2008 to be preferred when present.
It'd be nice if the defaults could be set on a per-sln level I guess. -Ben On Thu, Oct 29, 2009 at 2:30 PM, Peter Kasting pkast...@google.com wrote: On Thu, Oct 29, 2009 at 2:27 PM, Ben Goodger (Google) b...@chromium.orgwrote: VS2008 builds with /MP by default, and it's well supported, so when present there's no reason for us to not use it by default. Note that you can still force VS2005 by setting GYP_MSVS_VERSION=2005 in your environment. Note of caution for WebKit hackers: If you're building WebKit directly (e.g. ./build_webkit), you need to be using VS 2005. There's some support for VS 2008 in the WK build scripts, but the project files themselves are in 2005 format and WebKit doesn't use GYP. Someone passionate about this could try switching them over :) 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: Fwd: Switching vs2008 to be preferred when present.
It does seem slower, however never having to remember to patch the appropriate vsprops/gypi with /MP is a big win. When I was ordering the new machines I found most people on the team I asked were not doing this, and as a result their builds were 2-3x slower. -Ben On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe mbel...@google.com wrote: I've been using VS2008 on Win7 for the last month or so. I hate it. Problems: 1) Stepping in the debugger is SOOO slow. I am thinking about going back to VS2005. 2) If you turn on Intellisense, it crashes like crazy very regularly. I've turned off intellisense, but it is a big loss in productivity to do so I strongly recommend against VS2008; do others have these problems? Mike On Thu, Oct 29, 2009 at 2:27 PM, Ben Goodger (Google) b...@chromium.orgwrote: FYI. VS2008 builds with /MP by default, and it's well supported, so when present there's no reason for us to not use it by default. Note that you can still force VS2005 by setting GYP_MSVS_VERSION=2005 in your environment. Thanks Brad! -Ben -- Forwarded message -- From: b...@chromium.org Date: Thu, Oct 29, 2009 at 2:26 PM Subject: Re: Switching vs2008 to be preferred when present. To: bradnel...@google.com Cc: gyp-develo...@googlegroups.com LGTM http://codereview.chromium.org/341041 --~--~-~--~~~---~--~~ 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: Fwd: Switching vs2008 to be preferred when present.
Yes, this was widely publicized when discovered, yet most people won't make
the change if it's not the default.
-Ben
On Thu, Oct 29, 2009 at 3:42 PM, Jeremy Orlow jor...@chromium.org wrote:
From http://dev.chromium.org/developers/how-tos/build-instructions-windows
Ensure that /MP is enabled. You can do this by creating a file called inc
lude.gypi which contains the following lines:
{
'variables': {
'msvs_multi_core_compile': 1
}
}
Put this file in a folder called .gyp under your home directory. On
Windows, this will be something like: C:\Documents and
Settings\username\.gyp\include.gypi, or if you are on Vista:
C:\Users\username\.gyp\include.gypi. Make sure you rungclient runhooks
--force after creating this file to rebuild the project files, forcing
GYP to output /MP.
Btw, A month or two back someone posted build times from 2005 and 2008.
2005 was faster.
On Thu, Oct 29, 2009 at 2:40 PM, Ben Goodger (Google)
b...@chromium.orgwrote:
It does seem slower, however never having to remember to patch the
appropriate vsprops/gypi with /MP is a big win. When I was ordering the new
machines I found most people on the team I asked were not doing this, and as
a result their builds were 2-3x slower.
-Ben
On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe mbel...@google.com wrote:
I've been using VS2008 on Win7 for the last month or so.
I hate it.
Problems:
1) Stepping in the debugger is SOOO slow. I am thinking about going
back to VS2005.
2) If you turn on Intellisense, it crashes like crazy very regularly.
I've turned off intellisense, but it is a big loss in productivity to do so
I strongly recommend against VS2008; do others have these problems?
Mike
On Thu, Oct 29, 2009 at 2:27 PM, Ben Goodger (Google)
b...@chromium.orgwrote:
FYI.
VS2008 builds with /MP by default, and it's well supported, so when
present there's no reason for us to not use it by default. Note that you
can
still force VS2005 by setting GYP_MSVS_VERSION=2005 in your environment.
Thanks Brad!
-Ben
-- Forwarded message --
From: b...@chromium.org
Date: Thu, Oct 29, 2009 at 2:26 PM
Subject: Re: Switching vs2008 to be preferred when present.
To: bradnel...@google.com
Cc: gyp-develo...@googlegroups.com
LGTM
http://codereview.chromium.org/341041
--~--~-~--~~~---~--~~
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: How can we kill scons?
Step 2: ??? Step 3: Profit! -Ben On Wed, Oct 28, 2009 at 12:35 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Wed, Oct 28, 2009 at 12:34 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Not that it is effective :) Starred. :) Now what? On Wed, Oct 28, 2009 at 3:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Have you tried starring http://crbug.com/22044 ? On Wed, Oct 28, 2009 at 3:28 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If I'm not mistaken, I think like most everyone running on linux is using the make build nowadays, and the make build seems to work well enough for most people. The only time I hear someone mention the scons build, it's in reference to you broke the scons build, or so you developed on make. Did you check it worked on scons? Given that, what's keeping us from killing the scons build completely? My current motivation for asking is that I've been spending the last hour trying to figure out why scons is deciding to insert an -fPIC into my build, whereas make is not. This is on top of my previous motivation (from about 3 days ago) where I spent another few hours making something that worked fine on the make build, scons compatible. I'd rather spend that time killing scons if there was a clear list of what was needed to make that happen. -Albert --~--~-~--~~~---~--~~ 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: RFC: AutoFill++ Design Document
We need to come up with a way, if we also want to implement omnibox-style inline autocomplete for web page autofill. (a separate bug). -Ben On Wed, Oct 21, 2009 at 11:52 PM, Darin Fisher da...@chromium.org wrote: Ah, OK. That sounds like a good solution. I don't know how to implement that, but maybe there is already a way. -Darin On Tue, Oct 20, 2009 at 1:54 PM, Nick Baum nickb...@chromium.org wrote: The mocks also show a preview of all the fields when hovering over or arrowing to one of the drop-down options. Is there a way to do that without showing the values to the page? -Nick On Tue, Oct 20, 2009 at 12:46 PM, James Hawkins jhawk...@chromium.orgwrote: The current design keys off autofill after the user enters a value in the name field. A drop down menu is shown allowing the user to select which profile to autofill. If the user does not select a profile, the form will not be autofilled (using AutoFill++). I'll try to clarify this in the doc. Thanks, James On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.orgwrote: One security concern: Autofill should not give users information to the page until the user makes some gesture to accept the autofill choices. For the existing autofill, this is done by having the user choose from the drop down menu. The page can read the value of an INPUT field once it is set, so you have to be careful. I wonder if a solution already exists to support Safari's autofill. -Darin On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote: Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. Thanks, James Hawkins *AutoFill++* *Status:* *Draft* (as of 2009-10-16) *James Hawkins** jhawk...@chromium.org Modified: Fri Oct 16 2009 * Objective The purpose of this document is to describe a significant improvement in the current form autofill feature of Google Chrome. The current implementation is less of a form autofill and more of a form history. This approach has some limitations: - Values are saved per-site, so a Name value saved on penguin.comwill not be suggested for the Name field on turtle.com. - The form must be filled out field-by-field. I am proposing a new approach to form filling based on the client/server statistic-based model implemented by Google Toolbar. This feature provides the following benefits: - Forms are completely auto-filled. - Values are saved in user profiles, so the Name field can be auto-filled for a form on a site one has never visited. Background The main problem with the current autofill feature is that the user must move from field to field to fill out a form, even when each field can be auto-filled. The history is site-specific, so the user must enter form data for each site before autofill can be useful. Overview To use the AutoFill++ feature in Google Chrome, the user must enter personal information (name, address, email, etc.) into a form on any site and submit this form. An infobar will ask the user if he wants to enable autofill, and if so, AutoFill++ will parse the form data and query the autofill server for the field types. If the server knows the field types for the form on this particular site, AutoFill++ will match the data with the fields; otherwise, a heuristic based on the names of the fields and how they are layed out on the form is used to make this match. The map of (field, data) will then be saved in the user form data database. When the user starts entering information into any other form, a list of saved profiles will be presented to the user in a selection drop-down. After picking a profile, AutoFill++ will autofill all fields that it knows about and has information in the database for. The user will be able to enter additional profile information at any time through the AutoFill++ dialog. This dialog will be shown after the user first enters form information, and will also be available through the options dialog. Note that no personal information will be sent to the autofill server, just the field types determined by the heuristics. Detailed Design The first step in implementing AutoFill++ is to rename the current AutofillForm data structures to better match their behavior: FormFieldHistory. Just like Toolbar AutoFill++, the client will implement some strategies to reduce the bandwitdth on the autofill server. These include: - Ignore common search forms by ignoring forms that contain only one textfield with an id of q. - Ignore forms using the GET method to submit for data. - Ignore forms that have the word search in the target url for that form. - Using a flag in the query response from the server to tell the client whether or not it should upload the data if a user submits this form. *Data Structure* *Description* *AutoFillForm* The container that holds the
[chromium-dev] Re: RFC: AutoFill++ Design Document
Right. I am just wanting to match the inline behavior... using the omnibox these days I tend to notice when I have to down arrow into things to complete, so it's definitely a pain point for in-page autocomplete. -Ben On Thu, Oct 22, 2009 at 9:56 AM, Peter Kasting pkast...@google.com wrote: On Thu, Oct 22, 2009 at 9:39 AM, Ben Goodger (Google) b...@chromium.orgwrote: We need to come up with a way, if we also want to implement omnibox-style inline autocomplete for web page autofill. (a separate bug). Passing comment: This would be really cool but potentially a lot of work depending on the underlying data structures. We definitely can't reuse the Omnibox machinery. Just didn't want anyone's hopes to be artificially high. 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] Reminder: File bugs for behavior changes on different platforms!
I know I sent this out a few weeks ago but I'm still hearing that it's a problem so: When you change the behavior of the UI on one platform, please file a separate bug for each platform that doesn't implement this behavior change. Please make the following modifications to the new bug: - add the PlatformParity label - mark the new bug as blocking the original bug for the work, even if the original bug is now or soon will be closed. Right now we are pushing comprehensive platform parity bugs into Mstone:5. -Ben --~--~-~--~~~---~--~~ 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: Reminder: File bugs for behavior changes on different platforms!
+laforge I'll let Anthony explain. -Ben On Tue, Oct 20, 2009 at 11:21 AM, Aaron Boodman a...@chromium.org wrote: On Tue, Oct 20, 2009 at 11:16 AM, Ben Goodger (Google) b...@chromium.org wrote: - mark the new bug as blocking the original bug for the work, even if the original bug is now or soon will be closed. Can you explain more what you mean by this? What is the way to mark a bug as blocking? How can the blockee be closed if it is blocked by another bug that is open? - a --~--~-~--~~~---~--~~ 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: RFC: AutoFill++ Design Document
The theory is that you would start typing in one of the fields, the traditional autofill UI (dropdown) would appear and selecting an item would be equivalent to granting the form to be filled out. -Ben On Tue, Oct 20, 2009 at 12:43 PM, Darin Fisher da...@chromium.org wrote: One security concern: Autofill should not give users information to the page until the user makes some gesture to accept the autofill choices. For the existing autofill, this is done by having the user choose from the drop down menu. The page can read the value of an INPUT field once it is set, so you have to be careful. I wonder if a solution already exists to support Safari's autofill. -Darin On Tue, Oct 20, 2009 at 10:13 AM, James Hawkins jhawk...@chromium.orgwrote: Hi, please read the inlined proposed design for AutoFill++. Any feedback and comments are appreciated. Thanks, James Hawkins *AutoFill++* *Status:* *Draft* (as of 2009-10-16) *James Hawkins** jhawk...@chromium.org Modified: Fri Oct 16 2009 * Objective The purpose of this document is to describe a significant improvement in the current form autofill feature of Google Chrome. The current implementation is less of a form autofill and more of a form history. This approach has some limitations: - Values are saved per-site, so a Name value saved on penguin.com will not be suggested for the Name field on turtle.com. - The form must be filled out field-by-field. I am proposing a new approach to form filling based on the client/server statistic-based model implemented by Google Toolbar. This feature provides the following benefits: - Forms are completely auto-filled. - Values are saved in user profiles, so the Name field can be auto-filled for a form on a site one has never visited. Background The main problem with the current autofill feature is that the user must move from field to field to fill out a form, even when each field can be auto-filled. The history is site-specific, so the user must enter form data for each site before autofill can be useful. Overview To use the AutoFill++ feature in Google Chrome, the user must enter personal information (name, address, email, etc.) into a form on any site and submit this form. An infobar will ask the user if he wants to enable autofill, and if so, AutoFill++ will parse the form data and query the autofill server for the field types. If the server knows the field types for the form on this particular site, AutoFill++ will match the data with the fields; otherwise, a heuristic based on the names of the fields and how they are layed out on the form is used to make this match. The map of (field, data) will then be saved in the user form data database. When the user starts entering information into any other form, a list of saved profiles will be presented to the user in a selection drop-down. After picking a profile, AutoFill++ will autofill all fields that it knows about and has information in the database for. The user will be able to enter additional profile information at any time through the AutoFill++ dialog. This dialog will be shown after the user first enters form information, and will also be available through the options dialog. Note that no personal information will be sent to the autofill server, just the field types determined by the heuristics. Detailed Design The first step in implementing AutoFill++ is to rename the current AutofillForm data structures to better match their behavior: FormFieldHistory. Just like Toolbar AutoFill++, the client will implement some strategies to reduce the bandwitdth on the autofill server. These include: - Ignore common search forms by ignoring forms that contain only one textfield with an id of q. - Ignore forms using the GET method to submit for data. - Ignore forms that have the word search in the target url for that form. - Using a flag in the query response from the server to tell the client whether or not it should upload the data if a user submits this form. *Data Structure* *Description* *AutoFillForm* The container that holds the (field, value) pairs, parsed from HTML. *RenderViewHostDelegate::AutoFill* An interface implemented by a class that wants to be notified of AutoFill events from the RenderView *AutoFillService* The main AutoFill++ class. Coordinates between the RenderView, the autofill server, and the PersonalDatabaseManager Each TabContents has one, and each instance is lazily created. *AutoFillQueryXMLParser *Builds and parses XML queries that are sent to and received from the autofill server. *AutoFillDownloadThread* Spins off a new thread to download/upload data to the autofill server. *AutoFillProfileDialog* The UI for displaying the AutoFill++ profile dialog. *PersonalDatabaseManager* The gateway between the AutoFillService and the profile database. *AutoFillProfile* Contains all
[chromium-dev] UI across multiple platforms
Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -Ben --~--~-~--~~~---~--~~ 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: UI across multiple platforms
That sounds like the best plan to me. This way there can be separate owners. -Ben On Wed, Oct 7, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -Ben --~--~-~--~~~---~--~~ 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: Converting dialogs to infobars
Can you make sure a bug is filed to get this into the other platforms? -Ben On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman a...@chromium.org wrote: On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. 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] Re: Converting dialogs to infobars
It's great to re-use strings where it seems elegant. We should make sure our UX matches in substance on all platforms. This is especially important for help center docs, which may screenshot one platform. -Ben On Tue, Oct 6, 2009 at 3:30 PM, Avi Drissman a...@chromium.org wrote: Will do first thing tomorrow. Avi /who figured it was OK since the string was already in the grd file On Tue, Oct 6, 2009 at 6:25 PM, Ben Goodger (Google) b...@chromium.org wrote: Can you make sure a bug is filed to get this into the other platforms? -Ben On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman a...@chromium.org wrote: On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. 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] Re: Converting dialogs to infobars
OK let's make the change for multiple downloads, but not for protocols. If you fix the bug on linux, please make sure the bug is filed for mac/windows. Thanks! -Ben On Tue, Oct 6, 2009 at 3:37 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 3:18 PM, Glen Murphy g...@chromium.org wrote: Multidownload infobar SGTM, though I'm pretty sure I've seen the multiple download dialog appear after user input (could be for downloads initiated via JS or iframe POSTS). The multidownload dialog is launched specifically when there was a download started without user input, where user input == enter, space or click anywhere in the page, so it doesn't matter by which mechanism the download is initiated; it just matters whether the user did something. This is of course racy and heuristic. External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. Chatted briefly w/Brian he seemed to agree about multiple download dialog, Glen what do you think? -Ben On Tue, Oct 6, 2009 at 3:02 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 1:12 PM, Ben Goodger (Google) b...@chromium.org wrote: We should only use infobars for things that aren't initiated by a user action. They are very confusing for user initiated actions since they are harder to notice. In each of these cases, can you determine whether or not a user action caused them? for the multiple download dialog, a user action definitely did not cause it. for the external protocol handler, a user action usually did cause it (but sometimes not). I don't think there's any way of knowing for sure. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW this is something that we want to pursue independently of whether or not it's in HTML5... we already have app frames/app shortcuts, we would like to streamline this some. If someone wants to work with other vendors to come up with a standardized version great, so long as the UA controls the UX and can extend the feature set in a compatible way. -Ben On Fri, Oct 2, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.org wrote: I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
Depends if we want it to feel webby or dialoggy. Unsure yet. Good case for either way. Will keep it in mind. -Ben On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote: I'd like to suggest early on that it's done in HTML for the usual reasons. (And also that there are the usual negatives. Just wanna plant the seed.) In particular, a meta-page page would allow the typical operations on subresource links (click to view; media playing would work in-browser; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek rse...@chromium.org wrote: For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ 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: Chrome Keyboard Access, opinions?
Indeed. We need to be very careful not to over-use keyboard shortcuts. We will regret it later if we do. -Ben On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote: On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com wrote: On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour m...@chromium.org wrote: CTRL+SHIFT+T --- Main Toolbar CTRL+SHIFT+B --- Main Bookmarks bar CTRL+SHIFT+E --- Extension bar I really don't like this. These are hard to discover and use. Besides, you can't use two of these three: ctrl-shift-t is reopen closed tab and ctrl-shift-b is open bookmarks manager. I agree with Peter here. It seems like when these bars are open, their contents should be in the tab order. You should be able to tab through the contents of a page, into the chrome, and eventually back into the page. I don't think most folks want tab from the omnibox to take you through the menus, then bookmark buttons. I know that would drive me batty. I could see some users wanting it, but I don't think it should be the default. If all we care about is keyboard accessibility, then we should make the accelerator that gives focus to the location bar tab through all open bars. This addresses the issue of making everything reachable via the keyboard, but it definitely requires a lot of tabbing. Perhaps we also need the ability to assign accelerators to individual bookmarks/extensions. -Scott --~--~-~--~~~---~--~~ 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: Chrome Keyboard Access, opinions?
Building on what we already have sounds good to me. -Ben On Tue, Sep 29, 2009 at 5:03 PM, Jonas Klink (Google) kl...@chromium.org wrote: So, to clarify, we would then use ALT+SHIFT+T (currently focusing the toolbar), to cycle keyboard focus through any open toolbars (toolbar-bookmark bar-infobar (restore tabs etc, if visible)-Extensions toolstrips). Does that makes sense to everyone? The shortcut is not ideal, but it might be the best we've got... On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet s...@chromium.org wrote: I would just use the existing accelerator we have to focus the toolbar. -Scott On Tue, Sep 29, 2009 at 3:58 PM, Mohamed Mansour m...@chromium.org wrote: What kind of accelerators do would you like to have? Maybe have a accelerator that traverses only toolbars, and once we are in that toolbar, we can tab through the widgets. -Mohamed On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting pkast...@google.com wrote: On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote: On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com wrote: It seems like when these bars are open, their contents should be in the tab order. You should be able to tab through the contents of a page, into the chrome, and eventually back into the page. I don't think most folks want tab from the omnibox to take you through the menus, then bookmark buttons. I know that would drive me batty. I could see some users wanting it, but I don't think it should be the default. I admit that I totally failed to think through tab in the omnibox -- I was thinking about all the other cases. That said, we've had TONS of requests to make tab from the omnibox work differently (i.e. like how other browsers do it): * When the popup is open, tab rotates through its items * Otherwise, tab moves to the next focusable element I kind of regret that we picked tab for tab to search because it prevents both of these, and I'm not sure we can change it now. It does seem like a bug somehow that you can tab into the omnibox but not out, but I don't know how to fix :( Perhaps we also need the ability to assign accelerators to individual bookmarks/extensions. This has been requested a few times, and brakowski suggested it long ago as a replacement for the home button -- if you can drag a bookmark onto your main toolbar, and give it an alt-home shortcut, then you have your own home button. 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: Build time doubled since May - what gives?
I would be surprised if it were just the addition of code. Bear in mind the May 7 minute figure includes all of WebKit, and I don't think that's doubled in size since then? So it seems like it must be something more related to the build system itself. I don't think it's incremental linking, since my build was a clean build. -Ben On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter n...@chromium.org wrote: I'll volunteer to fix any build issues created as a result of sync. Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the bulk are signed/unsigned warnings. I'll put together a change to suppress those. - nick On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. 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: [DESIGN DOC] registerProtocolHandler HTML5 API
We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Build time doubled since May - what gives?
I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Question about UI and classic views
One day, we may offer further customization of this page. This may include the ability to show more items. I think this is preferable to a classic view option, which sets a bad precedent - that every time we make a UI change we'll carry the burden of supporting the old way too forever. It adds to the testing matrix and raises the opportunity cost of making ambitious UI changes. -Ben On Wed, Sep 23, 2009 at 8:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ 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: Question about UI and classic views
Note that this mode will probably vanish, it's a figment of the transition. -Ben On Wed, Sep 23, 2009 at 9:08 PM, Mohamed Mansour m...@chromium.org wrote: If you want to use the old new tab page, you can add this chrome switch ( --old-new-tab-page ) I personally like the 3x3 grid. I have a 24 screen and the new tab page is so tiny, would of been nice if the user could fully customize it, that is one of the popular features people want on the Chrome forums. - Mohamed Mansour On Wed, Sep 23, 2009 at 11:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ 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: Shipping features behind a run-time flag can sometimes still be dangerous
Indeed. BTW I filed http://crbug.com/18577 so it'd be easier to find (and copy-paste) the command line flags used for a build. We can add this to the default template if it'd be useful. -Ben On Mon, Sep 21, 2009 at 4:37 PM, Darin Fisher da...@chromium.org wrote: I agree. Our practice of releasing experimental features default disabled behinda command line flag is extremely valuable. We should make sure that this works well for new web APIs. It will continue to be a valuable tool down the road. It is important that we have features available in stable, beta, and dev channels this way. Otherwise, what we ship to stable is not the same build configuration as what we ship to beta, and that can cause even more problems. -Darin On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman a...@chromium.org wrote: It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? - a On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge lafo...@google.com wrote: That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860 ) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. J --~--~-~--~~~---~--~~ 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: Clear Strict-Transport-Security state checkbox added
Thanks! On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Verdict: Menu string casing
For Mac, we're creating copies of some strings with Title Case for menu items rather than the Sentence case we use on Windows. (Windows Vista HIG recommends Sentence case, Mac recommends Title Case). It sounds like Linux wants Title Case too so it should just use those strings. We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. That is all. -Ben --~--~-~--~~~---~--~~ 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: Verdict: Menu string casing
Preferences vs Options is one such exception. Quit vs. Exit is another. Let me know if there are others. -Ben On Wed, Sep 16, 2009 at 1:20 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 1:07 PM, Ben Goodger (Google) b...@chromium.org wrote: We will not duplicate strings for any other reason unless they refer to a concept that does not exist on the relevant platform. The idea is that we should have a single set of string content (independent of casing) that documentation can refer to. To be clear, that means splitting along platform conventions for stuff like Preferences vs Options is out? (Don't have a strong opinion, just curious.) --~--~-~--~~~---~--~~ 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: Removal of the Chrome window snap in Windows 7
It was my intent with Tabtastic2 that we would use the native window snap, since I am planning on re-doing tab dragging to be effectively window dragging, so it'll be easy. -Ben On Mon, Sep 14, 2009 at 7:06 PM, Mohamed Mansour m...@chromium.org wrote: Hi all, Since Windows 7 implemented system specific window snap (in many directions), what do you all think about removing it in Chrome for Windows 7 builds? Or are we planning to keep both snaps in Windows 7? - Mohamed --~--~-~--~~~---~--~~ 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: Platform parity
+1. It'd be good to involve experts from other platforms early in the process too even if the implementation is done later, so that the design considers local requirements. -Ben On Sun, Aug 30, 2009 at 9:44 PM, Mohamed Mansourm...@chromium.org wrote: I believe we should not close the tracker associated to the CL if a UI tweak should be done in all platforms, and its up to the developer to know who to delegate that task to. We shouldn't force anyone to develop this, we should properly tag the issue tracker and add proper labels. As well, we should properly cc people who are more active in that platform, so they will know what is missing. I don't know what a good solution is to cross platform development, unless everyone should produce code in all three platforms whenever they work on a patch or feature. - Mohamed Mansour On Sun, Aug 30, 2009 at 11:57 PM, Nico Weber tha...@chromium.org wrote: Hi, I happened to look at a CL today that adds a Really delete all passwords? dialog on Windows ( http://codereview.chromium.org/155291 ). The patch was done by someone relatively new to the project (which is of course great). Sadly, neither the patch author nor one of the reviewers mentioned that this change might have to be done on the other platforms as well. As it happens, it's not necessary on OS X, but it might be required on Linux. What's out approach to make sure that such UI tweaks reach all platforms? Do we require that contributors who do a UI tweak implement it on all three platforms? Do we require that contributors who do such a change open bugs for the platforms they don't do the change on and hope someone else will do the change on the other platforms? Or do we simply not worry about this too much, as it doesn't happen that often anyway? Just curious. Nico --~--~-~--~~~---~--~~ 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: Platform parity
From a UI design point of view, yes, but UI design is only one piece. Often times you benefit from having a platform expert who understands the underlying technology. -Ben On Sun, Aug 30, 2009 at 10:28 PM, PhistucKphist...@chromium.org wrote: Since user interface changes (are supposed to) go by the user interface team (some earlier thread required that), is it not part of their responsibility, to answer cross platform questions such as this one? ☆PhistucK On Mon, Aug 31, 2009 at 08:00, Ben Goodger (Google) b...@chromium.org wrote: +1. It'd be good to involve experts from other platforms early in the process too even if the implementation is done later, so that the design considers local requirements. -Ben On Sun, Aug 30, 2009 at 9:44 PM, Mohamed Mansourm...@chromium.org wrote: I believe we should not close the tracker associated to the CL if a UI tweak should be done in all platforms, and its up to the developer to know who to delegate that task to. We shouldn't force anyone to develop this, we should properly tag the issue tracker and add proper labels. As well, we should properly cc people who are more active in that platform, so they will know what is missing. I don't know what a good solution is to cross platform development, unless everyone should produce code in all three platforms whenever they work on a patch or feature. - Mohamed Mansour On Sun, Aug 30, 2009 at 11:57 PM, Nico Weber tha...@chromium.org wrote: Hi, I happened to look at a CL today that adds a Really delete all passwords? dialog on Windows ( http://codereview.chromium.org/155291 ). The patch was done by someone relatively new to the project (which is of course great). Sadly, neither the patch author nor one of the reviewers mentioned that this change might have to be done on the other platforms as well. As it happens, it's not necessary on OS X, but it might be required on Linux. What's out approach to make sure that such UI tweaks reach all platforms? Do we require that contributors who do a UI tweak implement it on all three platforms? Do we require that contributors who do such a change open bugs for the platforms they don't do the change on and hope someone else will do the change on the other platforms? Or do we simply not worry about this too much, as it doesn't happen that often anyway? Just curious. Nico --~--~-~--~~~---~--~~ 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: Formatting substrings in a views::Label
I actually don't like having a mix of HTML/native UIs in the product. When we switched to the NTP from the old Destinations page we made the decision to have the content of tabs feel webby and the content of dialogs feel dialoggy. As a result the NTP now feels pleasantly webby, but many of the HTML dialogs don't feel dialoggy (focus issues, key accelerators, etc). -Ben On Wed, Aug 26, 2009 at 11:43 PM, Tim Steelet...@chromium.org wrote: fwiw, another way to write a dialog like this platform independently without an extra abstraction for Label would be to use our html UI; that's what I did for the sync setup dialog/wizard flow, and so far so good! On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman a...@chromium.org wrote: I'm playing with different ideas for the extension install dialog, and would like to do something like the attacked mock. I can see that there is no support for this in Label presently and I'm told by Dean that the APIs for doing this are different across platforms. Is it worth adding an abstraction to Label for this? - a --~--~-~--~~~---~--~~ 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: Copying of profiles across systems
BTW we have two separate prefs files, Preferences and Local State to support this sort of thing in the pref system at least. Whether or not people put the right settings in the right data stores is another question. -Ben On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissmana...@google.com wrote: I've heard people proclaim the principle of being able to copy a profile across systems as being a deciding factor for certain changes (e.g. the history epoch change). However, it doesn't seem to be universally held or obeyed, and I'm not sure to the extent to which it can be obeyed. So some questions: - Is profile platform independence a guiding principle? - To what extent do we work to make it reality? - In the cases where it can't be kept (e.g. download folder path) should we keep a copy for each platform? - Is it worth rewriting today's code that doesn't conform (e.g. extensions and themes which use full paths and platform path separators)? 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] Re: Copying of profiles across systems
Note that even upgrading Windows OS from XP to Vista involves changing paths: c:\Documents and Settings - c:\Users Do we ever write paths such as this? Local state should be data that can be thrown away without much loss of user experience. Generally these things include window positions, file system paths etc. It is much more desirable to share personal data (the contents of my NTP, omnibox, etc) across machines and OSes. -Ben On Wed, Aug 26, 2009 at 1:33 PM, John Abd-El-Malekj...@chromium.org wrote: On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissmana...@google.com wrote: I've heard people proclaim the principle of being able to copy a profile across systems as being a deciding factor for certain changes (e.g. the history epoch change). However, it doesn't seem to be universally held or obeyed, and I'm not sure to the extent to which it can be obeyed. So some questions: - Is profile platform independence a guiding principle? - To what extent do we work to make it reality? I don't think this is a guiding principle. We should do it when it's reasonable. I think most places it is reasonable to do so. - In the cases where it can't be kept (e.g. download folder path) should we keep a copy for each platform? I don't think so. - Is it worth rewriting today's code that doesn't conform (e.g. extensions and themes which use full paths and platform path separators)? I don't think so, although I do wonder if full paths are necessary, It was painful to remove all of the full paths from mozilla's profile. It was something people wanted because they wanted to be able to just copy their profile from one computer to another. Think of moving a profile from WinXP to Vista where the path to your windows profile changes. I think moving between different versions of the OS is a simpler and more common problem than moving between different OSs. I could come up with convoluted scenarios about why I'd want to move my profile between different OSs, but if it's not a common user request, then it's not worth the effort IMO. -darin even if we're not worried about platform portability (not knowing anything about what these are used for if there are any). 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] Survey: Gathering our core team principles!
I'm trying to get a sense for what people perceive as the core team values of Chromium, and I would like to enlist everyone in helping figuring it out. Basically, I want to put together a small set of core values and a variety of example actions that support (or detract from) those values. A way I've found to do this pretty easily is thinking of a time when I saw someone doing something that I was really impressed by. (The opposite is also true - when you saw someone doing something you really unimpressed by!). If you want to help, try to recall some moments like this, step back and ascertain what the value was that you felt was being supported or detracted. Try and figure out an example of an action that supports that value. Once you've removed any personally identifying remarks or specifics, please send your thoughts to me. Note that I'm looking for individual team member behaviors here specifically, not product features or principles.. With your help, I'd love to put together a doc similar to our product principles that describes how we do (and should be doing) what we do. -Ben --~--~-~--~~~---~--~~ 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: FreeBSD port and ifdefs
I don't know much about the technical details at play here, but a couple of high level notes: - I am sympathetic to concerns around codebase cleanliness. Many people (like Brett) have spent very many months maintaining and improving the hygiene of Chrome code. Sometimes it feels like an uphill battle. Some people (like myself) tend to be more forgiving of temporary clutter when you have an established track record of making these changes and then swiftly sweeping up afterwards. - We have a growing number of ifdefs. It's getting hard to understand when and why each is set. As someone proposing to add more, it'd be much appreciated if you'd put together a doc on our website (and link it up) noting when the common ones are set. If you start such a doc, people can continue to augment/update it with others. So sorry if it seems like you're getting the third degree here, I just think it's a good idea for the team at large to know what's going on so we can all remember to follow up from time to time. -Ben On Wed, Aug 19, 2009 at 11:43 AM, Ben Laurieb...@chromium.org wrote: I've started working on a FreeBSD port. The first patch is here: http://codereview.chromium.org/172032. When looking at the patch, bear in mind a couple of things... 1. Added gyp lines for files like *_ar.pak are compensating for the fact that i18n targets are not currently being handled correctly, and this can break the build, particularly when -j is not used. There are TODOs to make them work properly. They aren't really part of the port, but because I have no build farm for FreeBSD, the problems show up. 2. There are now some directories that are called linux or mac but are used for FreeBSD, too. I'm hesitant to rename these at this point, because it may turn out later that actually FreeBSD-specific versions are needed. Views welcome, of course. Anyway, there's been some debate about how to proceed in terms of ifdefs. The observation is that many places that are currently: #if defined(OS_LINUX) are going to become: #if defined(OS_LINUX) || defined(OS_FREEBSD) and this is ugly. There's a temptation to instead say these are both POSIX, but not MACOSX, for example as here: http://codereview.chromium.org/172032/diff/3003/3013 but this may not always be true (to be honest, I'm not even sure if its true for that case). Does the list have a view on how this should be handled? --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
sgtm. -Ben On Tue, Aug 18, 2009 at 8:32 PM, Evan Stadeest...@chromium.org wrote: on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
Is the page menu really used more than the app menu? If the keys correspond to file/edit equivs, that would suggest wrench should be default. -Ben On Tue, Aug 18, 2009 at 9:20 PM, Mohamed Mansourm...@chromium.org wrote: Alright, I have changed it to use alt+e and alt+f. http://codereview.chromium.org/174044/show Would be nice if a user presses just alt and it would bring up the default main menu. The page menu is used more than the app menu. Would be nice to incorporate that into Chromium. What do you all think? - Mohamed Mansour On Tue, Aug 18, 2009 at 11:32 PM, Ben Goodger (Google) b...@chromium.org wrote: sgtm. -Ben On Tue, Aug 18, 2009 at 8:32 PM, Evan Stadeest...@chromium.org wrote: on linux we do alt+e for page menu and alt+f for wrench menu. The reasoning is that these two menus are reasonable approximations of the Edit and File menus, respectively. -- Evan Stade On Tue, Aug 18, 2009 at 8:14 PM, Ben Goodger (Google)b...@chromium.org wrote: I'm not sure about accesskeys, but my feeling is just pressing Alt should definitely hilight the one of the two menus. -Ben On Tue, Aug 18, 2009 at 8:11 PM, Mohamed Mansourm...@chromium.org wrote: Hi all, Currently, all the functionality in Chrome toolbar has a keyboard shortcut connected to it, except for the App and Page menus. For a keyboard user, currently, you can SHIFT+ALT+T and use the right arrow key to move focus to the menus. This is not very effective and would be better to have a quick way accessing these menus from the keyboard. My suggestion would be: ALT+A for App Menu and ALT+P for Page Menu. I would like some of your suggestions before I implement and commit the change. And I would need feedback from the UI Team. The bug tracker for this would be: http://crbug.com/906 - Mohamed Mansour --~--~-~--~~~---~--~~ 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: Proposal: per-tab open/save dialogs
I like the idea. On Fri, Aug 14, 2009 at 10:03 AM, Viet-Trung Luu viettrung...@gmail.comwrote: Dear all, In the spirit of reducing modality, I propose that, where possible, Open/Save (and other?) dialog boxes should be per-tab (i.e., tab-modal, rather than window-modal). Does anyone have any UI concerns with this? (Nudge, nudge, UI people) As a proof-of-concept, an implementation for Mac is in the CL http://codereview.chromium.org/164547 (be gentle, there are some bugs to be worked out). I'm told that this should be feasible under Linux, but perhaps isn't under Windows. If that's the case, does anyone object to Mac and Linux Chromium having a superior user experience to Windows? (Or, better, does anyone know how to embed a Windows file selection dialog in a window?) - Trung --~--~-~--~~~---~--~~ 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: Tree hygiene
On Fri, Aug 14, 2009 at 12:18 PM, Amanda Walkerama...@chromium.org wrote: I don't think nobody read my mail or nobody cares are accurate. I suspect it's more a matter of well, I didn't touch what broke, so it's not my priority. It would be nice to get back to our older team culture of when the tree breaks, it's everyone's problem until it's fixed, with the sheriff being a backstop. +1. If you committed in the timeframe that it broke, you are on the hook, regardless of whether or not you think you broke it or not. jar had a nice way of putting it: if you want out of the hook, there's an easy option. -Ben --~--~-~--~~~---~--~~ 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: Tree hygiene
I'll add: I really think the reality of the situation today is that sheriffing is a full time job. The days I last did sheriffing I found to do a good job of it I basically couldn't do anything else (e.g. write code) other than watch the tree. So I wanted to point out that when you are sheriff, it's something that you need to focus your attention to. If you're sheriff and are coding and start getting messages from other team members wondering what's up with the tree, you need to evaluate what you're focusing on. THAT SAID, I agree with amanda and jar that people need to take more responsibility about their own checkins. (See my other comment in this thread). -Ben On Fri, Aug 14, 2009 at 11:28 AM, Peter Kastingpkast...@google.com wrote: On Fri, Aug 14, 2009 at 8:00 AM, Marc-Antoine Ruel mar...@chromium.org wrote: - The reliability test has been red for so long that a bad regression hasn't been noticed before it was way too late. - There was multiple webkit linux regressions that haven't been fixed. (+ valgrind) I'm pretty frustrated with this week's tree. Last Thursday and Friday Tim and I kept *everything* green at almost all times. This week there's been constant redness, huge swaths of orange on the WebKit LayoutTest bots, and the tree's been open much of that time. I have done a few things to help but I feel like I can either let the tree be red or be a full-time sheriff. That's not how it should be. I wrote about what both sheriffs and others need to do at all times a week and a half ago. Maybe nobody read my mail because it was too long, or maybe just nobody cares about the tree being in good shape. It's disappointing. Exceptions: a few people like Chase, Tony, Nicolas, Darin, and some others (you know who you are) have indeed stepped up and helped out. Kudos to you guys. 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] Chrome Core Product Principles
I've put together a brief document describing the core principles of the Chrome product and some of the ways we try and achieve them. http://dev.chromium.org/developers/core-principles Thanks to Ian Fette and John Grabowski for helping me fill this out. Feel free to edit if you have anything else to add. -Ben --~--~-~--~~~---~--~~ 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: gears:// and HTML dialogs
I think that rather than having a scheme that opens a dialog, we should make
the HTML dialog open any URL you give it. Then you can just re-use chrome://
which is used by the NTP etc.
-Ben
On Thu, Aug 13, 2009 at 1:18 PM, Tim Steele t...@chromium.org wrote:
Currently most of the code for showing HTML dialogs is hard-coded to the
gears scheme (gears://), used by the 'Create Application Shortcuts'
dialog. If you wanted to add another HTML dialog today, you would need to
add a new scheme for the URL that points to the resource you would like to
have rendered. The sync setup wizard and google account authentication
dialog do this right now using a cloudy:// scheme. This is crappy.
Especially when you dig a bit deeper and notice things like
// Don't inspect *HTML dialogs* (doesn't work anyway).
if (active_entry-url().SchemeIs(chrome::*kGearsScheme*)) {
popping up here and there. I was thinking of adding a general purpose
scheme for triggering HTMLDialogUI, say 'dialog-resource' and add
DataSources for different paths.
Thoughts? Where on earth do the gears:// urls come from, though?
In the grand scheme of things we likely want to rework the html dialog
altogether, to tear it away from TabContents and use a RenderViewHost
directly. The personalization code used to do something like this using a
thing I added called HWNDHtmlView. I think extensions used it for a while,
and there was a bug+todo there to try and extend it's usefulness, but it
went the way of the dodo bird in r16392
http://codf1.jail/viewvc/chrome?view=revrevision=16392.
Is there some other new thing we have that primarily just implements
RenderViewHostDelegate and runs an RVH?
Anyway, I'm trying to avoid doing this more significant refactor right now.
Id first like to consolidate code paths for the application shortcut+sync
html dialogs in my effort to get rid of the CHROME_PERSONALIZATION #define.
Tim
--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?
Seems like all of this can be done on the page. The nice property of the page is that there's room to show a preview of the theme, which in many cases is more memorable than the name. -Ben On Mon, Aug 10, 2009 at 10:02 AM, Aaron Boodmana...@chromium.org wrote: On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogartvand...@google.com wrote: Undoubtedly, there will be hundreds of themes, finding the same one you were using last week before you decided to try a different one will be a daunting task. From a usability perspective, it seems to me that keeping around a small set of recently used themes makes sense. That seems better. I'm a lot more interested in a recently used themes or previously used themes (in the style of the history page) chrome://themes/ page than having the dropdown in the options menu. On the same page, we could combine the theme customization controls (tinting, etc). - a --~--~-~--~~~---~--~~ 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: [chromium-discuss] Re: getting latest stable Chromium
On Sat, Aug 8, 2009 at 9:11 AM, Adam Barthaba...@chromium.org wrote: Yeah, you should feel free to do that. I'm not sure what the advantage of doing that would be. The Chromium builds don't auto-update, so they quickly become out of date. The risk is non-technical people perceiving stable builds as Chromium being a consumer product - it isn't, its an open source project that products like Google Chrome are built on. So yeah, I would be hesitant for us to produce official stable builds that can't update. That shouldn't stop anyone else from doing so. -Ben --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ 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: desktop notifications, preliminary code for review
Yes. Major feature work should have a design doc sent to chromium-dev. Please write one up in the design docs section of dev.chromium.org. -Ben On Wed, Aug 5, 2009 at 5:03 PM, Jeremy Orlowjor...@chromium.org wrote: Is there any reason you're doing this on appspot's code review, not chromium's? I reviewed half the patch at a high level. I think there's plenty of comments to address for now. Once those are addressed, I'm happy to take a deeper dive with the rest if there aren't any more qualified reviewers who'd like to take it on. Even though this has been discussed to death, it might be good to still write up a mini-design doc since that's easier than code to review and I'm sure there's plenty of people who'd like to sanity check the design. (That said, I didn't see any major design flaws while reviewing.) J On Wed, Aug 5, 2009 at 4:52 PM, John Gregg john...@google.com wrote: Sorry, maybe not. It's a big world to keep up to date! Between WHATWG, webkit-dev, and offline it's been discussed at some length at many levels, but not much on this list as I check the archives. But in any case, while the code patch is large as I said I consider it preliminary, and this is why I ask for feedback on the document (and the design expressed in it) as well as the code. Thanks, -John On Wed, Aug 5, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.org wrote: Has a design doc for this feature in general been sent around? This is a fairly large change otherwise. -Ben On Wed, Aug 5, 2009 at 4:13 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 4:00 PM, Evan Martine...@chromium.org wrote: On Wed, Aug 5, 2009 at 3:51 PM, John Greggjohn...@google.com wrote: As I mentioned to some of you offline, I would greatly appreciate a pre-review so I can start to work out the issues and be as ready as possible to check in once the WebKit process finishes. Looks promising, but I see Mac and Windows code and no Linux. ? To clarify, I'd at least like to see the design doc address how and whether this will work on Linux. For example, suppose the APIs available were more broad -- maybe then there is extra information that ought to be plumbed around. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] PSA: Consider upgrading to VS2008.
A few changes are coming soon that mean using VS2008 is desirable: - /MP will be enabled by default for VS2008 debug builds, which will make your builds faster on newer multicore machines without you having to patch any files in your local tree. - We will eventually update the required SDK to the Windows 7 SDK. For this to work in VS2005 an additional hotfix is required. VS2005 will remain our base supported system however these benefits make upgrading to VS2008 desirable (especially if you are getting new hardware that needs everything to be set up on it anyway). -Ben --~--~-~--~~~---~--~~ 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: PSA: Consider upgrading to VS2008.
I would like to. It's just a matter of time and effort... and it's not been a top priority for me to date. Please feel free to gather requirements and develop a plan however. -Ben On Fri, Jul 31, 2009 at 11:11 AM, Mohamed Mansourm0.interact...@gmail.com wrote: Are we planning to remove ATL so we can make Express people happy. We can do a project plan and figure out a timeline on how to remove ATL. It will make many people happy. -- Mohamed Mansour On Fri, Jul 31, 2009 at 2:01 PM, Ben Goodger (Google) b...@chromium.org wrote: A few changes are coming soon that mean using VS2008 is desirable: - /MP will be enabled by default for VS2008 debug builds, which will make your builds faster on newer multicore machines without you having to patch any files in your local tree. - We will eventually update the required SDK to the Windows 7 SDK. For this to work in VS2005 an additional hotfix is required. VS2005 will remain our base supported system however these benefits make upgrading to VS2008 desirable (especially if you are getting new hardware that needs everything to be set up on it anyway). -Ben --~--~-~--~~~---~--~~ 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: How do I filter CC'd code reviews in Gmail?
I would be interested in knowing this too. I think I'm going to create a second email address (e.g. ben-cc) to handle CC'ed reviews. -Ben On Fri, Jul 31, 2009 at 5:18 PM, Brett Wilsonbre...@chromium.org wrote: I added myself to some watchlists and I get a bunch of email about a lot of reviews But this has confused my Gmail filters, which automatic ally label and archive code reviews not addressed directly to me, and all of my CCd code reviews show up in my inbox. Anybody know how to reliably detect the difference between I'm the reviewer and I'm CC'd on a review in a Gmail filter? 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] Re: How do I filter CC'd code reviews in Gmail?
I get a lot of mail since I set up a watchlist filter on browser/. -Ben On Fri, Jul 31, 2009 at 7:28 PM, Mohamed Mansourm0.interact...@gmail.com wrote: I thought all those cc's from code reviews, is about the last couple of people who edited that part of the code in the past. I have been getting a couple of code reviews cc's and the code I was cc'd is what I have touched within a month or so. I could imagine Ben receiving a ton of reviews, he touched almost all browser code base. -- Mohamed Mansour On Fri, Jul 31, 2009 at 8:44 PM, Rahul Kuchhal kuch...@chromium.org wrote: I thought to:user and -cc:user would work in this case? Have you tried using that in Has the words on Filter edit screen? On Fri, Jul 31, 2009 at 5:18 PM, Brett Wilson bre...@chromium.org wrote: I added myself to some watchlists and I get a bunch of email about a lot of reviews But this has confused my Gmail filters, which automatic ally label and archive code reviews not addressed directly to me, and all of my CCd code reviews show up in my inbox. Anybody know how to reliably detect the difference between I'm the reviewer and I'm CC'd on a review in a Gmail filter? 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] Re: CMake for chromium
Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: CMake for chromium
Does the debugger integration work without the project files? -Ben On Mon, Jul 27, 2009 at 6:20 PM, Evan Stadeest...@chromium.org wrote: yea I noticed that KDevelop does intellisense much better than MS does intellisense (all I had to do was set the header includes path to src/, and it was essentially instant to parse the symbols). I'm not sure what the point of a generator for it would be though. What advantage is there to building in KDevelop rather than from terminal? -- Evan Stade On Mon, Jul 27, 2009 at 5:41 PM, Ben Goodger (Google)b...@chromium.org wrote: Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: Proposal for adding ChangeLog files to Chromium
+1 No manual changelogs. -Ben On Tue, Jul 21, 2009 at 9:56 PM, Adam Barthaba...@chromium.org wrote: WebKit uses ChangeLogs for every commit and they are a royal pain, requiring an entire suite of scripts to handle generation, merges, and conflicts. I hope we can find a better solution. Adam On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: When a developer completes a visible or notable change, they'd add an entry to the ChangeLog along with their commit. The entry would have the date, author, a plain English description (suitable for release notes) of the change, along with a reference to any related bugs. Example: 2009-07-21 [lafo...@chromium.org]: Creating a patch to make change tracking easier (Bugs:12345,67890) Immediate Benefits: Assuming that changes were checked in with the code they were mapped to, ChangeLogs would stay up to date even through reverts and branch merges. It would be very easy, given a range of revisions to see what precisely changed in Chromium. Overall, I think this would make it much simpler to view the team's progress and help us improve our overall level of transparency. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Please keep TOOLKIT_VIEWS green!
What brett said. When the infrastructure is available to easily configure an on-demand one, go ahead and do it then. -Ben On Tue, Jul 21, 2009 at 3:56 PM, Brett Wilsonbre...@chromium.org wrote: On Tue, Jul 21, 2009 at 8:42 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Tue, Jul 21, 2009 at 8:31 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Can we have a trybot with that configuration, which would just compile the code? I think it would really save people's time. I never build with TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert and then investigate. If I got a trybot failure, I would know much more before committing. Ben: How likely is this to break? I'm reluctant to add yet another try bot because they do take a lot of resources. There are maybe 200-300 try changes sent every day. That means we need enough resources to build this configuration that many times, and it needs to answer fast enough. I don't think an automatically-running trybot is very critical for this build at the moment. Most of the things that break it are pretty simple (need to add a file to GYP, or maybe a stub for something) so the breakage won't be super complicated. Most errors will be caught by the regular trybots. 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] Please look at your Mstone:3 bugs!
As we begin to tighten the screws on Mstone:3, please review your Mstone:3 bugs: http://code.google.com/p/chromium/issues/list?can=2q=Mstone%3A3+owner%3Ame If you need help with or have concerns about anything on your list, let your neighborhood triage team know and they'll find help. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Please keep TOOLKIT_VIEWS green!
This mostly applies to people working on UI. Sometime tonight or tomorrow we'll be moving the TOOLKIT_VIEWS builder to the front page of the waterfall. Right now it's building just the chrome target, and running no tests, but in time we'll build this out. This is an experimental build distinct from the standard Chromium linux which we will ship but a codepath which we will support as first class for other purposes. So please keep it green! If it goes red, the same rules that apply to any other builder on the front page will apply. To build, export GYP_DEFINES=toolkit_views=1 gclient runhooks --force hammer chrome Thanks, -Ben --~--~-~--~~~---~--~~ 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: Fwd: [webkit-dev] Please welcome GYP to the our dysfunctional build family
Specifically, there were reasons why GYP was created instead of just using CMake. Mark Mentovai should comment. -Ben On Sun, Jul 12, 2009 at 12:30 PM, Jeremy Orlowjor...@chromium.org wrote: People are talking about GYP on the webkit-dev mailing list. It would be nice if we could convince the rest of WebKit to use GYP since it seems we're pretty committed at this point. Unfortunately I don't think there are any GYP experts on that list. At the moment, it'd be nice to know why we created GYP as opposed to using something else like cmake. J -- Forwarded message -- From: Brent Fulgham bfulg...@gmail.com Date: Sun, Jul 12, 2009 at 9:28 AM Subject: Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family To: Jeremy Orlow jor...@chromium.org Cc: Adam Treat tr...@kde.org, Mark Mentovai m...@chromium.org, webkit-...@lists.webkit.org webkit-...@lists.webkit.org Hi, I asked some similar questions on IRC. On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. On Sun, Jul 12, 2009 at 5:38 AM, Adam Treat tr...@kde.org wrote: Gyp sounds remarkably similar to CMake to me. On Jul 12, 2009, at 7:42 AM, Jeremy Orlow jor...@chromium.org wrote: From a quick glance at cmake's website, it seems that it's a build system and not a project file generator. I think it was pretty important to us to generate project files so that you can use the full power of each platform's IDE and toolchain. You might want to take a closer look! ;) CMake generates the desired build environment. So, on Windows it generates visual studio projects, on Mac OS it generates Xcode projects, and on Linux it generates Makefiles. You can override this behavior to get some other target. It can also drive the entire build, but that's not how a lot of people use it. So Cmake seems equivalent to GYP. GYP probably has unique features that make it more desireable than Cmake for one reason or another (perhaps it's easier to add new platform support or something), but at the moment those benefits are not obvious to me. I'm afraid that as far as I can tell, GYP seems like a case of NIH syndrome. -Brent --~--~-~--~~~---~--~~ 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: Frustrating problem with Linux Make build
Sounds like a dependency issue. Can you explicitly build the chrome_strings target and then try building the target you were trying to build again? -Ben On Tue, Jun 30, 2009 at 10:02 AM, Ben Laurieb...@google.com wrote: Following http://code.google.com/p/chromium/wiki/LinuxMakeBuild, I get this error: chrome/browser/debugger/devtools_window.cc:23:38: error: grit/generated_resources.h: No such file or directory and, indeed, if I look: $ ls out/Debug/obj/gen/chrome/grit browser_resources.h renderer_resources.h theme_resources_map.cc common_resources.h theme_resources.h theme_resources_map.h I've poked around in the makefiles some, but I'm mystified. Anyone got any clues? --~--~-~--~~~---~--~~ 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: Windows 7 and the mailto protocol
It's a good idea. We've talked in the past about allowing webapps to specify a manifest which (among other things) includes the list of protocols that they wish to support. When a webapp is installed via Create Application Shortcuts, we could add Chrome to the Windows list on behalf of the webapp. There's also the registerProtocolHandler component of one of the WHAT Web Apps specs. Definitely something we're considering, but no immediate implementation plans. -Ben On Fri, Jun 26, 2009 at 7:07 PM, Robert Daileyrcdai...@gmail.com wrote: This is only somewhat related to Chromium, but I'm asking here because the chromium developers might be the most likely to know the answer. I currently am running Windows 7 Ultimate x64, and I want to associate mailto: links that I click in Chromium (and anywhere, really) to be associated to a new window popping up in Chromium that opens a new email composition in GMail. I know the command for this (it involves -- app), but that doesn't do me any good if I can't put it anywhere. On windows xp, all I had to do was find the MAILTO file type and associate the appropriate command with it and everything worked. But in Windows 7 I do not have a MAILTO protocol. I go to Control Panel Default Programs Set Default Programs Chromium Choose defaults for this program. In this window, I have FTP, HTTP, and HTTPS protocols, but no MAILTO protocol. I'm assuming this is because I have no email client installed on my operating system, and Windows 7 acts dumb and doesn't even make MAILTO available since it does not detect an email client. That's just my speculation, though. Even if MAILTO was available, I don't think it would help because Windows 7 seems to have taken away the ability to associate a command with a protocol, like what was previously possible in Windows XP. Any ideas on this? --~--~-~--~~~---~--~~ 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: Windows 7 and the mailto protocol
I would recommend looking into how the underlying protocol system is implemented (what the format of the command is that Windows dispatches) then writing a script and setting that as the handler. In Chrome you can launch an app frame like so: path\to\chrome.exe --app URL Your script would synthesize the URL based on the data from windows and the URL format of the webmail provider. -Ben On Fri, Jun 26, 2009 at 7:16 PM, Robert Daileyrcdai...@gmail.com wrote: Thanks for getting back with me Ben. Good to know you guys are aware of the problem and looking at portable solutions. In the meantime, however, are you aware of any short-term solutions to this annoying problem? I have to say this is the one thing I hate about Windows 7 so far. I really don't understand how the new protocol system works in Windows 7 yet, nor why MAILTO isn't available. I'm hoping there are some registry keys I can edit somewhere. On Jun 26, 9:11 pm, Ben Goodger (Google) b...@chromium.org wrote: It's a good idea. We've talked in the past about allowing webapps to specify a manifest which (among other things) includes the list of protocols that they wish to support. When a webapp is installed via Create Application Shortcuts, we could add Chrome to the Windows list on behalf of the webapp. There's also the registerProtocolHandler component of one of the WHAT Web Apps specs. Definitely something we're considering, but no immediate implementation plans. -Ben On Fri, Jun 26, 2009 at 7:07 PM, Robert Daileyrcdai...@gmail.com wrote: This is only somewhat related to Chromium, but I'm asking here because the chromium developers might be the most likely to know the answer. I currently am running Windows 7 Ultimate x64, and I want to associate mailto: links that I click in Chromium (and anywhere, really) to be associated to a new window popping up in Chromium that opens a new email composition in GMail. I know the command for this (it involves -- app), but that doesn't do me any good if I can't put it anywhere. On windows xp, all I had to do was find the MAILTO file type and associate the appropriate command with it and everything worked. But in Windows 7 I do not have a MAILTO protocol. I go to Control Panel Default Programs Set Default Programs Chromium Choose defaults for this program. In this window, I have FTP, HTTP, and HTTPS protocols, but no MAILTO protocol. I'm assuming this is because I have no email client installed on my operating system, and Windows 7 acts dumb and doesn't even make MAILTO available since it does not detect an email client. That's just my speculation, though. Even if MAILTO was available, I don't think it would help because Windows 7 seems to have taken away the ability to associate a command with a protocol, like what was previously possible in Windows XP. Any ideas on this? --~--~-~--~~~---~--~~ 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: Important: Porting bits of UI by subclassing is now banned.
Browser is probably fine as is. More users want to access its API than the window's. -Ben On Tue, Jun 23, 2009 at 6:22 AM, Mike Pinkertonpinker...@chromium.org wrote: Is there a plan to rewrite Browser, probably the biggest application of the create the shared object via a factory pattern in our code, or is our focus just moving forward with the correct patterns and leaving existing code as-is? On Tue, Jun 23, 2009 at 1:27 AM, Peter Kastingpkast...@google.com wrote: On Mon, Jun 22, 2009 at 10:22 PM, Ben Goodger (Google) b...@chromium.org wrote: If you are creating UI on another platform and want to reuse common code, please move the common code into a separate object that the platform specific UI owns. Note that this is a specific application of a general good-C++-coding principle: prefer composition to inheritance. Ignore this at your peril, or like me you may end up forced to rewrite big chunks of your code when you later realize that inheritance does not extend to some future change you wanted to make nearly as flexibly as composition would have. (For the curious, this is why I spent the last week rewriting the cross-platform WebKit ICO and BMP decoders I just checked in.) PK -- 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] Important: Porting bits of UI by subclassing is now banned.
Porting bits of UI like dialog boxes by creating a platform-independent base class and subclassing for each platform is now no longer allowed. In C++, inheritance is something to be used carefully. You should create a subclass only when the derived class is a logical specialization. That one class contains cross platform state for a bit of UI and another class contains that platform-specific UI does not mean that the latter is a logical specialization of the former. Overuse of inheritance makes the code harder to follow and understand, and Brett and I in particular have spent a lot of time over the past few months correcting this throughout the Chrome front end. If you are creating UI on another platform and want to reuse common code, please move the common code into a separate object that the platform specific UI owns. This applies to changes you're currently working on, too. e.g., I just redid the Task Manager to fit this pattern. There are two frontends for it currently, TaskManagerView (windows) and TaskManagerGtk (linux). Both have a TaskManager object that they use to populate themselves. It is always more convenient for native code in a particular frontend to directly create its own UI components, rather than having to go through a factory method. If you need any advice on the feature you're working on, please let me know. I'm more than happy to discuss. We should also correct existing instances of the undesirable pattern soon. As I discover them, I'll be emailing the people responsible. If you know of any, please let me know. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] If you break the build, update the buildbot status
When the buildbot detects a critical failure it automatically closes the tree with a message like this: Tree is closed (Automatic: compile on Amiga Debug from 27294: elgo...@chromium.org) It's not clear from this message whether or not the mysterious el goato understands that he's broken the build. Maybe he knows and is fixing it or has scheduled a clobber (which aren't visible on the waterfall console), or maybe he doesn't know and has gone to lunch. Don't be like the mysterious el goato - if you break the build, update the status immediately so people know you're working on it, otherwise you can expect to be pinged relentlessly by people who aren't sure if you know! -Ben --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
No problem. Get well soon! On Sat, Jun 13, 2009 at 3:55 PM, Daniel Cowxdaniel.c...@gmail.com wrote: Sure, I'll take care of this. It'll have to wait a few days though as I broke my index finger and I'm having a bit of a time typing right now. Hope that's cool. Cheers, Daniel On Jun 11, 2:55 pm, Ben Goodger (Google) b...@chromium.org wrote: It's in the class registration function in widget_win.cc -Ben On Thu, Jun 11, 2009 at 2:52 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jun 11, 2009 at 2:48 PM, Ben Goodger (Google) b...@chromium.org wrote: Daniel, do you want to try making this change instead? It'll be pretty obvious to you if it doesn't work. Filed as crbug.com/13926 . We should try and find if we set a value in the WindowWin or WidgetWin (or somewhere) window creation calls and just ditch it. Daniel, feel free to whip up a patch, if it works Ben or I can review. 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: Naming things _views
sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: Naming things _views
Well, class name is supposed to match the file name in Google style. -Ben On Thu, Jun 11, 2009 at 11:22 AM, Erik Kayerik...@chromium.org wrote: So the class name is the same too in this case? (InfoBubble and InfoBubble) Erik On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) b...@chromium.org wrote: sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
It's worth a shot. We should make sure this is one of the WNDCLASSEX fields that when not set causes the window not to be created, obviously! -Ben On Thu, Jun 11, 2009 at 2:40 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jun 11, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.org wrote: Is the default cursor config in the window class even necessary? Isn't the default pointer the arrow anyway? Maybe we could just remove it from WindowWin. As long as Windows doesn't make the mouse cursor disappear by default when doing that, I say let's do it. Want me to file something, or you want to just patch this? 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: How to change the cursor smoothly for a view
It's in the class registration function in widget_win.cc -Ben On Thu, Jun 11, 2009 at 2:52 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jun 11, 2009 at 2:48 PM, Ben Goodger (Google) b...@chromium.org wrote: Daniel, do you want to try making this change instead? It'll be pretty obvious to you if it doesn't work. Filed as crbug.com/13926 . We should try and find if we set a value in the WindowWin or WidgetWin (or somewhere) window creation calls and just ditch it. Daniel, feel free to whip up a patch, if it works Ben or I can review. 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: Any way to compile webkit faster
Most of the losses were regained for me about 2 weeks ago... I am somewhat surprised to hear that you're still getting bad performance. Are you re-running gyp after you apply the /MP patch? -Ben On Wed, Jun 10, 2009 at 7:19 PM, Mohamed Mansourm0.interact...@gmail.com wrote: Hello, Ever since webkit converted to GYP, the time, chromium compilation went from 25 minutes to literally 1 hour and 20+ minutes. (that is by just doing a gclient sync every day) Are there any suggestions on how to make it quicker? (yes I followed the dev documentation) and I have applied the following /MP tags, http://codereview.chromium.org/115603 But I don't understand why my CPU is set to 20-25% active for webkit compilation and chromium uses 100%. It is really getting annoying for any gclient sync, I have to wait roughly 1hr + for me to use the code again. Out of my two to three hours a day working on chromium (about), two thirds of it goes on compiling. I would rather be productive and land couple of patches. Any suggestions is highly appreciated. -- Mohamed Mansour --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
+Sid I think it's worth understanding the API requirements of the new features. I know nothing about Spellchecking though. Maybe Sid can add more? -Ben On Wed, Jun 10, 2009 at 8:14 PM, Nick Baumnickb...@chromium.org wrote: In particular, Ben is referring to the automatic spelling correction that Sid is implementing. Off the top of my head, I can think of a few different ways this could fit in: We can implement Sid's auto-correction on top of native spellcheck, just like today it's implemented on top of Hunspell. OS X will provide similar (though not identical) functionality, and we deem this good enough. We decide native integration is more important than feature parity. As we add more smarts to the spellchecker, we'd need to keep re-evaluating. Thoughts? -Nick On Wed, Jun 10, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.org wrote: For whoever is coordinating this effort, please sync up with Nick Baum on spell checking. He has some additional considerations in mind we should make sure we understand what's possible here. -Ben On Wed, Jun 10, 2009 at 2:36 PM, Mike Pinkertonpinker...@chromium.org wrote: I think we're all on the same page. I pushed Paul to consider having both in his initial design since I forgot about the ability to add additional dictionaries. I'm glad others are in support of that as the way to get additional language support as opposed to trying to shim both implementations together. I agree with Jeremy, let's focus on the OSX spellchecker and ignore hunspell for now. Additionally, let's aim for the OS X spelling dialog if we can do it, regardless of whether or not win/linux can do it. On Wed, Jun 10, 2009 at 11:59 AM, Thomas Van Lententhoma...@chromium.org wrote: On Wed, Jun 10, 2009 at 2:38 PM, p_W paulwoolcoc...@gmail.com wrote: Forgive my (possibly) stupid concern here, but a few months ago there was some talk about this, and about how integrating with the OS's spellchecker was the preferred route as it allowed users to use their dictionary customizations over all their applications. Here is link to the discussion: http://groups.google.com/group/chromium-dev/browse_thread/thread/31832b99aeb953d7/d722d0f183a0b35f?hl=enlnk=gstq=OSX+spell#d722d0f183a0b35f Any thoughts about this? Uh, that's what this thread is about, his project is to switch to using the os one instead. And Jeremy was commenting that he doesn't need to support both, just switch to the native. Or am I reading this differently? TVL On Jun 9, 9:00 pm, Jeremy Moskovich jer...@chromium.org wrote: A couple more things: * I think ultimately we should support the grammar checker, but at first just getting spellchecking to work would be great! * +1 for supporting the Cocoa gui for spellchecking paragraphs, see the 2nd paragraph bellow for more thoughts on this. Matching Linux Windows functionality is a non-goal IMHO, to reiterate we want to behave like a native Cocoa application. WebKit/Safari already support these features so the issue is to get the plumbing working right in our multiprocess model (which may be non-trivial). IMHO the correct route here is to look at how this is done in WebKit and match the behavior there as much as possible, that's what I'm doing with the keyboard events at the moment and it's proving pretty fruitful. It's really exciting you're working on this!! Best regards, Jeremy On Tue, Jun 9, 2009 at 5:50 PM, Jeremy Moskovich jer...@chromium.orgwrote: IMHO there is no need to maintain dual hunspell/OSX spellchecker backends. There are addon OSX spellcheckers for other languages e.g. http://www.mitzpettel.com/software/hspell.php . Writing additional spelling servers is pretty simple so I think the correct approach would be: 1. Getting OSX spelling/grammar checking support working well. 2. If the need arises, wrapping hunspell as an Apple Spelling service and provide it as a separate project users can install. Best regards, Jeremy On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks pwick...@gmail.com wrote: Crap, sorry to post an incomplete version of this post earlier. Accidentally hit send before I finished it. Argh... Anyway, I've been looking at implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be usable, since hunspell supports more languages than OS X does. The public interface of the Spellchecker class is fairly small (mainly 2 methods: SpellCheckWord, AddWord). It seems that mapping these onto the OS X spellchecker shouldn't be too hard. I originally thought
[chromium-dev] Re: How to change the cursor smoothly for a view
I don't know, check WidgetWin. I would be slightly surprised though... we use GetCursorForPoint in a couple of places and haven't had issues... -Ben On Wed, Jun 10, 2009 at 9:39 PM, Daniel Cowxdaniel.c...@gmail.com wrote: Hi Ben, I'm getting the flickering even when I dont have any children in my view. I tried overridding GetViewForPoint for my view class and returning this, but I still get this flicker (with or without the label and bitmap being present). According to MSDN @ http://msdn.microsoft.com/en-us/library/ms648393(VS.85).aspx snip make sure the class cursor for the specified window's class is set to NULL. If the class cursor is not NULL, the system restores the class cursor each time the mouse is moved. /snip Could this be the culprit? On Jun 10, 9:05 pm, Ben Goodger (Google) b...@chromium.org wrote: You want to override GetViewForPoint on the container view and return this, rather than allowing the default implementation of the function to propagate into the base class impl. The reason you're getting flicker is that the default impl of RootView::UpdateCursor calls GetViewForPoint which ends up asking both the label and the text and the container view for the cursor, so its constantly getting reset as you move your mouse over it. -Ben On Wed, Jun 10, 2009 at 8:55 PM, Daniel Cowxdaniel.c...@gmail.com wrote: I've got a composite view that consists of a SkBitmap and views::Label. I'd like to use IDC_HAND (hand cursor) for this composite view so I've overridden view::GetCursorForPoint(...) Though this kinda works, it causes the cursor to jitter/flicker as it calls this function repeatedly based on the current cursor coordinates within the view. How can I implement the desired functionality without this flickering? I've also tried overriding view::OnMouseEntered() and view::OnMouseExited() and manually calling ::SetCursor() to no avail. Can someone please shed some light. Thanks, Daniel --~--~-~--~~~---~--~~ 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: Continuous builds
Awesome. Thanks for making this happen! -Ben On Mon, Jun 8, 2009 at 2:26 PM, Thomas Van Lenten thoma...@chromium.org wrote: The continuous build scripts have been updated to handle all three platforms. If you take the link on the top left of the waterfall pages, you'll go a listing that now includes directories for each platform. Each platform dir then has a LATEST link within it (the LATEST outside of the platform dirs is a Windows one, to make any existing scripts/links using that url still work). I have the scripts currently running to pull the last 30 days worth of builds on Mac and Linux into these directories; and just like Windows, new builds will also appear going forward. TVL Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New views::Menu API
As part of the TOOLKIT_VIEWS work some of the long time deficiencies of the existing views::Menu API have come to a head. I think it may finally be time to revisit this. The system of menu delegates, controllers, and such like are very confusing. We have an API that on one hand provides a model-like interface to a menu item provider, and on the other has methods for adding menu items directly. It's not very coherent. The original reason for this conflation was that some menus in Chrome are generated by data (e.g. bookmarks menus), and some are known beforehand. It's not impossible however to implement most of the fixed menus in terms of a model interface... I looked into doing this late last year, but it turned out there was one other reason for the simple AddItem interface - the Windows system menu. It's not easily possible without lots of gymnastics to populate this menu with a model interface, so the views::Menu code which is designed to optionally wrap a system HMENU retained this awkward interface. After some thought I think it would now be best to split off the Windows system menu handling into something separate in the interests of having an API that doesn't confuse everyone. To start with, I've begun to develop a new API for non-system menus. I've sketched out a straw man API for a menu model and uploaded it here: http://codereview.chromium.org/119237/patch/1001/1002 To make things simpler for fixed menus, an implementation of Menu2Model would be provided called SimpleMenuModel which would offer an interface similar to today's Menu API with functions like AddItemWithLabel, AddSeparator, etc. Once this system works, the views::MenuButton would be re-done to use this and automatically run the associated menu rather than delegating this responsibility to the weird ViewMenuDelegate interface. My plan is to start working on the NativeMenu subclass of Menu2, then work on transitioning the Page and Wrench menus over to it. This would be done leaving the existing Menu class in place so conversion can be done incrementally. Once all users are transitioned, Menu2 would be renamed Menu. ChromeMenu would then be based on this system also, and ultimately renamed ViewsMenu. Let me know if you think I'm missing anything. -Ben --~--~-~--~~~---~--~~ 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: Collapsed view of our waterfall
It'd be cool if it at least had a URL so one could bookmark it. -Ben On Fri, Jun 5, 2009 at 4:27 PM, Eric Romanero...@chromium.org wrote: Sweetness! I didn't know about that either. /me votes for making collapsed view the default since one generally doesn't want to see the descriptions unless something broke. On Fri, Jun 5, 2009 at 4:16 PM, Finnur Thorarinssonfin...@chromium.org wrote: It seems that every week I get around 2-3 people walking past my monitors asking Whoa! How did you get this cool view of the build tree waterfall?! What they are referring to is the merged view of Nicolas' awesome waterfall console view (the one that doesn't contain all the changelist descriptions, just the red/green and orange squares). We probably should make it more discoverable, but until then -- here is how you can get to it: Click on: http://build.chromium.org/buildbot/waterfall/console Scroll down to the bottom. Press the merge link in the lower left corner. But how do I see what failed when something turns red, you ask? Click the red square (and wait a bit) and you'll see (you'll get a popup with the relevant info). :) Enjoy! :) And thanks Nicolas!! -Finnur --~--~-~--~~~---~--~~ 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: Print Settings Mockup
I think we should do a page. This work is not otherwise on our immediate term plan so it may as well get done the right way. I think the page is more of a print preview than a print settings. -Ben On Wed, Jun 3, 2009 at 8:14 PM, Mohamed Mansour m0.interact...@gmail.com wrote: So what is the final verdict? Create a print settings dialog at a start or begin doing the printer settings tab page? -- Mohamed Mansour On Wed, Jun 3, 2009 at 10:56 AM, Sverrir Á. Berg sver...@chromium.org wrote: I think the main challenge is to keep the user flow simple. Traditionally Windows programs have split the configuration of a print to two different dialogs. The Page Setup dialog and the Print dialog. This has always been very confusing for me and I think most users because its not obvious what changing the page size in the page setup dialog is supposed to do when you select a new printer in the Print dialog or move to a new document. If we would go this route we would have a Page setup in the main menu and the print option in the page menu. Confusing at best. My vision for this was that by selecting print the user would go directly to a new tab with the print preview where the configuration would be visually obvious and you could by clicking on the header margins etc change the options, view the visual effects and then there and select the single button on the page that would say print. I've been taking the first steps for this in the work I have been doing to duplicate the DOM so that we have a static copy that can be printed. This is a prerequisite for the print preview (IMHO). As an in-between step we could go for a simple dialog that only displays the default case and has large buttons that you can click to edit page and printer settings (attached). Clicking the page would simply display a list of options (possibly similar to the manage search engines dialog) that would allow you do modify each one and possibly reset them all to default. Crude but efficient. Sverrir On Wed, Jun 3, 2009 at 10:06 AM, Marc-Antoine Ruel mar...@chromium.org wrote: That's an idea of what it'll looks like when embedded in a tab but it's dependent on Sverrir's (and future) work. M-A On Wed, Jun 3, 2009 at 9:56 AM, Mohamed Mansour m0.interact...@gmail.com wrote: Then you could directly see the effect of the settings you were changing on the printed output. So similar what Scott suggestion regarding inline editing? So something like this, or even more real-time ... NOTE: I just drew this at work with mspaint with paint brush and transform ;x http://i42.tinypic.com/2lnxymd.png Ian, page size is useful we could add that as well. I personally don't know how complex we even want it. The chromium UI team is very very picky for every inch being put on screen. We could make a full blown printer settings page and have a Advanced link that expands more options. I don't know. I am just spitting out mocks. Maybe just place the preview as the main one and people click on appropriate places, but that will be confusing to many newbs. -- Mohamed Mansour On Wed, Jun 3, 2009 at 6:00 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Yes it's still the goal but in the mean time it'd be nice to have something to be able to configure the basic settings. On Wed, Jun 3, 2009 at 4:16 AM, Ben Goodger (Google) b...@chromium.org wrote: I don't like these dialog boxes... I thought we had a more ambitious goal once upon a time to do some of this in-tab. Then you could directly see the effect of the settings you were changing on the printed output. -Ben On Tue, Jun 2, 2009 at 6:28 PM, Mohamed Mansour m0.interact...@gmail.com wrote: I removed the options part to give a more visualized idea: http://i41.tinypic.com/syvz7p.png Scott, I agree headers / footers are confusing everywhere, can you elaborate on how we can do inline header/footer representation. I was thinking of the same thing, but I thought it would be confusing for the user to actually click that area, unless it is visually appealing. Ideas? -- Mohamed Mansour On Tue, Jun 2, 2009 at 3:48 PM, Scott Hess sh...@chromium.org wrote: I think the headers and footers are confusing (everywhere). Why not just a single popup for each selection which displays a real-time view of each thing? So it might have items like: Header: Bonsai Kitten http://www.shorty.com/bonsaikitten/; Footer: Page 1 of 2 June 2, 2009 Even better if it were in-line in the box that shows the page (header above, footer below). Also better if it integrates with the margins, since the header and footer presumably take up some space, showing how that space is reclaimed might be valuable. -scott [not a UI designer, I hate almost all print panels, they almost always make what I want hard to do] On Tue, Jun 2, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I like
[chromium-dev] Re: chrome.sln switched to gyp (sort of)
Great! It's exciting to finally see the light at the end of the tunnel. -Ben On Mon, Jun 1, 2009 at 11:53 PM, Bradley Nelson bradnel...@google.com wrote: Hi All, We've just landed a change to switch chrome.sln to be gyp generated. This was accomplished with a bit of a temporary cheat. The now generated chrome.sln continues to refer to the checked-in vcprojs. This change will allow us to switch them over one by one (and will let us roll out most of the major components which are working gyp generated, without being blocked on the few that aren't). This has a few weird (temporary) ramifications: 1. Changes to modules at the chrome module level still need to be made in the checked in vcprojs, however, dependency information now comes from chrome.gyp and installer/installer.gyp. 2. The future layout of chrome.sln is reflected now (even though the projects are in their old locations). Do let me know if there are any problems with the new layout (or if I missed something). The new layout mimics the directory structure, with the one compression that lone vcprojs in a directory with the same name get brought up a level. With any luck we'll be able to land vcprojs gradually throughout the week. We don't plan to bug everyone with announcements on each change, so here's a good rule of thumb: Since you are already updating the gyp files to keep the other platforms working, take note of whether targets you change in chrome.gyp or installer.gyp contain the setting: 'msvs_existing_vcproj'. These will require you to change the checked in vcproj file, others will not. Be sure to let us (sgk and I) know if you notice any regressions during this process. -BradN --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Important: User visible UI changes must be discussed with the UI folk
This has happened a couple of times now. If you're adding any visible user interface, even if it's just a checkbox to the advanced page of Options, you must discuss it with: myself (ben@) Glen Murphy (glen@) Nick Baum (nickbaum@) Brian Rakowski (brian@) first. If you don't, it's highly likely that your change will be reverted :-) -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
