[chromium-dev] Question about how to skip a directory in gclient sync

Hi, I have added '"src/third_party/WebKit/WebKit": None,' to my .gclient file. But when I do 'gclient sync', it still tries to sync up a subdirectory 'mac', under "src/third_party/WebKit/WebKit". $ gclient sync found .git directory; skipping src svn: '/Users/hap497/chromium3/src/thir

[chromium-dev] Re: Question about how to skip a directory in gclient sync

Sorry, I find out answer to my problem. I need to put the directory name same as the ones listed in DEPS. On Fri, Aug 21, 2009 at 10:07 PM, hap 497 wrote: > Hi, > > I have added '"src/third_party/WebKit/WebKit": None,' to my .gclient > file. > But when I do 'gclient sync', it still tries to

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 2:33 PM, Pam Greene wrote: > At least in the batch of tests I examined, the ones that needed > re-baselining weren't tests we'd originally failed and suddenly started > passing. They were new tests that nobody had ever taken a good look at. > > If that matches everyone els

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 6:43 PM, Ojan Vafai wrote: > On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting > wrote: >> >> On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke wrote: >>> >>> This is all good feedback, thanks! To clarify, though: what do you >>> think the cost will be? Perhaps you are assuming t

[chromium-dev] Re: [Linux folks] Splitting First Run into it's own process

What's the motivation? On Fri, Aug 21, 2009 at 5:11 PM, Jeremy Moskovich wrote: > I'm looking at splitting the First Run UI & import machinery into it's own > process on OS X. > I just wanted to sync up with people working on the Linux side of things to > make sure no-one else is working on the s

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting wrote: > On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke wrote: > >> This is all good feedback, thanks! To clarify, though: what do you >> think the cost will be? Perhaps you are assuming things about how I >> would implement this that are different tha

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke wrote: > This is all good feedback, thanks! To clarify, though: what do you > think the cost will be? Perhaps you are assuming things about how I > would implement this that are different than what I had in mind. > Some amount of your time, and some a

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 4:01 PM, Stuart Morgan wrote: > On Fri, Aug 21, 2009 at 3:36 PM, Dean McNamee wrote: >> Note: Firefox on OSX selects all on single click.  So there isn't a >> clear answer on OSX either. > > Firefox has historically tended to favor "do what Firefox does on > other platform

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Aug 21, 4:36 pm, Dean McNamee wrote: > Note: Firefox on OSX selects all on single click.  So there isn't a > clear answer on OSX either. According to Gruber, this is badly broken: http://daringfireball.net/2008/04/firefox_3_safari_3 "LOCATION FIELD — The new Firefox 3 location field, the so

[chromium-dev] Re: [Linux folks] Splitting First Run into it's own process

AFAIK no one is working on it for Linux. On Fri, Aug 21, 2009 at 5:11 PM, Jeremy Moskovich wrote: > I'm looking at splitting the First Run UI & import machinery into it's own > process on OS X. > I just wanted to sync up with people working on the Linux side of things to > make sure no-one else i

[chromium-dev] [Linux folks] Splitting First Run into it's own process

I'm looking at splitting the First Run UI & import machinery into it's own process on OS X. I just wanted to sync up with people working on the Linux side of things to make sure no-one else is working on the same thing in Linux-land? Best regards, Jeremy --~--~-~--~~~-

[chromium-dev] Chromium / Google Summer of Code

With the Google Summer of Code program winding down, I'm curious how our GSoC participants are doing. Can the students and their mentors share their experiences? (Assuming you're all done with evaluations and all that.) --~--~-~--~~~---~--~~ Chromium Developers mai

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock wrote: > > On Aug 21, 10:17 am, Dean McNamee wrote: >> The Omnibox widget code is already very involved, and I don't think it >> is a good idea to add any more complexity or additional modes. > >  ...but, wait a sec, Chromium on OSX seems to do exact

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 4:47 PM, Peter Kasting wrote: > On Fri, Aug 21, 2009 at 2:33 PM, Pam Greene wrote: >> >> I'm not convinced that passing tests we used to fail, or failing tests >> differently, happens often enough to warrant the extra work of producing, >> storing, and using expected-bad r

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 2:33 PM, Pam Greene wrote: > I'm not convinced that passing tests we used to fail, or failing tests > differently, happens often enough to warrant the extra work of producing, > storing, and using expected-bad results. Of course, I may be completely > wrong. What did other

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

As others have said, this thread has been beaten into the ground, and before it we had 15 other threads get beaten into the ground. Various relevant stakeholders such as beng, glen, pinkerton, etc. have been conversed with, and while we are interested in getting more data (see the bug I filed) and

[chromium-dev] Re: Handling layout test expectations for failing tests

