[chromium-dev] Re: Tree flakyness

[Søren Gjesse]

Regarding PERF TESTS I have committed a change which drops the use of for
WebCore::ConsoleMessage::operator== for now. Lets see how the tests reacts
to this.
/Søren

On Tue, Dec 16, 2008 at 1:58 AM, Nicolas Sylvain wrote:

> Hello,
>   As you all know, our tests are really flaky and are causing the tree to
> be red too often.
>
>   I took a quick look at the test logs and compiled the stats about all the
> flakyness.
>
>
> UI TESTS:
>
> In the last 7 days, 188 ui tests failed. 47 of them failed more than 30
> times.
>
> The biggest offenders:
>
> 122  BrowserTest.JavascriptAlertActivatesTab
>  85  UnloadTest.CrossSiteInfiniteUnloadAsync
>  82  ErrorPageTest.DNSError
>  78  UnloadTest.CrossSiteInfiniteBeforeUnloadAsync
>  52  BrowserTest.TabNavigationAccelerators
>  35  ChromeMainTest.SecondLaunch
>  35  AutomationProxyTest.GetTabCount
>  34  PreferenceServiceTest.PreservedWindowPlacementIsLoaded
>  34  AutomationProxyTest.GetBrowserWindow
>  34  AutomationProxyTest.GetActiveTabIndex
>
> I used to file bugs for all the flaky tests and disable them, but this
> approach did not work.
>
> We currently have 25 ui-tests that are disabled, and I don't think anyone
> is trying to fix them
>
> UNIT TESTS:
>
> This one is getting more stable. Nothing to report, but we have 13 disabled
> tests.
>
> PERF TESTS:
>
> The page cycler tests are often crashing. The offending code is in 
> WebCore::ConsoleMessage::operator==
> which is a new function added a month ago. It's a bit late to start
> reverting this code though (was part of a v8 change), and hard to replicate
> on our dev machines (it never crashed in a debugger).
>
>
> If someone has time, it would be great if you could help debugging, mainly
> if you wrote any of these tests.
>
> Thanks
>
> Nicolas
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Peter Kasting]

On Tue, Dec 16, 2008 at 7:27 PM, Ian Fette  wrote:

> I actually like what Peter was getting at, in the sense that this is "an
> action you can take with the current page". I think we should design for
> that general case and then treat RSS as an instance of that case, rather
> than treating RSS as something special that we get out the door now. Nick's
> other proposal actually seems like a pretty reasonable start here.
>

I think the basic idea of Nick's bookmarklets proposal works well for this,
in the sense of having top-level items and a secondary menu, assuming we
give users sufficient customization power.  I am ambivalent on whether these
need to be in the right side of the address bar.  As long as I can delete or
move (into the chevron menu) the "star" and "rss" icons, then perhaps they
are sufficiently more commonly triggered to justify defaulting them to
top-level positioning.  Data would be nice!

If we think this is the long-term route, it's probably feasible to do more
of a one-off solution for RSS in the short term and simply change the
implementation over time to make the RSS button a "super bookmarklet".

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[Peter Kasting]

On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek  wrote:

> Just a heads-up that I've integrated the script into our Rietveld
> instance.


This is great, thanks very much.  Maybe you should send a standalone email
telling people to look for this link just to be sure we don't miss it?

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Peter Kasting]

On Tue, Dec 16, 2008 at 9:01 PM, Jo  wrote:

> Just some random idea of other possibility.
> This random idea is that when you move your mouse over the star, a
> circle show up with all possibilities for the given web site.


I would like to see us use pie menus more.

That said, I'm not sure this is an application for which they'd make sense.
 The set of possible actions here is unbounded and can change over time,
both of which lead to pie menus being tricky to use or breaking down
entirely.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Jo]

Just some random idea of other possibility.
This random idea is that when you move your mouse over the star, a
circle show up with all possibilities for the given web site. Also, if
you click the star, it will just bookmark as normal. One thing forever
that I will have like to be able to do will have been to replace the
star with a very small summary of which icon are available. Like if we
put ssl icon in this circle, the user will probably want to see the
ssl icon without having to go over the star just as for rss feed
detector.
http://i41.tinypic.com/2en0vuf.png

On Dec 16, 8:33 pm, Nick Baum  wrote:
> Hi all,
>
> I've posted a document that describes how we could better support
> bookmarklets:
>
> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
>
> Let me know if you have any feedback!
> Cheers,
>
> -Nick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Martin]

On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
> Tony set up a temporary pixel builder on his desktop, which Googlers
> can access at go/chrome_linuxpixel ; hopefully that'll only be up
> during the current period where we're trying to get the Linux pixel
> tests matching the non-pixel Linux tests.  Currently we have 1554
> failing.

We're now down to 37 failures and 62 unexpected passes, after some
manual work on truly failing tests as well as some computer-assisted
work on those that just needed fuzzy diffing.

We should reexamine the 62 unexpected passes -- I spot-checked a few
and found at least one that looks suspicious.

Below is a little shell script I use to find test result images
quickly.  I run it like
  image-viewer `./test-results.sh LayoutTests/fast/forms/search-rtl*.png`
and it brings up all the expected results images we have on various platforms.

#!/bin/bash

target=$1
base=webkit/data/layout_tests
chrome_platform=$base/platform
webkit_platform=$base/LayoutTests/platform