At least in the batch of tests I examined, the ones that needed re-baselining weren't tests we'd originally failed and suddenly started passing. They were new tests that nobody had ever taken a good look at. If that matches everyone else's experience, then all we need is an UNTRIAGED annotation in

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 4:12 PM, Dean McNamee wrote: > My argument was just that I know of only 2 frequently used URL bars in > browser.  Safari, and Firefox.  They differ in their behavior.  I > don't know how you have an established standard when you only have a > few reference points, and one o

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 3:36 PM, Dean McNamee wrote: > Note: Firefox on OSX selects all on single click.  So there isn't a > clear answer on OSX either. Firefox has historically tended to favor "do what Firefox does on other platforms" over "follow the platform standard". In other cases, it does

[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

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 2:34 PM, Lei Zhang wrote: > On Fri, Aug 21, 2009 at 2:25 PM, Dean McNamee wrote: >> >> On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: >>> - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's >>> going to look at the host for them. If your target dist

[chromium-dev] Re: Cross-compiling on ARM

2009/8/21 Antoine Labour : > > There's growing interest from several parties in getting Chrome to > cross-compile onto linux/ARM. Let's make sure everyone is on the same > page so that we don't duplicate efforts. > I understand that Joel Stanley, Dean McNamee and Lei Zhang have > already been doin

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: > - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's > going to look at the host for them. If your target distribution > matches your host maybe you're fine, but it may not work at all, so > it'd would be good to extract that a

[chromium-dev] Re: Handling layout test expectations for failing tests

This seems to me like a lot more work for minimal gain. Because you've thought more about it than I have, it makes me think I'm misunderstanding something. Can you explain this more simply, in terms of use cases? Here's what I think you're saying: 1) We don't have notes on why tests are failing

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. On Fri, Aug 21, 2009 at 2:52 PM, Dean McNamee wrote: > On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock wrote: >> >> On Aug 21, 10:17 am, Dean McNamee wrote: >>> The Omnibox widget code is already very

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 2:58 PM, Antoine Labour wrote: > > On Fri, Aug 21, 2009 at 2:45 PM, Erik Corry wrote: >> 2009/8/21 Antoine Labour : >>> >>> There's growing interest from several parties in getting Chrome to >>> cross-compile onto linux/ARM. Let's make sure everyone is on the same >>> page

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 2:45 PM, Erik Corry wrote: > 2009/8/21 Antoine Labour : >> >> There's growing interest from several parties in getting Chrome to >> cross-compile onto linux/ARM. Let's make sure everyone is on the same >> page so that we don't duplicate efforts. >> I understand that Joel St

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 2:46 PM, Dean McNamee wrote: > On Fri, Aug 21, 2009 at 2:34 PM, Lei Zhang wrote: >> On Fri, Aug 21, 2009 at 2:25 PM, Dean McNamee wrote: >>> >>> On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 2:25 PM, Dean McNamee wrote: > > On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: >> - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's >> going to look at the host for them. If your target distribution >> matches your host maybe you're fine, but it m

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Aug 21, 10:17 am, Dean McNamee wrote: > The Omnibox widget code is already very involved, and I don't think it > is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying

[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?

On Fri, Aug 21, 2009 at 11:41 AM, Mohamed Mansour wrote: > Let me summarize what you all have stated: > >- ALT: Highlight App menu button >- ALT-P: Show Page menu >- ALT-A: Show App menu > > or.. > >- ALT: Highlight App menu button >- ALT-P: Highlight Page menu button >- A

[chromium-dev] Re: Cross-compiling on ARM

On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: > > There's growing interest from several parties in getting Chrome to > cross-compile onto linux/ARM. Let's make sure everyone is on the same > page so that we don't duplicate efforts. > I understand that Joel Stanley, Dean McNamee and Lei Z

[chromium-dev] Cross-compiling on ARM

There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a

[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?

On Fri, Aug 21, 2009 at 1:17 PM, Mohamed Mansour wrote: > I really want to name it tools as Peter stated, If anyone has any > objections, please let me know, it will now be: > ALT-T = Tools Menu (previously known as App menu) > ALT-P = Page Menu. > > The only difference within these sets is that

[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?

I really want to name it tools as Peter stated, If anyone has any objections, please let me know, it will now be: ALT-T = Tools Menu (previously known as App menu) ALT-P = Page Menu. The only difference within these sets is that within the first set, it "shows" the menu (the menu popup will be vis

[chromium-dev] Re: Handling layout test expectations for failing tests

On Fri, Aug 21, 2009 at 1:00 PM, Dirk Pranke wrote: > > Hi all, > > As Glenn noted, we made great progress last week in rebaselining the > tests. Unfortunately, we don't have a mechanism to preserve the > knowledge we gained last week as to whether or not tests need to be > rebaselined or not, an

[chromium-dev] Handling layout test expectations for failing tests

Hi all, As Glenn noted, we made great progress last week in rebaselining the tests. Unfortunately, we don't have a mechanism to preserve the knowledge we gained last week as to whether or not tests need to be rebaselined or not, and why not. As a result, it's easy to imagine that we'd need to rep

[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?

Let me summarize what you all have stated: - ALT: Highlight App menu button - ALT-P: Show Page menu - ALT-A: Show App menu or.. - ALT: Highlight App menu button - ALT-P: Highlight Page menu button - ALT-A: Highlight App menu button First set or second set? Thanks! - Mohamed

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 10:25 AM, JT Olds wrote: > Dean wrote: >> Chromium of course is open source, which is a very hidden form of >> configuration. > > It's a shame this is what is left on the table, but hooray for git-svn! http://code.google.com/p/chromium/wiki/UsingGit as well --~--~---

[chromium-dev] Re: [HTML5] Please add HTML5 to your bugs

When I sync issues from WebKit they will get the label HTML5 if they have the keyword HTML5 in their Bugzilla database. However, I will add the label OWP so we can have simple searches on our side. Jon On Mon, Aug 17, 2009 at 1:20 PM, Andrew Scherkus wrote: > That works for me as well. It would

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

On Fri, Aug 21, 2009 at 10:25 AM, JT Olds wrote: > It's a shame this is what is left on the table, but hooray for git-svn! FYI: don't use git-svn. We have a dedicated git mirror that you can clone and fetch from. Much, much faster. http://code.google.com/p/chromium/wiki/UsingGit -- Elliot --~-

[chromium-dev] Re: Overloading operator<< for TimeDelta

Defining operator<< is fine. Other types do this: http://www.google.com/codesearch?as_q=operator<<&btnG=Search+Code&hl=en&as_lang=&as_license_restrict=i&as_license=&as_package=src.chromium.org/svn/trunk/src&as_filename=\.h&as_case=

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

Evan, I don't know if you already got this, sorry if you did, but it looks like it got lost somewhere. I guess I suck at Google Groups. > The problem fundamentally comes down to "matching an existing platform > behavior" versus "try to do something better".  I assert inline > autocomplete and tab

[chromium-dev] Tab-modal dialog/sheet UI design document (long)

Having played with my proof-of-concept for tab-modal file selection (etc.) sheets (CL: ), I think it's time for a draft design document. I'd especially appreciate feedback from the UI people. Here goes Definitions: A tab-specific dialog box or sheet (

[chromium-dev] Re: Lock the Render process in chromium

Joel had some ideas about doing something like thing for power saving. On Thu, Aug 20, 2009 at 12:51 PM, Adam Langley wrote: > > On Thu, Aug 20, 2009 at 9:38 AM, n179911 wrote: >> I don't want the renderer process to die. I just want it 'locked' so >> that i can dump out information of the page

[chromium-dev] Re: WebKit API guidance?

Sure, although I've only just started (have only updated the code to reflect the changes to WorkerObjectProxy/WorkerContextProxy on the WebCore side, and am now cascading the changes down into the WebKit API/browser). http://codereview.chromium.org/173193 Thanks for the help, everyone. I think I s

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

Can we please make it configurable? I hate the click once select all thing. It really drives me nuts. Chromium is so nice otherwise. I don't care how hidden of a configuration parameter it is, just so long as I can change it. On Fri, Aug 21, 2009 at 9:12 AM, Dean McNamee wrote: > > A bug tracker

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

The problem fundamentally comes down to "matching an existing platform behavior" versus "try to do something better". I assert inline autocomplete and tabs on top fall strictly into the latter category, so you can't win an argument by just saying "it matches the platform". Inline autocomplete is

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. Chromium of course is open source, which is a very hidden form of configuration. Good luck, -- dean On Fri, Aug 21, 2009 at 8:57 AM, JT Olds wrote: > Can we ple

[chromium-dev] Re: Use git to checkout chromium source

On Thu, Aug 20, 2009 at 8:42 PM, hap 497 wrote: > But I don't understand how to use git to check out Webkit source which > chromium depends on. > Should I use 'git-svn'? If yes, what is the url for the repository? http://trac.webkit.org/wiki/UsingGitWithWebKit Note that it is your responsibility

[chromium-dev] Re: Chromium Linux 64-bit

On Fri, Aug 21, 2009 at 01:14, Dean McNamee wrote: > > The v8 team did some amazing work this quarter building a working > 64-bit port.  After a handful of changes on the Chromium side, I've > had Chromium Linux building on 64-bit for the last few weeks. This is awesome. You should be knighted.

[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns

A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there

[chromium-dev] Re: Question about Browser IO thread

On Thu, Aug 20, 2009 at 11:27 PM, n179911 wrote: > But when I look at the code , the IOThread class in > browser_process_impl.cc just contains below. It does not has any logic > which dispatches messages. Can you please tell me if it is the right > code? if not , can you please point me to the rig