for platform in $chrome_platform/* $webkit_platform/*; do
for file in $platform/$target; do
[ -e $file ] && echo $file
done
done

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Linus Upson]

Perhaps the work Charlie is doing could help here.
Linus


On Tue, Dec 16, 2008 at 4:32 PM, Brian Ellis  wrote:

>
> I may be repeating what Peter said to some extent, but unless I'm
> missing something (and I may well be), the browser's security model
> should prevent pages from referring to each other via JavaScript
> across domain boundaries...  so if the "page-modal" dialog also
> "locked" all other tabs in the same tab group (which, as I understand
> it, is defined as those tabs which share a domain) by graying out the
> tab or otherwise indicating that it's unavailable, we could get 95% of
> the way there with 5% of the headaches.  It would be awesome if we
> could perform some kind of analysis to determine that certain tabs are
> independent of the locked page and not gray out those, but that seems
> like a lot of work for not much extra benefit.  The main thing here is
> that user should not have to respond to the alert before they're
> allowed to look at another page on a completely different domain;
> anything that gets us that is, in my opinion, worth the time spent to
> make it happen.
>
> Brian
>
> On Dec 16, 4:00 pm, Peter Kasting  wrote:
> > On Tue, Dec 16, 2008 at 3:56 PM, Darin Fisher 
> wrote:
> > > I don't understand what tab-group-modal UI would be like.
> >
> > That is fair, I don't have a good idea either.  I assumed something like
> dim
> > the page and/or put the alert window (using a ConstrainedWindow) over
> each
> > page in the group, but there are obvious downsides to that.
> >
> > I'd prefer to do something like auto-cancel alerts that originate from
> >
> > > background tabs.  Maybe use an alternate, non-modal UI to present the
> alert
> > > text in case that is interesting.
> >
> > That seems promising.  The first thing I think of for "alternate UI" is
> some
> > sort of taskbar notification toast or something, but there are probably
> > other possibilities too.
> >
> > PK
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tree flakyness

[John Abd-El-Malek]

On Mon, Dec 15, 2008 at 4:58 PM, Nicolas Sylvain  wrote:
> Hello,
>   As you all know, our tests are really flaky and are causing the tree to be
> red too often.
>   I took a quick look at the test logs and compiled the stats about all the
> flakyness.
>
> UI TESTS:
> In the last 7 days, 188 ui tests failed. 47 of them failed more than 30
> times.
> The biggest offenders:
> 122  BrowserTest.JavascriptAlertActivatesTab
>  85  UnloadTest.CrossSiteInfiniteUnloadAsync
>  82  ErrorPageTest.DNSError

I just committed a fix for this a few hours ago.  It might fix other
flakiness as well.

>  78  UnloadTest.CrossSiteInfiniteBeforeUnloadAsync
>  52  BrowserTest.TabNavigationAccelerators
>  35  ChromeMainTest.SecondLaunch
>  35  AutomationProxyTest.GetTabCount
>  34  PreferenceServiceTest.PreservedWindowPlacementIsLoaded
>  34  AutomationProxyTest.GetBrowserWindow
>  34  AutomationProxyTest.GetActiveTabIndex
> I used to file bugs for all the flaky tests and disable them, but this
> approach did not work.
>
> We currently have 25 ui-tests that are disabled, and I don't think anyone is
> trying to fix them
> UNIT TESTS:
> This one is getting more stable. Nothing to report, but we have 13 disabled
> tests.
> PERF TESTS:
> The page cycler tests are often crashing. The offending code is
> in WebCore::ConsoleMessage::operator== which is a new function added a month
> ago. It's a bit late to start reverting this code though (was part of a v8
> change), and hard to replicate on our dev machines (it never crashed in a
> debugger).
>
> If someone has time, it would be great if you could help debugging, mainly
> if you wrote any of these tests.
> Thanks
> Nicolas
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[John Abd-El-Malek]

On Tue, Dec 16, 2008 at 8:26 PM, Mohamed Mansour
 wrote:
> Awesome John, will save a lot of time for those reviewers. So I assume this
> is only for Google code style, webkit patches reviews will always display an
> error since they have a different style.

That's correct.  The script doesn't catch all style violations, but it
should cover enough to save reviewers tedious nitting.
>
> On Tue, Dec 16, 2008 at 11:20 PM, Adam Barth  wrote:
>>
>> Awesome!  Thanks John.  Trailing whitespace be gone!
>>
>> On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek 
>> wrote:
>> >
>> > Just a heads-up that I've integrated the script into our Rietveld
>> > instance.  If you use gcl, it will ping the server at a special url
>> > after a patchset upload so that it can lint the files in the
>> > background.  When you visit the issue page, you'll see  a "x errors"
>> > link under the Lint column which takes you to the lint output. If the
>> > file hasn't been linted yet, you'll see "? errors", in which case
>> > clicking the link will show the errors and save it for future
>> > refreshes of the issue page.
>> >
>> > On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel 
>> > wrote:
>> >>
>> >> I did an internal search and the current state is:
>> >>
>> >> - "Folks have been looking at open sourcing cpplint"
>> >> - In its current incarnation, there is a lot of google-specific checks
>> >> that needs to be factored out simply because they don't apply to
>> >> external and open source projects.
>> >> - Nobody actually took over to do the work.
>> >>
>> >> So I wouldn't expect anything in the near term.
>> >>
>> >> M-A
>> >>
>> >> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>> >>  wrote:
>> >>> Ok, so, back to the original question.  When can those of us external
>> >>> to
>> >>> google expect a code style tool? :-)
>> >>>
>> >>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee 
>> >>> wrote:
>> 
>>  It doesn't need to be a parser, it's just a linter.  You don't really
>>  need to understand anything about the program to give useful warnings
>>  about style.  Our biggest style violation is probably trailing
>>  whitespace, for example.
>> 
>>  On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>>  >
>>  > You wrote a c++ parser in python? cl!  I can't wait to see the
>>  > source.
>>  >
>>  > -Benjamin Meyer
>>  >
>>  > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene 
>>  > wrote:
>>  >>
>>  >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
>>  >>>
>>  >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>>  >>>  wrote:
>>   Sorry to be a pest, but has there been any progress on this?
>>  
>>   Thanks,
>>   Marshall
>>  
>>   On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene 
>>   wrote:
>>  >
>>  > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>>  >  wrote:
>>  > > Hi Mark/Pam,
>>  > >
>>  > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai
>>  > > 
>>  > > wrote:
>>  > >>
>>  > >> Great question.  We've been talking about open-sourcing
>>  > >> something
>>  > >> for
>>  > >> this, but so far, we don't have anything yet.  We do have
>>  > >> something we
>>  > >> use internally, but someone needs to go through it and clean
>>  > >> up a
>>  > >> few
>>  > >> things before releasing it so that it runs well in the wild.
>>  > >>  When it
>>  > >> does materialize, it'll show up on the style guide project
>>  > >> (http://google-styleguide.googlecode.com/).
>>  > >
>>  > > Do you guys have a timeline in mind of when such a tool might
>>  > > become
>>  > > available?  If there are potential code licensing/IP issues,
>>  > > perhaps it
>>  > > could be made available as a web-based service?  For
>>  > > instance,
>>  > > something
>>  > > like the w3c validator but returning the corrections in
>>  > > either
>>  > > human-readable format or a format conducive to automation.
>>  >
>>  > Everybody's generally in support of open-sourcing the tool, and
>>  > I
>>  > don't anticipate any licensing conflicts; it's just a matter of
>>  > finding the time to go through it.  For what it's worth,
>>  > setting it
>>  > up
>>  > as a web-based service wouldn't be any faster.  More than days,
>>  > less
>>  > than months, would be my guess.
>>  >
>>  > - Pam
>>  >>>
>>  >>> A web tool would only delay releasing a real tool.  Just curious
>>  >>> how
>>  >>> is it written?  Using llvm, rpp, or another parser?
>>  >>
>>  >> It's in Python.
>>  >>
>>  >> - Pam
>>  >>
>>  >>>
>>  >>> -Benjamin Meyer
>>  >>>
>> 

[chromium-dev] Re: code style verification/formatting tool

[Mohamed Mansour]

Awesome John, will save a lot of time for those reviewers. So I assume this
is only for Google code style, webkit patches reviews will always display an
error since they have a different style.

On Tue, Dec 16, 2008 at 11:20 PM, Adam Barth  wrote:

>
> Awesome!  Thanks John.  Trailing whitespace be gone!
>
> On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek 
> wrote:
> >
> > Just a heads-up that I've integrated the script into our Rietveld
> > instance.  If you use gcl, it will ping the server at a special url
> > after a patchset upload so that it can lint the files in the
> > background.  When you visit the issue page, you'll see  a "x errors"
> > link under the Lint column which takes you to the lint output. If the
> > file hasn't been linted yet, you'll see "? errors", in which case
> > clicking the link will show the errors and save it for future
> > refreshes of the issue page.
> >
> > On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel 
> wrote:
> >>
> >> I did an internal search and the current state is:
> >>
> >> - "Folks have been looking at open sourcing cpplint"
> >> - In its current incarnation, there is a lot of google-specific checks
> >> that needs to be factored out simply because they don't apply to
> >> external and open source projects.
> >> - Nobody actually took over to do the work.
> >>
> >> So I wouldn't expect anything in the near term.
> >>
> >> M-A
> >>
> >> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
> >>  wrote:
> >>> Ok, so, back to the original question.  When can those of us external
> to
> >>> google expect a code style tool? :-)
> >>>
> >>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee 
> wrote:
> 
>  It doesn't need to be a parser, it's just a linter.  You don't really
>  need to understand anything about the program to give useful warnings
>  about style.  Our biggest style violation is probably trailing
>  whitespace, for example.
> 
>  On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>  >
>  > You wrote a c++ parser in python? cl!  I can't wait to see the
>  > source.
>  >
>  > -Benjamin Meyer
>  >
>  > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene 
> wrote:
>  >>
>  >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
>  >>>
>  >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>  >>>  wrote:
>   Sorry to be a pest, but has there been any progress on this?
>  
>   Thanks,
>   Marshall
>  
>   On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene 
> wrote:
>  >
>  > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>  >  wrote:
>  > > Hi Mark/Pam,
>  > >
>  > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai <
> m...@chromium.org>
>  > > wrote:
>  > >>
>  > >> Great question.  We've been talking about open-sourcing
> something
>  > >> for
>  > >> this, but so far, we don't have anything yet.  We do have
>  > >> something we
>  > >> use internally, but someone needs to go through it and clean
> up a
>  > >> few
>  > >> things before releasing it so that it runs well in the wild.
>  > >>  When it
>  > >> does materialize, it'll show up on the style guide project
>  > >> (http://google-styleguide.googlecode.com/).
>  > >
>  > > Do you guys have a timeline in mind of when such a tool might
>  > > become
>  > > available?  If there are potential code licensing/IP issues,
>  > > perhaps it
>  > > could be made available as a web-based service?  For instance,
>  > > something
>  > > like the w3c validator but returning the corrections in either
>  > > human-readable format or a format conducive to automation.
>  >
>  > Everybody's generally in support of open-sourcing the tool, and
> I
>  > don't anticipate any licensing conflicts; it's just a matter of
>  > finding the time to go through it.  For what it's worth, setting
> it
>  > up
>  > as a web-based service wouldn't be any faster.  More than days,
> less
>  > than months, would be my guess.
>  >
>  > - Pam
>  >>>
>  >>> A web tool would only delay releasing a real tool.  Just curious
> how
>  >>> is it written?  Using llvm, rpp, or another parser?
>  >>
>  >> It's in Python.
>  >>
>  >> - Pam
>  >>
>  >>>
>  >>> -Benjamin Meyer
>  >>>
>  >>> >
>  >>>
>  >>
>  >> >
>  >>
>  >
>  > >
>  >
> 
> 
> >>>
> >>>
> >>> >
> >>>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-de

[chromium-dev] Re: code style verification/formatting tool

[Adam Barth]

Awesome!  Thanks John.  Trailing whitespace be gone!

On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek  wrote:
>
> Just a heads-up that I've integrated the script into our Rietveld
> instance.  If you use gcl, it will ping the server at a special url
> after a patchset upload so that it can lint the files in the
> background.  When you visit the issue page, you'll see  a "x errors"
> link under the Lint column which takes you to the lint output. If the
> file hasn't been linted yet, you'll see "? errors", in which case
> clicking the link will show the errors and save it for future
> refreshes of the issue page.
>
> On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel  wrote:
>>
>> I did an internal search and the current state is:
>>
>> - "Folks have been looking at open sourcing cpplint"
>> - In its current incarnation, there is a lot of google-specific checks
>> that needs to be factored out simply because they don't apply to
>> external and open source projects.
>> - Nobody actually took over to do the work.
>>
>> So I wouldn't expect anything in the near term.
>>
>> M-A
>>
>> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>>  wrote:
>>> Ok, so, back to the original question.  When can those of us external to
>>> google expect a code style tool? :-)
>>>
>>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee  wrote:

 It doesn't need to be a parser, it's just a linter.  You don't really
 need to understand anything about the program to give useful warnings
 about style.  Our biggest style violation is probably trailing
 whitespace, for example.

 On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
 >
 > You wrote a c++ parser in python? cl!  I can't wait to see the
 > source.
 >
 > -Benjamin Meyer
 >
 > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene  wrote:
 >>
 >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
 >>>
 >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
 >>>  wrote:
  Sorry to be a pest, but has there been any progress on this?
 
  Thanks,
  Marshall
 
  On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene  wrote:
 >
 > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
 >  wrote:
 > > Hi Mark/Pam,
 > >
 > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai 
 > > wrote:
 > >>
 > >> Great question.  We've been talking about open-sourcing something
 > >> for
 > >> this, but so far, we don't have anything yet.  We do have
 > >> something we
 > >> use internally, but someone needs to go through it and clean up a
 > >> few
 > >> things before releasing it so that it runs well in the wild.
 > >>  When it
 > >> does materialize, it'll show up on the style guide project
 > >> (http://google-styleguide.googlecode.com/).
 > >
 > > Do you guys have a timeline in mind of when such a tool might
 > > become
 > > available?  If there are potential code licensing/IP issues,
 > > perhaps it
 > > could be made available as a web-based service?  For instance,
 > > something
 > > like the w3c validator but returning the corrections in either
 > > human-readable format or a format conducive to automation.
 >
 > Everybody's generally in support of open-sourcing the tool, and I
 > don't anticipate any licensing conflicts; it's just a matter of
 > finding the time to go through it.  For what it's worth, setting it
 > up
 > as a web-based service wouldn't be any faster.  More than days, less
 > than months, would be my guess.
 >
 > - Pam
 >>>
 >>> A web tool would only delay releasing a real tool.  Just curious how
 >>> is it written?  Using llvm, rpp, or another parser?
 >>
 >> It's in Python.
 >>
 >> - Pam
 >>
 >>>
 >>> -Benjamin Meyer
 >>>
 >>> >
 >>>
 >>
 >> >
 >>
 >
 > >
 >


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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[John Abd-El-Malek]

Just a heads-up that I've integrated the script into our Rietveld
instance.  If you use gcl, it will ping the server at a special url
after a patchset upload so that it can lint the files in the
background.  When you visit the issue page, you'll see  a "x errors"
link under the Lint column which takes you to the lint output. If the
file hasn't been linted yet, you'll see "? errors", in which case
clicking the link will show the errors and save it for future
refreshes of the issue page.

On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel  wrote:
>
> I did an internal search and the current state is:
>
> - "Folks have been looking at open sourcing cpplint"
> - In its current incarnation, there is a lot of google-specific checks
> that needs to be factored out simply because they don't apply to
> external and open source projects.
> - Nobody actually took over to do the work.
>
> So I wouldn't expect anything in the near term.
>
> M-A
>
> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>  wrote:
>> Ok, so, back to the original question.  When can those of us external to
>> google expect a code style tool? :-)
>>
>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee  wrote:
>>>
>>> It doesn't need to be a parser, it's just a linter.  You don't really
>>> need to understand anything about the program to give useful warnings
>>> about style.  Our biggest style violation is probably trailing
>>> whitespace, for example.
>>>
>>> On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>>> >
>>> > You wrote a c++ parser in python? cl!  I can't wait to see the
>>> > source.
>>> >
>>> > -Benjamin Meyer
>>> >
>>> > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene  wrote:
>>> >>
>>> >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
>>> >>>
>>> >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>>> >>>  wrote:
>>>  Sorry to be a pest, but has there been any progress on this?
>>> 
>>>  Thanks,
>>>  Marshall
>>> 
>>>  On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene  wrote:
>>> >
>>> > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>>> >  wrote:
>>> > > Hi Mark/Pam,
>>> > >
>>> > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai 
>>> > > wrote:
>>> > >>
>>> > >> Great question.  We've been talking about open-sourcing something
>>> > >> for
>>> > >> this, but so far, we don't have anything yet.  We do have
>>> > >> something we
>>> > >> use internally, but someone needs to go through it and clean up a
>>> > >> few
>>> > >> things before releasing it so that it runs well in the wild.
>>> > >>  When it
>>> > >> does materialize, it'll show up on the style guide project
>>> > >> (http://google-styleguide.googlecode.com/).
>>> > >
>>> > > Do you guys have a timeline in mind of when such a tool might
>>> > > become
>>> > > available?  If there are potential code licensing/IP issues,
>>> > > perhaps it
>>> > > could be made available as a web-based service?  For instance,
>>> > > something
>>> > > like the w3c validator but returning the corrections in either
>>> > > human-readable format or a format conducive to automation.
>>> >
>>> > Everybody's generally in support of open-sourcing the tool, and I
>>> > don't anticipate any licensing conflicts; it's just a matter of
>>> > finding the time to go through it.  For what it's worth, setting it
>>> > up
>>> > as a web-based service wouldn't be any faster.  More than days, less
>>> > than months, would be my guess.
>>> >
>>> > - Pam
>>> >>>
>>> >>> A web tool would only delay releasing a real tool.  Just curious how
>>> >>> is it written?  Using llvm, rpp, or another parser?
>>> >>
>>> >> It's in Python.
>>> >>
>>> >> - Pam
>>> >>
>>> >>>
>>> >>> -Benjamin Meyer
>>> >>>
>>> >>> >
>>> >>>
>>> >>
>>> >> >
>>> >>
>>> >
>>> > >
>>> >
>>>
>>>
>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Ricardo Vargas]

On Tue, Dec 16, 2008 at 5:47 PM, mpcompl...@chromium.org <
mpcompl...@chromium.org> wrote:

>
> We need to at least support per-profile enabling/disabling of
> extensions.  The extension package may live outside the profile
> directory, but if another profile has Random Extension X enabled, I
> shouldn't be forced to use it as well.


Enabling / disabling of extensions per profile seems like the right thing to
do, but at least to me, installation outside the profile directory would be
more natural. We already have an install path that is per user so most of
the time the person using a profile X is the same one that installed the
browser and any additional extensions, and it would be natural to have them
available on all profiles.


>
> As for the technical details of request interception, every request
> has an URLRequestContext, which has a 1-1 mapping to a Profile object.
>  Perhaps you can use that to either store the info you need or get
> access to the right Profile.  The thing you need to be careful about
> is that Profiles can only be accessed on the UI thread.  I had to deal
> with a similar problem when working out request interception for
> Gears, so maybe I can help you with details.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Mohamed Mansour]

Hmm, I am with Ben on this one.  How about this proposal? Same way Nick has
done his interface, but without including it in the omnibar (cause its not
page related) lets make another button on the toolbar to demonstrate its
user related. If a user would like to show/hide that button, he could do so
similar to the homepage button via options.
How about something like this? http://i40.tinypic.com/29wtoqv.png



On Tue, Dec 16, 2008 at 9:05 PM, Ben Goodger (Google) wrote:

>
> In one hypothetical reality, the RSS icon could be implemented as one
> of these "super bookmarklets" (as could any number of other
> page-state-specific notification icons).
>
> -Ben
>
> On Tue, Dec 16, 2008 at 6:04 PM, Ian Fette  wrote:
> > Is the RSS icon in the screenshot there just a holdover from your doing
> this
> > and the feeds discussion at the same time? I would assume yes, but I
> wanted
> > to make sure that I wasn't missing something.
> >
> > On Tue, Dec 16, 2008 at 5:49 PM, Peter Kasting 
> > wrote:
> >>
> >> On Tue, Dec 16, 2008 at 5:33 PM, Nick Baum 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I've posted a document that describes how we could better support
> >>> bookmarklets:
> >>>
> >>>
> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
> >>>
> >>> Let me know if you have any feedback!
> >>
> >> From a UI/mock perspective, the chevron reminds me of the Windows Quick
> >> Launch bar chevron, and I would expect things to work similarly:
> >> * The chevron only appears when there are more icons hiding
> >> * All items in the dropdown menu get an icon (we give ones without one a
> >> default "page" icon a la tabs with no favicon -- this also sidesteps
> your
> >> comment about only being able to promote bookmarklets with icons)
> >> * I can easily make this area bigger/smaller or manage the icons in it
> and
> >> its dropdown (you allude to this at the end as a possibility, I would
> want
> >> it for sure, probably via drag-and-drop; and I would want to be able to
> move
> >> things from the main bar into the dropdown, not just the other way)
> >> I suggest "Delete" instead of "Remove..." for consistency with Windows
> UI.
> >> It would be nice to support dragging bookmarklets to the bookmarks bar
> >> since that is what people expect in current browsers.  If we want to
> enforce
> >> a single point of UI access for them, we could then animate the
> bookmarklet
> >> "flying" over to the chevron and blink the chevron or something.  We
> should
> >> also think about how the UX will work when importing bookmarklets from
> other
> >> browsers.
> >> A la the search boxes of Fx 2+ and IE 7+, we could subtly highlight the
> >> chevron when on a page that provides some bookmarklets the user doesn't
> >> have, and/or append a section to the bottom of the dropdown like "Add
> "
> >> where  is a bookmarklet the page contains.
> >> PK
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Ian Fette]

It's kind of like bookmarking, except so are a lot of other things (as Peter
mentions, microformats, availability of search engines, etc). Many of these
are things that a subset of people use. I acknowledge that they are vocal on
the support groups and that they are out there, but I don't think RSS users
come anywhere close to a "majority of users" (or for that matter bookmark
users). We have in the past been hesitant to add UI or even preferences for
these minority-use-cases. Do we have any data on how many people actually
click the RSS indicator in FF?
I actually like what Peter was getting at, in the sense that this is "an
action you can take with the current page". I think we should design for
that general case and then treat RSS as an instance of that case, rather
than treating RSS as something special that we get out the door now. Nick's
other proposal actually seems like a pretty reasonable start here.

On Tue, Dec 16, 2008 at 6:14 PM, Ben Goodger (Google) wrote:

>
> RSS is kind of like bookmarking - it's bookmarking a page in your
> reader, instead of in the browser. That's why this intersects with the
> other design doc Nick posted about Bookmarklets that moved the Star.
> We show an RSS icon in the location bar because it's page related.
>
> I don't think there's yet consensus on what the default set of actions
> available in this "page related notification/action" area are, but
> given the feedback we've received from many users, this is one of the
> more popular ones.
>
> -Ben
>
> On Tue, Dec 16, 2008 at 6:11 PM, Ian Fette  wrote:
> > I've always wondered why the RSS feed icon was in the URL bar in Firefox.
> > How many of our users actually know what an RSS feed is, much less use
> it?
> > (I have a feeling that googlers are probably a biased sample). It's
> always
> > seemed like a pretty random thing that someone just decided to throw an
> icon
> > up for. I also grow concerned with too many things crowding the address
> bar
> > - it's really the only "trusted UI" we have anywhere. So, two questions:
> > 1. Does it really make sense to show the "RSS" icon for all users, or is
> > there a way to only have it show up for people who actually use RSS
> feeds?
> > (Not sure how to define those users, maybe we recognize that they have a
> > reader installed / registered / whatever?)
> > 2. Does it really have to be *in* the address bar?
> >
> > On Tue, Dec 16, 2008 at 5:29 PM, Nick Baum 
> wrote:
> >>
> >> Hi all,
> >>
> >> I've posted a pretty simple design document that covers a frequently
> >> requested feature: subscribing to RSS/Atom feeds in Chrome:
> >>
> >>
> >>
> http://sites.google.com/a/chromium.org/dev/user-experience/feed-subscriptions
> >>
> >> There are some mocks missing, but Glen is on vacation, so I figured I'd
> >> send this out anyway.
> >> Let me know if you have any feedback!
> >>
> >> -Nick
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Mohamed Mansour]

Nice design document Nick! I have some remarks I would like to share, which
I will explain later.

@Ian Fette

> I've always wondered why the RSS feed icon was in the URL bar in Firefox.
> How many of our users actually know what an RSS feed is, much less use it?
> (I have a feeling that googlers are probably a biased sample). It's always
> seemed like a pretty random thing that someone just decided to throw an icon
> up for. I also grow concerned with too many things crowding the address bar
> - it's really the only "trusted UI" we have anywhere. So, two questions:
> 1. Does it really make sense to show the "RSS" icon for all users, or is
> there a way to only have it show up for people who actually use RSS feeds?
> (Not sure how to define those users, maybe we recognize that they have a
> reader installed / registered / whatever?)
>
> 2. Does it really have to be *in* the address bar?
>

I believe we should go forward in the web, and feeds are part of it, it is
nice to tell the user about RSS feeds. It is a perfect place on the address
bar since you quickly know if this website has an RSS feed since its page
related. Same thing applies for SSL, etc.

@Ben Goodger
>
> RSS is kind of like bookmarking - it's bookmarking a page in your
> reader, instead of in the browser. That's why this intersects with the
> other design doc Nick posted about Bookmarklets that moved the Star.
> We show an RSS icon in the location bar because it's page related


That is what I think as well, it is bookmarking, but with live feeds. I
personally like the bookmark to be on the left, it is less crowded and fits
perfectly with the design. When we moved the star into the omnibar, it feels
awkward cause my first intentions were that everything that is included
inside the omnibar is page related, a bookmark is not page related (in my
definition) it is user related. I treat feeds as bookmarks, and as I said
before, its just a live bookmark.

I have been constantly reading the Google Chrome user help forums, and many
users are requesting RSS feeds. More than anything, I could even make a
spreadsheet that describes that. Many users would like to view the XML, and
to stay on Chromium theme look, why not make the Feed View feel the same way
as the New Tab feel?

I mocked up something really quickly that demonstrates what would be kinda
cool, http://i44.tinypic.com/4hcav6.png , a lot of things could change.

- m0

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Darin Fisher]

On Tue, Dec 16, 2008 at 5:47 PM, mpcompl...@chromium.org <
mpcompl...@chromium.org> wrote:

>
> We need to at least support per-profile enabling/disabling of
> extensions.  The extension package may live outside the profile
> directory, but if another profile has Random Extension X enabled, I
> shouldn't be forced to use it as well.
>
> As for the technical details of request interception, every request
> has an URLRequestContext, which has a 1-1 mapping to a Profile object.
>  Perhaps you can use that to either store the info you need or get
> access to the right Profile.  The thing you need to be careful about
> is that Profiles can only be accessed on the UI thread.  I had to deal
> with a similar problem when working out request interception for
> Gears, so maybe I can help you with details.



Ditto.  This is something you get for free in Chrome.  URL requests from a
RenderView are contextual.  The only time we have trouble mapping an URL
request to a Profile is when it is a global service issuing the URL request.
 This comes up for things like the metrics service.

The trickiness definitely lies with the fact that the Profile can only be
used on the main thread.  We have a variety of solutions in use to expose
services to the IO thread and other background threads.  We might want to
think about unifying those under some kind of ThreadSafeProfileData class or
perhaps a separate class associated with the Profile that only gets accessed
on the IO thread.

-Darin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Darin Fisher]

per-machine extensions are very important.  that turns out to greatly
simplify the task of distributing an extension via a third-party installer.
-darin



On Tue, Dec 16, 2008 at 5:40 PM, Peter Kasting wrote:

> On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman  wrote:
>
>> Any thoughts, either on advantages or disadvantages to installing
>> extensions per-chrome install, or to assuming that there is only one
>> profile per browser process?
>
>
> From a user perspective, I would very much want per-profile extensions.  I
> have no opinion on whether per-machine extensions would be widely useful (I
> suggest punting that until someone cares) but I would certainly not want
> that to be the only, or the default, choice.
>
> PK
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Peter Kasting]

On Tue, Dec 16, 2008 at 6:11 PM, Ian Fette  wrote:

> 1. Does it really make sense to show the "RSS" icon for all users, or is
> there a way to only have it show up for people who actually use RSS feeds?
> (Not sure how to define those users, maybe we recognize that they have a
> reader installed / registered / whatever?)
>

Borrowing from the Bookmarklets UI, perhaps it could show up in the chevron
(+ the "highlight chevron" idea I posted there), as it's something like "an
action you can take with the current page".

2. Does it really have to be *in* the address bar?
>

If you don't like my suggestion above, another possibility is that we create
some sort of generalized "content area signaling location" where you can
display messages and place actions applicable to the page content.  ("This
page has RSS feeds, microformats, bookmarklets, search engines, Javascript
alerts, notifications".)  But I have no idea what this would look like or
where you'd put it.  Besides "the right edge of the address bar", one could
also imagine "in an expandable area to the right of the address bar", a
shelf below the page a la the download shelf, or a sidebar (gah!).

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Ben Goodger (Google)]

RSS is kind of like bookmarking - it's bookmarking a page in your
reader, instead of in the browser. That's why this intersects with the
other design doc Nick posted about Bookmarklets that moved the Star.
We show an RSS icon in the location bar because it's page related.

I don't think there's yet consensus on what the default set of actions
available in this "page related notification/action" area are, but
given the feedback we've received from many users, this is one of the
more popular ones.

-Ben

On Tue, Dec 16, 2008 at 6:11 PM, Ian Fette  wrote:
> I've always wondered why the RSS feed icon was in the URL bar in Firefox.
> How many of our users actually know what an RSS feed is, much less use it?
> (I have a feeling that googlers are probably a biased sample). It's always
> seemed like a pretty random thing that someone just decided to throw an icon
> up for. I also grow concerned with too many things crowding the address bar
> - it's really the only "trusted UI" we have anywhere. So, two questions:
> 1. Does it really make sense to show the "RSS" icon for all users, or is
> there a way to only have it show up for people who actually use RSS feeds?
> (Not sure how to define those users, maybe we recognize that they have a
> reader installed / registered / whatever?)
> 2. Does it really have to be *in* the address bar?
>
> On Tue, Dec 16, 2008 at 5:29 PM, Nick Baum  wrote:
>>
>> Hi all,
>>
>> I've posted a pretty simple design document that covers a frequently
>> requested feature: subscribing to RSS/Atom feeds in Chrome:
>>
>>
>> http://sites.google.com/a/chromium.org/dev/user-experience/feed-subscriptions
>>
>> There are some mocks missing, but Glen is on vacation, so I figured I'd
>> send this out anyway.
>> Let me know if you have any feedback!
>>
>> -Nick
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for subscribing to feeds

[Ian Fette]

I've always wondered why the RSS feed icon was in the URL bar in Firefox.
How many of our users actually know what an RSS feed is, much less use it?
(I have a feeling that googlers are probably a biased sample). It's always
seemed like a pretty random thing that someone just decided to throw an icon
up for. I also grow concerned with too many things crowding the address bar
- it's really the only "trusted UI" we have anywhere. So, two questions:
1. Does it really make sense to show the "RSS" icon for all users, or is
there a way to only have it show up for people who actually use RSS feeds?
(Not sure how to define those users, maybe we recognize that they have a
reader installed / registered / whatever?)

2. Does it really have to be *in* the address bar?


On Tue, Dec 16, 2008 at 5:29 PM, Nick Baum  wrote:

> Hi all,
>
> I've posted a pretty simple design document that covers a frequently
> requested feature: subscribing to RSS/Atom feeds in Chrome:
>
>
> http://sites.google.com/a/chromium.org/dev/user-experience/feed-subscriptions
>
> There are some mocks missing, but Glen is on vacation, so I figured I'd
> send this out anyway.
> Let me know if you have any feedback!
>
> -Nick
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Ben Goodger (Google)]

In one hypothetical reality, the RSS icon could be implemented as one
of these "super bookmarklets" (as could any number of other
page-state-specific notification icons).

-Ben

On Tue, Dec 16, 2008 at 6:04 PM, Ian Fette  wrote:
> Is the RSS icon in the screenshot there just a holdover from your doing this
> and the feeds discussion at the same time? I would assume yes, but I wanted
> to make sure that I wasn't missing something.
>
> On Tue, Dec 16, 2008 at 5:49 PM, Peter Kasting 
> wrote:
>>
>> On Tue, Dec 16, 2008 at 5:33 PM, Nick Baum  wrote:
>>>
>>> Hi all,
>>>
>>> I've posted a document that describes how we could better support
>>> bookmarklets:
>>>
>>> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
>>>
>>> Let me know if you have any feedback!
>>
>> From a UI/mock perspective, the chevron reminds me of the Windows Quick
>> Launch bar chevron, and I would expect things to work similarly:
>> * The chevron only appears when there are more icons hiding
>> * All items in the dropdown menu get an icon (we give ones without one a
>> default "page" icon a la tabs with no favicon -- this also sidesteps your
>> comment about only being able to promote bookmarklets with icons)
>> * I can easily make this area bigger/smaller or manage the icons in it and
>> its dropdown (you allude to this at the end as a possibility, I would want
>> it for sure, probably via drag-and-drop; and I would want to be able to move
>> things from the main bar into the dropdown, not just the other way)
>> I suggest "Delete" instead of "Remove..." for consistency with Windows UI.
>> It would be nice to support dragging bookmarklets to the bookmarks bar
>> since that is what people expect in current browsers.  If we want to enforce
>> a single point of UI access for them, we could then animate the bookmarklet
>> "flying" over to the chevron and blink the chevron or something.  We should
>> also think about how the UX will work when importing bookmarklets from other
>> browsers.
>> A la the search boxes of Fx 2+ and IE 7+, we could subtly highlight the
>> chevron when on a page that provides some bookmarklets the user doesn't
>> have, and/or append a section to the bottom of the dropdown like "Add "
>> where  is a bookmarklet the page contains.
>> PK
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Ian Fette]

Is the RSS icon in the screenshot there just a holdover from your doing this
and the feeds discussion at the same time? I would assume yes, but I wanted
to make sure that I wasn't missing something.

On Tue, Dec 16, 2008 at 5:49 PM, Peter Kasting wrote:

> On Tue, Dec 16, 2008 at 5:33 PM, Nick Baum  wrote:
>
>> Hi all,
>>
>> I've posted a document that describes how we could better support
>> bookmarklets:
>>
>> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
>>
>> Let me know if you have any feedback!
>
>
> From a UI/mock perspective, the chevron reminds me of the Windows Quick
> Launch bar chevron, and I would expect things to work similarly:
> * The chevron only appears when there are more icons hiding
> * All items in the dropdown menu get an icon (we give ones without one a
> default "page" icon a la tabs with no favicon -- this also sidesteps your
> comment about only being able to promote bookmarklets with icons)
> * I can easily make this area bigger/smaller or manage the icons in it and
> its dropdown (you allude to this at the end as a possibility, I would want
> it for sure, probably via drag-and-drop; and I would want to be able to move
> things from the main bar into the dropdown, not just the other way)
>
> I suggest "Delete" instead of "Remove..." for consistency with Windows UI.
>
> It would be nice to support dragging bookmarklets to the bookmarks bar
> since that is what people expect in current browsers.  If we want to enforce
> a single point of UI access for them, we could then animate the bookmarklet
> "flying" over to the chevron and blink the chevron or something.  We should
> also think about how the UX will work when importing bookmarklets from other
> browsers.
>
> A la the search boxes of Fx 2+ and IE 7+, we could subtly highlight the
> chevron when on a page that provides some bookmarklets the user doesn't
> have, and/or append a section to the bottom of the dropdown like "Add "
> where  is a bookmarklet the page contains.
>
> PK
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Peter Kasting]

On Tue, Dec 16, 2008 at 5:50 PM, Mike Belshe  wrote:

> My thought is that extensions should not apply in the incognito mode.


I don't know.  From my perspective as a user, "incognito" is more like a
flag I temporarily set on my current window/profile, rather than a different
profile.  (Which is also fairly true implementation-wise.)  In that sense I
wouldn't expect extensions to be disabled unless they wrote state to disk or
something.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Mike Belshe]

My thought is that extensions should not apply in the incognito mode.

Another option is to have scoping of extensions; globally or profile
based.  But that sounds complicated.

Maybe for now just implement profile-scoped extensions, and if this is
obviously insufficient then you can add global scopes?

Mike


On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman  wrote:
>
> I've been struggling with how extensions and profiles should relate.
> My initial thinking was that we should support installing extensions
> per-profile and per-machine (the latter for distribution deals
> mostly). Currently, our extension manager (ExtensionsService) object
> is owned by the profile and looks for extensions inside the profile
> directory. As for incognito mode, my assumption was that it was more
> correct to have extensions keep working in incognito mode than to have
> them stop working (there are tradeoffs both ways though).
>
> My immediate issue is that I'm trying to implement support for the
> extension:// protocol, which looks like this:
> extension:///path/inside/extension. In order to implement
> this, I need to be able to track a request back to the profile it came
> from. But at the point my custom protocol handler gets invoked,
> profile information is long since toast.
>
> Stepping back, I could make some simplifying assumptions:
>
> * We could start by implementing per-chrome-install extensions only.
> In that case a static protocol handler is fine. I'd also have to
> change the extension service to be a singleton and instead look for
> extension inside the app directory, similar to how npapi plugins work.
>
> * I could keep extensions installed per-profile for now, but assume
> that there is really only one profile per-browser process. In this
> world, I'd still make ExtensionsService be a singleton, but I'd
> initialize at browser startup with the path to the profile that was
> picked at startup.
>
> Any thoughts, either on advantages or disadvantages to installing
> extensions per-chrome install, or to assuming that there is only one
> profile per browser process?
>
>
> Thanks,
>
> - a
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Peter Kasting]

On Tue, Dec 16, 2008 at 5:33 PM, Nick Baum  wrote:

> Hi all,
>
> I've posted a document that describes how we could better support
> bookmarklets:
>
> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
>
> Let me know if you have any feedback!


>From a UI/mock perspective, the chevron reminds me of the Windows Quick
Launch bar chevron, and I would expect things to work similarly:
* The chevron only appears when there are more icons hiding
* All items in the dropdown menu get an icon (we give ones without one a
default "page" icon a la tabs with no favicon -- this also sidesteps your
comment about only being able to promote bookmarklets with icons)
* I can easily make this area bigger/smaller or manage the icons in it and
its dropdown (you allude to this at the end as a possibility, I would want
it for sure, probably via drag-and-drop; and I would want to be able to move
things from the main bar into the dropdown, not just the other way)

I suggest "Delete" instead of "Remove..." for consistency with Windows UI.

It would be nice to support dragging bookmarklets to the bookmarks bar since
that is what people expect in current browsers.  If we want to enforce a
single point of UI access for them, we could then animate the bookmarklet
"flying" over to the chevron and blink the chevron or something.  We should
also think about how the UX will work when importing bookmarklets from other
browsers.

A la the search boxes of Fx 2+ and IE 7+, we could subtly highlight the
chevron when on a page that provides some bookmarklets the user doesn't
have, and/or append a section to the bottom of the dropdown like "Add "
where  is a bookmarklet the page contains.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[mpcompl...@chromium.org]

We need to at least support per-profile enabling/disabling of
extensions.  The extension package may live outside the profile
directory, but if another profile has Random Extension X enabled, I
shouldn't be forced to use it as well.

As for the technical details of request interception, every request
has an URLRequestContext, which has a 1-1 mapping to a Profile object.
 Perhaps you can use that to either store the info you need or get
access to the right Profile.  The thing you need to be careful about
is that Profiles can only be accessed on the UI thread.  I had to deal
with a similar problem when working out request interception for
Gears, so maybe I can help you with details.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Peter Kasting]

On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman  wrote:

> Any thoughts, either on advantages or disadvantages to installing
> extensions per-chrome install, or to assuming that there is only one
> profile per browser process?


>From a user perspective, I would very much want per-profile extensions.  I
have no opinion on whether per-machine extensions would be widely useful (I
suggest punting that until someone cares) but I would certainly not want
that to be the only, or the default, choice.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Extensions and profiles

[Aaron Boodman]

I've been struggling with how extensions and profiles should relate.
My initial thinking was that we should support installing extensions
per-profile and per-machine (the latter for distribution deals
mostly). Currently, our extension manager (ExtensionsService) object
is owned by the profile and looks for extensions inside the profile
directory. As for incognito mode, my assumption was that it was more
correct to have extensions keep working in incognito mode than to have
them stop working (there are tradeoffs both ways though).

My immediate issue is that I'm trying to implement support for the
extension:// protocol, which looks like this:
extension:///path/inside/extension. In order to implement
this, I need to be able to track a request back to the profile it came
from. But at the point my custom protocol handler gets invoked,
profile information is long since toast.

Stepping back, I could make some simplifying assumptions:

* We could start by implementing per-chrome-install extensions only.
In that case a static protocol handler is fine. I'd also have to
change the extension service to be a singleton and instead look for
extension inside the app directory, similar to how npapi plugins work.

* I could keep extensions installed per-profile for now, but assume
that there is really only one profile per-browser process. In this
world, I'd still make ExtensionsService be a singleton, but I'd
initialize at browser startup with the path to the profile that was
picked at startup.

Any thoughts, either on advantages or disadvantages to installing
extensions per-chrome install, or to assuming that there is only one
profile per browser process?


Thanks,

- a

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Design for better supporting bookmarklets

[Nick Baum]

Hi all,

I've posted a document that describes how we could better support
bookmarklets:

http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets

Let me know if you have any feedback!
Cheers,

-Nick

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Design for subscribing to feeds

[Nick Baum]

Hi all,

I've posted a pretty simple design document that covers a frequently
requested feature: subscribing to RSS/Atom feeds in Chrome:

http://sites.google.com/a/chromium.org/dev/user-experience/feed-subscriptions

There are some mocks missing, but Glen is on vacation, so I figured I'd send
this out anyway.
Let me know if you have any feedback!

-Nick

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Brian Ellis]

I may be repeating what Peter said to some extent, but unless I'm
missing something (and I may well be), the browser's security model
should prevent pages from referring to each other via JavaScript
across domain boundaries...  so if the "page-modal" dialog also
"locked" all other tabs in the same tab group (which, as I understand
it, is defined as those tabs which share a domain) by graying out the
tab or otherwise indicating that it's unavailable, we could get 95% of
the way there with 5% of the headaches.  It would be awesome if we
could perform some kind of analysis to determine that certain tabs are
independent of the locked page and not gray out those, but that seems
like a lot of work for not much extra benefit.  The main thing here is
that user should not have to respond to the alert before they're
allowed to look at another page on a completely different domain;
anything that gets us that is, in my opinion, worth the time spent to
make it happen.

Brian

On Dec 16, 4:00 pm, Peter Kasting  wrote:
> On Tue, Dec 16, 2008 at 3:56 PM, Darin Fisher  wrote:
> > I don't understand what tab-group-modal UI would be like.
>
> That is fair, I don't have a good idea either.  I assumed something like dim
> the page and/or put the alert window (using a ConstrainedWindow) over each
> page in the group, but there are obvious downsides to that.
>
> I'd prefer to do something like auto-cancel alerts that originate from
>
> > background tabs.  Maybe use an alternate, non-modal UI to present the alert
> > text in case that is interesting.
>
> That seems promising.  The first thing I think of for "alternate UI" is some
> sort of taskbar notification toast or something, but there are probably
> other possibilities too.
>
> PK
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Peter Kasting]

On Tue, Dec 16, 2008 at 3:56 PM, Darin Fisher  wrote:

> I don't understand what tab-group-modal UI would be like.


That is fair, I don't have a good idea either.  I assumed something like dim
the page and/or put the alert window (using a ConstrainedWindow) over each
page in the group, but there are obvious downsides to that.

I'd prefer to do something like auto-cancel alerts that originate from
> background tabs.  Maybe use an alternate, non-modal UI to present the alert
> text in case that is interesting.
>

That seems promising.  The first thing I think of for "alternate UI" is some
sort of taskbar notification toast or something, but there are probably
other possibilities too.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Darin Fisher]

I don't understand what tab-group-modal UI would be like.
I'd prefer to do something like auto-cancel alerts that originate from
background tabs.  Maybe use an alternate, non-modal UI to present the alert
text in case that is interesting.  We could even flash the background tab to
indicate that something happened.

Trying to coerce alerts to be page-modal is just going to hurt a lot and be
way more work than the feature could possibly be worth in my opinion.

-Darin



On Tue, Dec 16, 2008 at 3:36 PM, Peter Kasting  wrote:

> On Tue, Dec 16, 2008 at 3:30 PM, Darin Fisher  wrote:
>
>> The problem is that no matter how you cut it, you end up violating the
>> run-to-completion (non-reentrant) constraint of javascript.
>> This problem is further complicated by the fact that Flash can also cause
>> script to execute in the web page, and all web pages use the same Flash
>> process (same Flash thread even).
>>
>
> FWIW, we could do "better" here, though probably not perfect, with the
> following set of changes:
> * Move from one plugin process to one plugin process per tab group, so that
> Flash etc. don't introduce additional tab dependencies beyond what JS
> introduces.
> * Be as aggressive as possible about breaking script dependencies between
> tabs.  Perhaps we can somehow use the garbage collector to realize a page
> doesn't have a reference to the window it just opened and thus can't script
> it, or something.  The idea is to make tabs be in distinct processes as
> frequently as possible.  (Perhaps there is even more we can do if we're
> willing to break some small part of the web; I'm just speculating wildly.)
> * Make alerts tab-group-modal instead of app-modal, and hope that the
> typical number of tabs in a tab group is 1.
>
> PK
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Peter Kasting]

On Tue, Dec 16, 2008 at 3:30 PM, Darin Fisher  wrote:

> The problem is that no matter how you cut it, you end up violating the
> run-to-completion (non-reentrant) constraint of javascript.
> This problem is further complicated by the fact that Flash can also cause
> script to execute in the web page, and all web pages use the same Flash
> process (same Flash thread even).
>

FWIW, we could do "better" here, though probably not perfect, with the
following set of changes:
* Move from one plugin process to one plugin process per tab group, so that
Flash etc. don't introduce additional tab dependencies beyond what JS
introduces.
* Be as aggressive as possible about breaking script dependencies between
tabs.  Perhaps we can somehow use the garbage collector to realize a page
doesn't have a reference to the window it just opened and thus can't script
it, or something.  The idea is to make tabs be in distinct processes as
frequently as possible.  (Perhaps there is even more we can do if we're
willing to break some small part of the web; I'm just speculating wildly.)
* Make alerts tab-group-modal instead of app-modal, and hope that the
typical number of tabs in a tab group is 1.

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Modal dialogs in Chrome

[Darin Fisher]

This sounds nice and simple on the surface I spent a lot of energy
trying to figure out how to make it fly to no avail.
Short version:

The problem is that no matter how you cut it, you end up violating the
run-to-completion (non-reentrant) constraint of javascript.  It is not
enough to prevent the script on the page that calls alert from executing
javascript again.  You also have to worry about other pages that may be able
to script the page that is currently calling alert.  So, you could have
multiple tabs that are all able to script one another.  In fact, it could be
tab A calling alert on the window object of tab B.  Those tabs could also be
in different browser windows.  If you think through those kinds of
scenarios, you can imagine how this kind page-modal UI breaks down.
This problem is further complicated by the fact that Flash can also cause
script to execute in the web page, and all web pages use the same Flash
process (same Flash thread even).  The Flash process needs to also see the
same kind of run-to-completion world.  So, then all tabs running Flash (not
just the ones in the same domain) are linked together in this way.

Hence, the need for app-modal alerts.

-Darin


On Tue, Dec 16, 2008 at 3:13 PM, Brian Ellis  wrote:

>
> Hi folks,
>
> I wanted to share an idea that I think could substantially improve the
> user experience of the various modal dialogs used in Chrome.  You can
> see it here:
>
> http://docs.google.com/Doc?id=dj6xpc2_0hspk5vcw
>
> For the tl;dr crowd, basically the idea is to introduce the concept of
> a page-modal dialog.  When a page-modal dialog in onscreen, the user
> can't interact with the page that showed the dialog (for example
> scrolling, clicking links, right-clicking on the page, etc.) but can
> interact normally with everything else in the window -- he or she can
> close the tab, switch to another tab, close the window, show the
> Options dialog, etc.  This makes the dialog modal from the point of
> view of a script on the page (preserving the existing semantics of
> functions like alert()), but avoids forcing the user to interact with
> the dialog before they can do anything else in the browser, thwarting
> DoS attacks and removing an attractive vehicle for "dialog spammers"
> to claim the user's attention.  See the doc for more details and
> mockups.
>
> Brian
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Trunk build's biggest annoyances?

[Mark Larson (Google)]

On Tue, Dec 16, 2008 at 07:20, Marshall Greenblatt
wrote:

> What is chromium's usage plan for /trunk?  It seems that recent beta and
> release builds of chrome are coming off of /branches/chrome_official_branch
> -- is there a process in place to synchronize
> /branches/chrome_official_branch with /trunk at some set interval?  Or will
> they be kept separate with changes moving between them only as needed?


We want to release to the developer preview channel (Dev) from trunk weekly,
with periodic exceptions for stabilizing things for a Beta channel release.
Our goal is to keep the lifespan of a release branch unde 3 weeks.

To get there, we need to get trunk releasable again (and keep it that way).

--Mark


>
>
> Thanks,
> Marshall
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Modal dialogs in Chrome

[Brian Ellis]

Hi folks,

I wanted to share an idea that I think could substantially improve the
user experience of the various modal dialogs used in Chrome.  You can
see it here:

http://docs.google.com/Doc?id=dj6xpc2_0hspk5vcw

For the tl;dr crowd, basically the idea is to introduce the concept of
a page-modal dialog.  When a page-modal dialog in onscreen, the user
can't interact with the page that showed the dialog (for example
scrolling, clicking links, right-clicking on the page, etc.) but can
interact normally with everything else in the window -- he or she can
close the tab, switch to another tab, close the window, show the
Options dialog, etc.  This makes the dialog modal from the point of
view of a script on the page (preserving the existing semantics of
functions like alert()), but avoids forcing the user to interact with
the dialog before they can do anything else in the browser, thwarting
DoS attacks and removing an attractive vehicle for "dialog spammers"
to claim the user's attention.  See the doc for more details and
mockups.

Brian
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Evan Martin]

On Tue, Dec 16, 2008 at 2:58 PM, Darin Fisher  wrote:
>> This doesn't work well for people in other time zones. I guess we can just
>> keep with the webkit process. I wonder if there's a way we can be more
>> reliable about getting patches committed within a work-day of them getting
>> approved (e.g. have a committer look over the list of approved patches every
>> day to commit things).
>
> Good point.  In that case, sending mail to chromium-dev should suffice,
> right?  (That is, if the webkit process isn't working.)

For Linux patches, we had found some success with a manual list of
pending patches:
  http://code.google.com/p/chromium/wiki/LinuxPatchQueue
It's basically empty now though.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Ojan Vafai]

On Tue, Dec 16, 2008 at 2:58 PM, Darin Fisher  wrote:

> On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai  wrote:
>
>> On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher  wrote:
>>
>>> http://nightly.webkit.org/start has a link to the list of approved
>>> patchesthat
>>>  simply need to be landed.  In the past, I have used that link to locate
>>> patches to commit that were created by Chromium folks who lack commit
>>> access.
>>>
>>> I'm not a huge fan of process since it requires learning about process.
>>>  Does it not work to ask in #chromium or #webkit for someone to help land a
>>> patch?  (Just ask in the IRC channel is an easy process to remember.)
>>>
>>
>> This doesn't work well for people in other time zones. I guess we can just
>> keep with the webkit process. I wonder if there's a way we can be more
>> reliable about getting patches committed within a work-day of them getting
>> approved (e.g. have a committer look over the list of approved patches every
>> day to commit things).
>>
>
> Good point.  In that case, sending mail to chromium-dev should suffice,
> right?  (That is, if the webkit process isn't working.)
>

I buy that.

Ojan

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Martin]

On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
> Adam wrote a nifty fuzzy image differ that can highlight "meaningful"
> diffs between images.  It's in third_party/fuzzymatch and maybe he can
> comment on how he uses it.

With some recent changes, it should be sufficient to:
1) run scons in third_party/fuzzymatch (look at the comments in the
file if you're missing dependencies)
2) run_webkit_tests.sh --fuzzy-pixel-tests

You can also run it manually (see its --help output) to have it
highlight where images differ.

Adam plans to automatically rebaseline all tests where we're passing
render trees and the fuzzy differ, so you don't need to worry about
manual rebaselining if the fuzzy differ is ok with it.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Darin Fisher]

On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai  wrote:

> On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher  wrote:
>
>> http://nightly.webkit.org/start has a link to the list of approved
>> patchesthat
>>  simply need to be landed.  In the past, I have used that link to locate
>> patches to commit that were created by Chromium folks who lack commit
>> access.
>>
>> I'm not a huge fan of process since it requires learning about process.
>>  Does it not work to ask in #chromium or #webkit for someone to help land a
>> patch?  (Just ask in the IRC channel is an easy process to remember.)
>>
>
> This doesn't work well for people in other time zones. I guess we can just
> keep with the webkit process. I wonder if there's a way we can be more
> reliable about getting patches committed within a work-day of them getting
> approved (e.g. have a committer look over the list of approved patches every
> day to commit things).
>

Good point.  In that case, sending mail to chromium-dev should suffice,
right?  (That is, if the webkit process isn't working.)

-Darin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Eric Seidel]

The quickest way to get your patches approved, is to submit enough
that we can offer you commit access. :)

-eric

On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai  wrote:
> On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher  wrote:
>>
>> http://nightly.webkit.org/start has a link to the list of approved patches
>> that simply need to be landed.  In the past, I have used that link to locate
>> patches to commit that were created by Chromium folks who lack commit
>> access.
>>
>> I'm not a huge fan of process since it requires learning about process.
>>  Does it not work to ask in #chromium or #webkit for someone to help land a
>> patch?  (Just ask in the IRC channel is an easy process to remember.)
>
> This doesn't work well for people in other time zones. I guess we can just
> keep with the webkit process. I wonder if there's a way we can be more
> reliable about getting patches committed within a work-day of them getting
> approved (e.g. have a committer look over the list of approved patches every
> day to commit things).
> Ojan
>
>>
>> -Darin
>>
>> On Tue, Dec 16, 2008 at 1:43 PM, Ojan Vafai  wrote:
>>>
>>> Do we have a list of chromium committers who are also webkit committers?
>>> Should we have some sort of process for how to get help getting webkit
>>> patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
>>> of the committers (darin mainly) just committing all our patches. Seems like
>>> there could be a better way. Should we have some queue of webkit patches
>>> that need comitting maybe? Or a mailing list people can email when they have
>>> an r+'ed patch?
>>> This came up because we have a patch open that's now a week delayed in
>>> getting committed since it's been r+'ed. It's not anyones fault. It just
>>> fell through the cracks as there's no official process.
>>> Ojan
>>>
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Ojan Vafai]

On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher  wrote:

> http://nightly.webkit.org/start has a link to the list of approved 
> patchesthat
>  simply need to be landed.  In the past, I have used that link to locate
> patches to commit that were created by Chromium folks who lack commit
> access.
>
> I'm not a huge fan of process since it requires learning about process.
>  Does it not work to ask in #chromium or #webkit for someone to help land a
> patch?  (Just ask in the IRC channel is an easy process to remember.)
>

This doesn't work well for people in other time zones. I guess we can just
keep with the webkit process. I wonder if there's a way we can be more
reliable about getting patches committed within a work-day of them getting
approved (e.g. have a committer look over the list of approved patches every
day to commit things).

Ojan


> -Darin
>
>
> On Tue, Dec 16, 2008 at 1:43 PM, Ojan Vafai  wrote:
>
>> Do we have a list of chromium committers who are also webkit committers?
>> Should we have some sort of process for how to get help getting webkit
>> patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
>> of the committers (darin mainly) just committing all our patches. Seems like
>> there could be a better way. Should we have some queue of webkit patches
>> that need comitting maybe? Or a mailing list people can email when they have
>> an r+'ed patch?
>> This came up because we have a patch open that's now a week delayed in
>> getting committed since it's been r+'ed. It's not anyones fault. It just
>> fell through the cracks as there's no official process.
>>
>> Ojan
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Adam Barth]

I can land a swath of these on Wednesday.

On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher  wrote:
> Here's the list IIRC:
> abarth
> brettw
> darin
> eseidel
> pamg
> pkasting
> With the following folks on deck:
> dglazkov
> mpcomplete
> tc
> http://nightly.webkit.org/start has a link to the list of approved patches
> that simply need to be landed.  In the past, I have used that link to locate
> patches to commit that were created by Chromium folks who lack commit
> access.
>
> I'm not a huge fan of process since it requires learning about process.
>  Does it not work to ask in #chromium or #webkit for someone to help land a
> patch?  (Just ask in the IRC channel is an easy process to remember.)
> -Darin
>
> On Tue, Dec 16, 2008 at 1:43 PM, Ojan Vafai  wrote:
>>
>> Do we have a list of chromium committers who are also webkit committers?
>> Should we have some sort of process for how to get help getting webkit
>> patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
>> of the committers (darin mainly) just committing all our patches. Seems like
>> there could be a better way. Should we have some queue of webkit patches
>> that need comitting maybe? Or a mailing list people can email when they have
>> an r+'ed patch?
>> This came up because we have a patch open that's now a week delayed in
>> getting committed since it's been r+'ed. It's not anyones fault. It just
>> fell through the cracks as there's no official process.
>> Ojan
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Darin Fisher]

Here's the list IIRC:
abarth
brettw
darin
eseidel
pamg
pkasting

With the following folks on deck:

dglazkov
mpcomplete
tc

http://nightly.webkit.org/start has a link to the list of approved
patchesthat
simply need to be landed.  In the past, I have used that link to
locate
patches to commit that were created by Chromium folks who lack commit
access.

I'm not a huge fan of process since it requires learning about process.
 Does it not work to ask in #chromium or #webkit for someone to help land a
patch?  (Just ask in the IRC channel is an easy process to remember.)

-Darin


On Tue, Dec 16, 2008 at 1:43 PM, Ojan Vafai  wrote:

> Do we have a list of chromium committers who are also webkit committers?
> Should we have some sort of process for how to get help getting webkit
> patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
> of the committers (darin mainly) just committing all our patches. Seems like
> there could be a better way. Should we have some queue of webkit patches
> that need comitting maybe? Or a mailing list people can email when they have
> an r+'ed patch?
> This came up because we have a patch open that's now a week delayed in
> getting committed since it's been r+'ed. It's not anyones fault. It just
> fell through the cracks as there's no official process.
>
> Ojan
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: list of webkit committers?

[Eric Seidel]

The "official" process I thought was that the reviewer should commit a
patch after reviewing.  But you're right, the WebKit commit queue is
well out of control.

http://webkit.org/pending-commit

You could certainly bring up such on webkit-dev.

-eric

On Tue, Dec 16, 2008 at 1:43 PM, Ojan Vafai  wrote:
> Do we have a list of chromium committers who are also webkit committers?
> Should we have some sort of process for how to get help getting webkit
> patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
> of the committers (darin mainly) just committing all our patches. Seems like
> there could be a better way. Should we have some queue of webkit patches
> that need comitting maybe? Or a mailing list people can email when they have
> an r+'ed patch?
> This came up because we have a patch open that's now a week delayed in
> getting committed since it's been r+'ed. It's not anyones fault. It just
> fell through the cracks as there's no official process.
> Ojan
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] list of webkit committers?

[Ojan Vafai]

Do we have a list of chromium committers who are also webkit committers?
Should we have some sort of process for how to get help getting webkit
patches that have been r+'ed committed? Up to now, it's been an ad-hoc thing
of the committers (darin mainly) just committing all our patches. Seems like
there could be a better way. Should we have some queue of webkit patches
that need comitting maybe? Or a mailing list people can email when they have
an r+'ed patch?
This came up because we have a patch open that's now a week delayed in
getting committed since it's been r+'ed. It's not anyones fault. It just
fell through the cracks as there's no official process.

Ojan

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Martin]

On Tue, Dec 16, 2008 at 11:57 AM, Evan Martin  wrote:
> On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
>> 2) Run them locally.
>
> One more gotcha: due to a bug our debug output is different than the
> opt output.  Adam is fixing it.
> The builder is running opt, but we want debug output in our baselines.
>  So run your tests locally with the debug test_shell and just ignore
> tests that are already passing locally.

This is now fixed, but make sure you have r7088 or higher (there was a bug).

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: quick sort test results

[Andy]

Forgot to mention that I was using test page located in chromium\src
\webkit\data\test_shell\sort\sort.html

Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: quick sort test results

[Mike Belshe]

What are you sorting?  (can you provide the test?)

You could look at about:stats and see if the GC times are going nuts.
Or, if you're sorting DOM nodes, it may be that we're getting bogged
down with large numbers of JS wrapper creations.

Mike


On Tue, Dec 16, 2008 at 12:34 PM, Andy  wrote:
>
> Hi, All
>
> Just did some tests about quick sort across the Chrome/Firefox/IE7.
> Here is the results:
>
> samples:  0.3K  3K  30K
> nlog(n):743 10431   134313
> Chrome:   400   13700   1316501(only 1 time, it's around 20mins)
> Firefox:  1200  28240   no-response
> IE7: 2500   638406  no need to
>
> 30K results
> Quick Sort
> Times(ms)   Total   Avg Max
> Total   1316501 348 320
> Work42961   11  124
> Overhead1273540 336 699
>
> Env: Core2duo 2.33G, mem 4G, XP2002-SP3, Chrome 1.0.154.36
>
> It seems Chrome is fast, really fast but need to improve when samples
> are big, very big.
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] quick sort test results

[Andy]

Hi, All

Just did some tests about quick sort across the Chrome/Firefox/IE7.
Here is the results:

samples:  0.3K  3K  30K
nlog(n):743 10431   134313
Chrome:   400   13700   1316501(only 1 time, it's around 20mins)
Firefox:  1200  28240   no-response
IE7: 2500   638406  no need to

30K results
Quick Sort
Times(ms)   Total   Avg Max
Total   1316501 348 320
Work42961   11  124
Overhead1273540 336 699

Env: Core2duo 2.33G, mem 4G, XP2002-SP3, Chrome 1.0.154.36

It seems Chrome is fast, really fast but need to improve when samples
are big, very big.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Adam Langley]

On Tue, Dec 16, 2008 at 12:07 PM, Dan Kegel  wrote:
> Picking a random spot to start has worked for me on other projects.
> Checking with others via irc or
> http://code.google.com/p/chromium/wiki/LinuxAttackPlan
> also seems like a good idea as long as it doesn't slow anybody down.

My aim is to get the pixeltests in good shape rather than to fix any
tests as such. I'll be going though the tests to find the ones where
the render tree matches Windows and the pixel output is accepted by
the fuzzy matcher and rebaselining them in bulk. I'll then manually
review those where the fuzzy matcher doesn't accept the change and
rebaseline those mismatches which are caused by form controls etc.


AGL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Dan Kegel]

On Tue, Dec 16, 2008 at 12:00 PM, Evan Stade  wrote:
>> SMO folks: any requests on how we can avoid collisions on this?  I
>> typically grab something from the middle (e.g. tables/mozilla/marvin)
>> and just hope I don't conflict.
>
> If it looks like something I've touched before, I tackle it. If it
> looks like something that "belongs" to someone (e.g. fonts = agl, css
> gradients = mmoss) then I leave it alone. But we could probably do
> with better coordination. Maybe create a google doc for what we are
> working on (or we can put it on the wiki, a la LinuxAttackPlan). That
> approach depends on people using it, though...

Picking a random spot to start has worked for me on other projects.
Checking with others via irc or
http://code.google.com/p/chromium/wiki/LinuxAttackPlan
also seems like a good idea as long as it doesn't slow anybody down.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Stade]

> SMO folks: any requests on how we can avoid collisions on this?  I
> typically grab something from the middle (e.g. tables/mozilla/marvin)
> and just hope I don't conflict.

If it looks like something I've touched before, I tackle it. If it
looks like something that "belongs" to someone (e.g. fonts = agl, css
gradients = mmoss) then I leave it alone. But we could probably do
with better coordination. Maybe create a google doc for what we are
working on (or we can put it on the wiki, a la LinuxAttackPlan). That
approach depends on people using it, though...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Martin]

On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
> 2) Run them locally.

One more gotcha: due to a bug our debug output is different than the
opt output.  Adam is fixing it.
The builder is running opt, but we want debug output in our baselines.
 So run your tests locally with the debug test_shell and just ignore
tests that are already passing locally.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Michael Moss]

On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
>
> Just so everyone's on the same page:
>
> As far as I know we're as close to Windows font metrics as we're gonna
> get.  Using the Windows render tree baselines we're only 0.4% behind
> Windows.  Most of that delta is probably stuff that we have that's
> really broken, and the font-related ones are likely stuff like italics
> small-caps helvetica (I think I really did see that test).
> The "WebKit Linux" builder on the buildbot is only running render tree tests.
>
> However, many of our image expected outputs need to be regenerated,
> because the font antialiasing is slightly different.
> Tony set up a temporary pixel builder on his desktop, which Googlers
> can access at go/chrome_linuxpixel ; hopefully that'll only be up
> during the current period where we're trying to get the Linux pixel
> tests matching the non-pixel Linux tests.  Currently we have 1554
> failing.
>
> So what we should be able to get done quickly is rebaseline only tests
> where we're actually passing.
> 1) Find some tests that are failing on the linux pixel builder.
> 2) Run them locally.
> 3) Verify that they are actually passing by comparing against the
> Windows baseline.  Please be very careful!  Many tests matter down to
> the pixel.
> 4) Rebaseline passing tests by running them with --new-baseline ; mark
> tests that are failing in the pixel world by adding to tests_fixable
> (and be sure to comment as to what the problem is).
>
> Adam wrote a nifty fuzzy image differ that can highlight "meaningful"
> diffs between images.  It's in third_party/fuzzymatch and maybe he can
> comment on how he uses it.
>
> SMO folks: any requests on how we can avoid collisions on this?  I
> typically grab something from the middle (e.g. tables/mozilla/marvin)
> and just hope I don't conflict.

I'm already working on an issue related to pattern drawing which I
think may affect a bunch of tests with "pattern", "gradient", or
"background" in the names, so for now I'll claim those.

Michael

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: linux layout tests status

[Evan Martin]

On Tue, Dec 16, 2008 at 11:48 AM, Evan Martin  wrote:
> 2) Run them locally.

E.g.:
  xargs ./run_webkit_tests.sh
 and then cut'n'paste a section from the failing list at the end of
the buildbot output

> 3) Verify that they are actually passing by comparing against the
> Windows baseline.  Please be very careful!  Many tests matter down to
> the pixel.
> 4) Rebaseline passing tests by running them with --new-baseline ; mark
> tests that are failing in the pixel world by adding to tests_fixable
> (and be sure to comment as to what the problem is).
>
> Adam wrote a nifty fuzzy image differ that can highlight "meaningful"
> diffs between images.  It's in third_party/fuzzymatch and maybe he can
> comment on how he uses it.
>
> SMO folks: any requests on how we can avoid collisions on this?  I
> typically grab something from the middle (e.g. tables/mozilla/marvin)
> and just hope I don't conflict.
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] linux layout tests status

[Evan Martin]

Just so everyone's on the same page:

As far as I know we're as close to Windows font metrics as we're gonna
get.  Using the Windows render tree baselines we're only 0.4% behind
Windows.  Most of that delta is probably stuff that we have that's
really broken, and the font-related ones are likely stuff like italics
small-caps helvetica (I think I really did see that test).
The "WebKit Linux" builder on the buildbot is only running render tree tests.

However, many of our image expected outputs need to be regenerated,
because the font antialiasing is slightly different.
Tony set up a temporary pixel builder on his desktop, which Googlers
can access at go/chrome_linuxpixel ; hopefully that'll only be up
during the current period where we're trying to get the Linux pixel
tests matching the non-pixel Linux tests.  Currently we have 1554
failing.

So what we should be able to get done quickly is rebaseline only tests
where we're actually passing.
1) Find some tests that are failing on the linux pixel builder.
2) Run them locally.
3) Verify that they are actually passing by comparing against the
Windows baseline.  Please be very careful!  Many tests matter down to
the pixel.
4) Rebaseline passing tests by running them with --new-baseline ; mark
tests that are failing in the pixel world by adding to tests_fixable
(and be sure to comment as to what the problem is).

Adam wrote a nifty fuzzy image differ that can highlight "meaningful"
diffs between images.  It's in third_party/fuzzymatch and maybe he can
comment on how he uses it.

SMO folks: any requests on how we can avoid collisions on this?  I
typically grab something from the middle (e.g. tables/mozilla/marvin)
and just hope I don't conflict.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Adam Langley]

On Tue, Dec 16, 2008 at 11:03 AM, Ben Goodger (Google)  
wrote:
> I would recommend starting by trying to get view.h/cc to compile on
> Linux (ifdef out a lot of the platform specific detritus to begin with
> - you don't need drag & drop on day 1). Once you've done this, you can
> try writing the Linux version of WidgetWin. That'd be WidgetGtk or
> WidgetWhatever you end up going with.

That's what I'm aiming for at the moment, however, view.h does pull in
huge amounts of stuff so I'm not there yet.


AGL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Ben Goodger (Google)]

The views system is designed with some amount of portability in mind.
The general design is intended to be as follows:

- Widget implementations are specific to a particular platform. See
WidgetWin for the Windows version.
- Almost all of the Views should be mostly cross platform, with the
exception of NativeControl and HWNDView and friends.

I would recommend starting by trying to get view.h/cc to compile on
Linux (ifdef out a lot of the platform specific detritus to begin with
- you don't need drag & drop on day 1). Once you've done this, you can
try writing the Linux version of WidgetWin. That'd be WidgetGtk or
WidgetWhatever you end up going with.

FYI, my eventual intent is for views to move into a DEP alongside
chrome instead of inside it, though chrome will always source it
@HEAD, at least for the forseeable future.

-Ben

On Tue, Dec 16, 2008 at 8:34 AM, Adam Langley  wrote:
>
> On Mon, Dec 15, 2008 at 11:23 PM, joshthecoder  wrote:
>> What are the plans so far on how to port the Views UI layout layer to
>> linux?
>
> I spent a couple of days last week porting views and it looks like
> it'll be quite the task. My method at the moment is to do it in a very
> hacky way for a few hours and then redo properly that which still
> makes sense in hindsight.
>
> #ifdefs should be kept to a minimum, but there's still a threshold at
> which it doesn't make sense to add another file. With chrome_canvas
> and chrome_font (actually in chrome/common/gfx, but needed to be done)
> I kept the header with #ifdefs and split the .cc files; doing binding
> at link time.
>
> For things like OSExchangeData which are very platform specific, one
> might split the header files too and use a forwarding header (#ifdef
> ... #include ... #else #include ... #endif).
>
>
> AGL
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Adam Langley]

On Tue, Dec 16, 2008 at 9:34 AM, Mohamed Mansour
 wrote:
> That is why it would be nice to see what Adam has done so we could attempt
> doing one view and see if it passes the way chromium wants to port.

Firstly, 5166aa12 was the port of chrome_canvas:
  
http://github.com/chromium/chromium/commit/5166aa126c43f74ecb38f71a15f3656ea65dbce1

In a previous commit I had copied chrome_canvas.cc to
chrome_canvas_win.cc (so that both shared the same history and
contents). Then, in this commit, I just deleted the platform specific
functions from chrome_canvas.cc and deleted the platform independent
functions from chrome_canvas_win.cc. That way it's clear the I'm not
changing any of the code (since everything is just a deletion). Then
the corresponding functions to those in chrome_canvas_win.cc went into
chrome_canvas_skia.cc (since they ended up being dependent on Skia
rather than Linux). Obviously there's still some major todo's in the
Skia file.

I also have a couple of other patches pending which touch actual files
in views/ I'll be getting to them later this week.



AGL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Peter Kasting]

On Tue, Dec 16, 2008 at 9:34 AM, Mohamed Mansour
wrote:

> So the first step to do now is to reorganize the views. The separation
> between the View and the Model since both of them exist in the same file. I
> always wondered why they are not separated, but now it kinda makes sense.
> For example lets look at the autocomplete_edit.cc:


You picked the one case where your statements are true, because this file is
only half-separated.  In most cases we wrote View and Model classes from the
beginning, but the AutocompleteEdit predates the View system and is only now
being slowly reworked.  I suggest not looking at it :)

PK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Mohamed Mansour]

So the first step to do now is to reorganize the views. The separation
between the View and the Model since both of them exist in the same file. I
always wondered why they are not separated, but now it kinda makes sense.
For example lets look at the autocomplete_edit.cc:
It consists of AutocompleteEditView  and AutocompleteEditModel, would it
make more sense to to create separate files called autocomplete_edit_model,
autocomplete_edit_view_win, autocomplete_edit_view_mac, etc  And refactor
the current AutocompleteEditView and AutocompleteEditModel out
of autocomplete_edit to platform specific classes? So we will
have AutocompleteEditViewWin, AutocompleteEditViewMac etc
That is why it would be nice to see what Adam has done so we could attempt
doing one view and see if it passes the way chromium wants to port.




On Tue, Dec 16, 2008 at 12:18 PM, Amanda Walker  wrote:

> On Tue, Dec 16, 2008 at 12:10 PM, Scott Violet  wrote:
>>
>> I believe the original thinking was that we would have view specific
>> implementations per platform and the code would change to go through a
>> factory for creating the leaf node views instead of using
>> constructors.
>
>
> Yes--this is why most of the view classes have associated "model" classes
> that encapsulate the state and behavior.  This way, view classes can use
> platform facilities for drawing (GTK, GDI, Cocoa, etc.), but the bulk of the
> logic behind the view can be platform neutral.
>
> I don't think that any of the current Windows view classes were ever
> intended to be "ported" per se.
>
> --Amanda
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Amanda Walker]

On Tue, Dec 16, 2008 at 12:10 PM, Scott Violet  wrote:
>
> I believe the original thinking was that we would have view specific
> implementations per platform and the code would change to go through a
> factory for creating the leaf node views instead of using
> constructors.


Yes--this is why most of the view classes have associated "model" classes
that encapsulate the state and behavior.  This way, view classes can use
platform facilities for drawing (GTK, GDI, Cocoa, etc.), but the bulk of the
logic behind the view can be platform neutral.

I don't think that any of the current Windows view classes were ever
intended to be "ported" per se.

--Amanda

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Scott Violet]

I believe the original thinking was that we would have view specific
implementations per platform and the code would change to go through a
factory for creating the leaf node views instead of using
constructors. All the platform specific code would exist in each of
the platform specific implementations. Any place we're using windows
specific code outside of the view classes would have to change to
either be wrapped around a #define, or promoted to the view class in a
platform neutral way.

 -Scott

On Mon, Dec 15, 2008 at 11:23 PM, joshthecoder  wrote:
>
> Currently the test_shell uses GTK to create a basic rendering for
> Chromium.
>
> What are the plans so far on how to port the Views UI layout layer to
> linux?
> Will a widget toolkit such as GTK be used? Or maybe just use a more
> direct approach such as XLib.
> Using XLib to directly communicate with X server might provide some
> extra speed much like using the Win32 API for the Windows version of
> Views, but XLib might be a bit too low level.
>
> I'd like to see the wheels get rolling on porting Views over to linux.
> This will be a major leap in getting Chrome running on linux. I'm
> interesting in helping contribute code for porting views. So if anyone
> has suggestions, ideas, or comments please post them. Let's get some
> ideas flowing.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Josh Roesslein]

Yes if you could provide some of the code that would be great. That way we
can see how to get started.

Yeah sticking to the convention of xxx_win.cc xxx_linux.cc would work fine.


On Tue, Dec 16, 2008 at 10:57 AM, Mohamed Mansour
wrote:

> Hey AGL, can you link me with your code review for some of your View ports,
> so I can see how you did them?
> So is it final to do platform independent views? That being said, a lot of
> refactoring should be done to reuse code.
>
> Thanks,
>
> On Tue, Dec 16, 2008 at 11:36 AM, Adam Langley  wrote:
>
>>
>> On Tue, Dec 16, 2008 at 8:07 AM, Josh Roesslein 
>> wrote:
>> > We would have to abstract the "windows.h" header in these headers. For
>> > example the HWND type from windows.h could
>> > be moved into views_basetypes.h and use an #if-def to dfine it:
>> >
>> > #if defined(WINDOWS)
>> > #include 
>> > #elseif  defined(GTK)
>> > typedef unsigned int HWND
>> > #endif
>> >
>> > Something like that could work. Bascially any types defined in
>> 
>> > could be defined for the other platforms.
>>
>> The typedefed HWND is "NativeView" (in base/gfx/native_widget_types.h).
>>
>> > Another side note, using GTK will also help in the porting to Mac OSX.
>> >
>> > Next we could divide the .cc files into the different platforms.
>> > views/windows  - holds all .cc files that implement for windows
>> > views/gtk - holds all .cc files that implement for the gtk toolkit
>>
>> Rather than directories we generally use xxx.cc (platform independent)
>> and xxx_win.cc/xxx_skia.cc/xxx_linux.cc. At least that's the pattern
>> that we maintain because of WebKit.
>>
>> The Mac folks will be doing their own thing which I doubt involves GTK :)
>>
>>
>> AGL
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Mohamed Mansour]

Hey AGL, can you link me with your code review for some of your View ports,
so I can see how you did them?
So is it final to do platform independent views? That being said, a lot of
refactoring should be done to reuse code.

Thanks,

On Tue, Dec 16, 2008 at 11:36 AM, Adam Langley  wrote:

>
> On Tue, Dec 16, 2008 at 8:07 AM, Josh Roesslein 
> wrote:
> > We would have to abstract the "windows.h" header in these headers. For
> > example the HWND type from windows.h could
> > be moved into views_basetypes.h and use an #if-def to dfine it:
> >
> > #if defined(WINDOWS)
> > #include 
> > #elseif  defined(GTK)
> > typedef unsigned int HWND
> > #endif
> >
> > Something like that could work. Bascially any types defined in
> 
> > could be defined for the other platforms.
>
> The typedefed HWND is "NativeView" (in base/gfx/native_widget_types.h).
>
> > Another side note, using GTK will also help in the porting to Mac OSX.
> >
> > Next we could divide the .cc files into the different platforms.
> > views/windows  - holds all .cc files that implement for windows
> > views/gtk - holds all .cc files that implement for the gtk toolkit
>
> Rather than directories we generally use xxx.cc (platform independent)
> and xxx_win.cc/xxx_skia.cc/xxx_linux.cc. At least that's the pattern
> that we maintain because of WebKit.
>
> The Mac folks will be doing their own thing which I doubt involves GTK :)
>
>
> AGL
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Adam Langley]

On Tue, Dec 16, 2008 at 8:07 AM, Josh Roesslein  wrote:
> We would have to abstract the "windows.h" header in these headers. For
> example the HWND type from windows.h could
> be moved into views_basetypes.h and use an #if-def to dfine it:
>
> #if defined(WINDOWS)
> #include 
> #elseif  defined(GTK)
> typedef unsigned int HWND
> #endif
>
> Something like that could work. Bascially any types defined in 
> could be defined for the other platforms.

The typedefed HWND is "NativeView" (in base/gfx/native_widget_types.h).

> Another side note, using GTK will also help in the porting to Mac OSX.
>
> Next we could divide the .cc files into the different platforms.
> views/windows  - holds all .cc files that implement for windows
> views/gtk - holds all .cc files that implement for the gtk toolkit

Rather than directories we generally use xxx.cc (platform independent)
and xxx_win.cc/xxx_skia.cc/xxx_linux.cc. At least that's the pattern
that we maintain because of WebKit.

The Mac folks will be doing their own thing which I doubt involves GTK :)


AGL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Adam Langley]

On Mon, Dec 15, 2008 at 11:23 PM, joshthecoder  wrote:
> What are the plans so far on how to port the Views UI layout layer to
> linux?

I spent a couple of days last week porting views and it looks like
it'll be quite the task. My method at the moment is to do it in a very
hacky way for a few hours and then redo properly that which still
makes sense in hindsight.

#ifdefs should be kept to a minimum, but there's still a threshold at
which it doesn't make sense to add another file. With chrome_canvas
and chrome_font (actually in chrome/common/gfx, but needed to be done)
I kept the header with #ifdefs and split the .cc files; doing binding
at link time.

For things like OSExchangeData which are very platform specific, one
might split the header files too and use a forwarding header (#ifdef
... #include ... #else #include ... #endif).


AGL

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: porting views to linux/posix

[Josh Roesslein]

I don't think if-defs would be the best way to go. The code would become
very messy and confusing.

I think we could use the headers of the views and use those as interfaces
for the different implementations.
We would have to abstract the "windows.h" header in these headers. For
example the HWND type from windows.h could
be moved into views_basetypes.h and use an #if-def to dfine it:

#if defined(WINDOWS)
#include 
#elseif  defined(GTK)
typedef unsigned int HWND
#endif

Something like that could work. Bascially any types defined in 
could be defined for the other platforms.

Another side note, using GTK will also help in the porting to Mac OSX.

Next we could divide the .cc files into the different platforms.
views/windows  - holds all .cc files that implement for windows
views/gtk - holds all .cc files that implement for the gtk toolkit


On Tue, Dec 16, 2008 at 1:50 AM, Mohamed Mansour
wrote:

> I would like to see the plans on how would we approach the porting,many
> views use direct Win32 API calls for mouse events, keyboard,
> painting, etc. What would the proper way doing this, create a class
> with a bunch if if-defs and just calling that. If there are plans on
> what to do, I could spend time porting the correct way instead
> of doing it the incorrect way.
>
> /m0
>
>
> On Tue, Dec 16, 2008 at 2:23 AM, joshthecoder wrote:
>
>>
>> Currently the test_shell uses GTK to create a basic rendering for
>> Chromium.
>>
>> What are the plans so far on how to port the Views UI layout layer to
>> linux?
>> Will a widget toolkit such as GTK be used? Or maybe just use a more
>> direct approach such as XLib.
>> Using XLib to directly communicate with X server might provide some
>> extra speed much like using the Win32 API for the Windows version of
>> Views, but XLib might be a bit too low level.
>>
>> I'd like to see the wheels get rolling on porting Views over to linux.
>> This will be a major leap in getting Chrome running on linux. I'm
>> interesting in helping contribute code for porting views. So if anyone
>> has suggestions, ideas, or comments please post them. Let's get some
>> ideas flowing.
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: bookmark menu

[Chris G]

They are right that it is not possible to please everyone, and someone
needs to make the decisions as to what the browser will and won't
offer.  They are allowed to say no.

Following my attempts on here, I have left them to bring out more
releases and see how they address the shortcomings we have brought to
their attention.  There is now a new bookmark manager GUI.

In all honesty, it isn't that much of a hardship to just turn on your
bookmark bar (Ctrl+B) if you like using bookmarks.  I am happy using
Chrome like this, and to be honest I like it with the bookmark bar on
now, and buttons for my top 10 websites!

They don't use bookmarks themselves, and just type and search every
time. (Google, search??)..

Chris



On Dec 16, 3:23 pm, "Simon B."  wrote:
> Chris and Bizzeh, why not compile your own Chromium binaries and get
> some people to try it out?
>
> PS. You obviously need more than your own vote/voice to convince the
> Chromium team to take your patches, and that's very reasonable.
> Otherwise, count the # of participants on this forum and imagine a
> browser with everybodys favourite feature.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: bookmark menu

[Amanda Walker]

On Mon, Dec 15, 2008 at 8:41 PM, Bizzeh  wrote:

> this views do intersect with my own, however i do not feel that i was
> fairly treated. i feel as if i was treated as "the kid that nobody
> wants around at school" because everybody is fine as they are.


Darren, where are you getting this impression from?  I've just re-read the
entire thread about your patch, and all I see are questions about whether
there might be an even better way to solve the problem, and whether you have
some data backing up your assertion about what "most users want".

This is not a rejection of your patch, it's just the kind of scrutiny every
new feature gets.


> what i have tried to introduce today is a feature that is a staple part of
> a
> browser, fast no-frills access to a users bookmarks. as this was met
> with critisism from the start, i tried the harder in order to win
> favour for compleating the feature. which was then met with "why
> should we add it when we dont know if people want it, and it might
> mess up our image", which i have taken the liberty of translating "we
> dont want to be anything like the other browsers at the detrement of
> our own browsers usability".


I think you are misreading the feedback people have been giving.


> the least i expected was for the feature i had taken the time to
>
create to be considered, rather than instantly dismissed.


It hasn't been instantly dismissed--a number of people (such as Ben) are
just asking if there are better ways to do it.

While getting huffy, talking about pictures of hitler, and threatening to
give up if your patch isn't accepted is not the best way to engage people in
discussion, you've made a very good start by actually implementing your
idea.  This already puts you way ahead of people who have an idea that they
think *other* people should implement :-).  Many great features start as
"this is bugging me, so I'll go fix it", even if the end result doesn't
always match the initial idea.

As with most open source projects, not every patch is accepted immediately,
and some may require many iterations.  Chrome's UI is intentionally minimal,
so changes that affect the UI will by their nature prompt more discussion
than ones that are just behind-the-scenes bug fixes.  "Let's talk about this
and make sure it's really the way we should be solving this problem" is
actually a good sign, not a rejection.

--Amanda

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Trunk build's biggest annoyances?

[Marc-Antoine Ruel]

We need to stabilize the trunk first. We're doing that right now.
Trunk will be sent to the dev channel soon.

On Tue, Dec 16, 2008 at 10:20 AM, Marshall Greenblatt
 wrote:
> What is chromium's usage plan for /trunk?  It seems that recent beta and
> release builds of chrome are coming off of /branches/chrome_official_branch
> -- is there a process in place to synchronize
> /branches/chrome_official_branch with /trunk at some set interval?  Or will
> they be kept separate with changes moving between them only as needed?
>
> Thanks,
> Marshall
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Trunk build's biggest annoyances?

[Marshall Greenblatt]

What is chromium's usage plan for /trunk?  It seems that recent beta and
release builds of chrome are coming off of /branches/chrome_official_branch
-- is there a process in place to synchronize
/branches/chrome_official_branch with /trunk at some set interval?  Or will
they be kept separate with changes moving between them only as needed?

Thanks,
Marshall

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: bookmark menu

[Simon B.]

Chris and Bizzeh, why not compile your own Chromium binaries and get
some people to try it out?

PS. You obviously need more than your own vote/voice to convince the
Chromium team to take your patches, and that's very reasonable.
Otherwise, count the # of participants on this forum and imagine a
browser with everybodys favourite feature.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: bookmark menu

[Chris G]

I already tried this one and got no where with them.  And at the end
of the day it is their project - just switch on your bookmark bar
permanently.

Chris



On Dec 16, 1:41 am, Bizzeh  wrote:
> this views do intersect with my own, however i do not feel that i was
> fairly treated. i feel as if i was treated as "the kid that nobody
> wants around at school" because everybody is fine as they are. what i
> have tried to introduce today is a feature that is a staple part of a
> browser, fast no-frills access to a users bookmarks. as this was met
> with critisism from the start, i tried the harder in order to win
> favour for compleating the feature. which was then met with "why
> should we add it when we dont know if people want it, and it might
> mess up our image", which i have taken the liberty of translating "we
> dont want to be anything like the other browsers at the detrement of
> our own browsers usability".
>
> i wasnt in any way trying to be nasty or offencive. i was simply
> speaking my mind about the situation in hand that should never have
> risen its head.
>
> the least i expected was for the feature i had taken the time to
> create to be considered, rather than instantly dismissed.
>
> Regards,
> Darren
>
> On 16 Dec, 01:32, "Ben Goodger (Google)"  wrote:
>
> > Thanks for taking the time to send us your thoughts.
>
> > Chrome functions as a project at scale by maintaining a set of
> > development principles (some of which are outlined 
> > here:http://dev.chromium.org/developers/contributing-code). One of these
> > principles is encouraging communication with each other in a
> > reasonable fashion.
>
> > To be a successful member of the Chromium project, you should be
> > mindful of the way we work and considerate of the principles that we
> > think are important (such as communicating your ideas early, building
> > consensus, backing up your arguments with data where appropriate,
> > being prepared to have your ideas be challenged by your peers). Coming
> > in and trying to blackmail us by saying we're losing a developer if we
> > don't agree with you isn't going to work.
>
> > If these values don't intersect with yours, then there may not be a
> > good cultural fit for you in the Chromium project.
>
> > -Ben
>
> > On Mon, Dec 15, 2008 at 5:21 PM, Bizzeh  wrote:
>
> > > this has totally missed the issue, the issue is not about user
> > > customisation, its about user experiance.
>
> > > nowhere did i mention anything about customising the toolbar, and
> > > nowhere did i limit it.
>
> > > what i did do, was reduce the amount of time needed to navigate
> > > bookmarks, and make it obvious that chrome actually has the feature.
>
> > > please, i am not some stupid kid who will fall for tactics such as
> > > avoiding the question, and creating unanswerable questions.
>
> > > congratulations on loosing a potential developer
>
> > > On 16 Dec, 01:16, "Ben Goodger (Google)"  wrote:
> > >> I am generally supportive of allowing users to put UI elements where
> > >> they want, but I think the right context for this work is in allowing
> > >> our toolbars to be customizable, as is possible in other software,
> > >> rather than special casing this one particular issue. The end result
> > >> for you, and others who have the same preferences is the same, but the
> > >> way of getting there is much more powerful (and allows other people to
> > >> create the configurations they want, too).
>
> > >> -Ben
>
> > >> On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks
>
> > >>  wrote:
> > >> > i have recently created a patch and submitted it to codereview
> > >> >http://codereview.chromium.org/14441/show
>
> > >> > the patch adds a menu button to the right of the address bar and the 
> > >> > menu
> > >> > gives a menu of all the bookmarks within the bookmark manager and 
> > >> > allows for
> > >> > a user to navigate to their bookmarks without the need for the 
> > >> > bookmark bar
> > >> > or opening a new tab and then going to the bookmark button.
>
> > >> > the patch was designed for generally speeding up access to the users
> > >> > bookmarks, as this is one of the most complained about missing 
> > >> > features that
> > >> > i have heard while in offices and around the web and around irc.
> > >> > IE7 has the star button, IE6 had the old style dropdown menu, safari 
> > >> > also
> > >> > has the old style dropdown menu as with IE6. firefox and opera also 
> > >> > have
> > >> > similar features directly on the main interface without the need to 
> > >> > waste
> > >> > extra screen real estate on another toolbar we dont need.
>
> > >> > as this is at most a 28 pixel reduction in the width of the address 
> > >> > bar,
> > >> > this is a far better use of the screen than 24 pixels of height in the 
> > >> > form
> > >> > of an additional toolbar removing from the actual browser visability.
>
> > >> > and as most people will only use the bookmark bar to access the "other
> > >> > bookmarks" button, this trul

[chromium-dev] Re: Trunk build's biggest annoyances?

[Mohamed Mansour]

My biggest annoyance is the tab dragging as well and it has been broken
http://crbug.com/5118 and another one would be pages rendered wrong after
working in a previous build such as Facebook. There are many small stuff
here and there but we can live with them.
/m0


On Tue, Dec 16, 2008 at 3:19 AM, Jo  wrote:

>
> Here is one: when you have a window without tab, just a caption and a
> icon, the icon doesn't show as a button.
> :)
>
> On Dec 16, 2:56 am, Adam Barth  wrote:
> > Apparently my bug searching skills just suck.  :)
> >
> >
> >
> > On Mon, Dec 15, 2008 at 11:52 PM, Adam Barth 
> wrote:
> > > I'm not sure what the policy is for making up labels on the bug
> > > tracker, but I labeled these bugs "SuperAnnoying".  I filed and
> > > labeled another bug (space bar doesn't scroll window).
> >
> > > Either my bug search skills suck or not that many people are
> > > dogfooding trunk.  How can it be that no one noticed that the space
> > > bar doesn't scroll the page or that the Facebook home screen is
> > > rendered wrong?  (Maybe these are very recent regressions?)
> >
> > > Adam
> >
> > > On Mon, Dec 15, 2008 at 5:01 PM, Patrick Johnson 
> wrote:
> >
> > >> I thinkhttp://crbug.com/5118is one of my biggest annoyances.  I'm a
> > >> fan of tab dragging, and it's been fairly broken recently (at least in
> > >> maximized mode).
> >
> > >> Patrick
> >
> > >> On Mon, Dec 15, 2008 at 4:50 PM, Mark Larson (Google) <
> m...@chromium.org> wrote:
> > >>>  is
> > >>> public on chromium-dev.>
> > >>> I want to do a Dev channel release from the trunk soon.
> > >>> I know there are a lot of issues with the current trunk because it
> hasn't
> > >>> had the same test exposure or release pressure as the 154 branch.
> > >>> I don't plan to get trunk to a Beta level of stability before
> releasing, but
> > >>> I would like to know what the biggest problems are so we can evaluate
> what
> > >>> needs to be fixed (or put under 'Known Issues'). I know there are
> bugs on
> > >>> file, but I'm trying to get a sense of the real burning issues from
> people
> > >>> who are actually using trunk (or trying to use it) every day.
> > >>> So... what are the 1-3 top issues you think need to get fixed on
> trunk to
> > >>> make it bearable for everyday use?
> > >>> My biggest peeve right now is the browser crash when you close an app
> window
> > >>> (at least once a day I take down my whole browser by closing my
> calendar.
> > >>> D'oh!).
> > >>> --Mark
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Trunk build's biggest annoyances?

[Jo]

Here is one: when you have a window without tab, just a caption and a
icon, the icon doesn't show as a button.
:)

On Dec 16, 2:56 am, Adam Barth  wrote:
> Apparently my bug searching skills just suck.  :)
>
>
>
> On Mon, Dec 15, 2008 at 11:52 PM, Adam Barth  wrote:
> > I'm not sure what the policy is for making up labels on the bug
> > tracker, but I labeled these bugs "SuperAnnoying".  I filed and
> > labeled another bug (space bar doesn't scroll window).
>
> > Either my bug search skills suck or not that many people are
> > dogfooding trunk.  How can it be that no one noticed that the space
> > bar doesn't scroll the page or that the Facebook home screen is
> > rendered wrong?  (Maybe these are very recent regressions?)
>
> > Adam
>
> > On Mon, Dec 15, 2008 at 5:01 PM, Patrick Johnson  
> > wrote:
>
> >> I thinkhttp://crbug.com/5118is one of my biggest annoyances.  I'm a
> >> fan of tab dragging, and it's been fairly broken recently (at least in
> >> maximized mode).
>
> >> Patrick
>
> >> On Mon, Dec 15, 2008 at 4:50 PM, Mark Larson (Google)  
> >> wrote:
> >>>  >>> public on chromium-dev.>
> >>> I want to do a Dev channel release from the trunk soon.
> >>> I know there are a lot of issues with the current trunk because it hasn't
> >>> had the same test exposure or release pressure as the 154 branch.
> >>> I don't plan to get trunk to a Beta level of stability before releasing, 
> >>> but
> >>> I would like to know what the biggest problems are so we can evaluate what
> >>> needs to be fixed (or put under 'Known Issues'). I know there are bugs on
> >>> file, but I'm trying to get a sense of the real burning issues from people
> >>> who are actually using trunk (or trying to use it) every day.
> >>> So... what are the 1-3 top issues you think need to get fixed on trunk to
> >>> make it bearable for everyday use?
> >>> My biggest peeve right now is the browser crash when you close an app 
> >>> window
> >>> (at least once a day I take down my whole browser by closing my calendar.
> >>> D'oh!).
> >>> --Mark
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---