[chromium-dev] Major tab cold regression on mac around r24415

[Mike Pinkerton]

If you look at

 
http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150

You'll see a pretty big spike in new tab performance between r24415 and r24419

 
http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419

Anyone know what's going on? This is a very serious regression and
there were no Mac-specific changes anywhere in the vicinity that I
could see. I filed

  http://code.google.com/p/chromium/issues/detail?id=20312

to cover the regression.

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

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Evan Martin]

PS Every time I want to call it the "EPIC CHANGE".

On Wed, Aug 26, 2009 at 9:27 AM, Evan Martin wrote:
> Here's a guess: the "history" file is restored each time the test
> runs, and Brett's epoch change means that we need to re-migrate the
> history file every time we start.
>
> (I don't recall how this test works, but it seems logical to test NTP
> performance you'd want some data that the NTP would make use of...)
>
> On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton wrote:
>>
>> If you look at
>>
>>  http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
>>
>> You'll see a pretty big spike in new tab performance between r24415 and 
>> r24419
>>
>>  http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
>>
>> Anyone know what's going on? This is a very serious regression and
>> there were no Mac-specific changes anywhere in the vicinity that I
>> could see. I filed
>>
>>  http://code.google.com/p/chromium/issues/detail?id=20312
>>
>> to cover the regression.
>>
>> --
>> Mike Pinkerton
>> Mac Weenie
>> pinker...@google.com
>>
>> >>
>>
>

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

[chromium-dev] Chromium Engineering Snippets for 8/17 - 8/23

[Glen Murphy]

Chromium Engineering Snippets 8/17 - 8/23

- Chromium builder on webkit.org going up this week.
- Notifications[1] work starting to land
- Global Script Context[2] engineering starting
- O3D on track to be in Chrome dev channel by EOQ
- Epoch change landing for Mac/Linux history databases
- 3.0 RC getting cut Wednesday AM
- Linux 64-bit soon
- Extensions close to being enabled by default on dev channel

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html
[2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022113.html

-

Q: What is this?
A: A short weekly overview of what is happening in Chromium's
 development - it's intended as mechanism for allowing people to
 know what large efforts are starting and landing. Please bear
 with us while we improve coverage and latency.

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Thomas Van Lenten]

On Wed, Aug 26, 2009 at 12:32 PM, Thomas Van Lenten
wrote:

>
>
> On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin  wrote:
>
>>
>> PS Every time I want to call it the "EPIC CHANGE".
>>
>> On Wed, Aug 26, 2009 at 9:27 AM, Evan Martin wrote:
>> > Here's a guess: the "history" file is restored each time the test
>> > runs, and Brett's epoch change means that we need to re-migrate the
>> > history file every time we start.
>> >
>> > (I don't recall how this test works, but it seems logical to test NTP
>> > performance you'd want some data that the NTP would make use of...)
>
>
> Wouldn't linux show this data also?  or the non theme test also show it?
>

I spoke too soon:
http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150

looks like linux also sees it.

TVL


>
> TVL
>
>
>>
>> >
>> > On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton
>> wrote:
>> >>
>> >> If you look at
>> >>
>> >>
>> http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
>> >>
>> >> You'll see a pretty big spike in new tab performance between r24415 and
>> r24419
>> >>
>> >>
>> http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
>> >>
>> >> Anyone know what's going on? This is a very serious regression and
>> >> there were no Mac-specific changes anywhere in the vicinity that I
>> >> could see. I filed
>> >>
>> >>  http://code.google.com/p/chromium/issues/detail?id=20312
>> >>
>> >> to cover the regression.
>> >>
>> >> --
>> >> Mike Pinkerton
>> >> Mac Weenie
>> >> pinker...@google.com
>> >>
>> >> >>
>> >>
>> >
>>
>> >>
>>
>

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Dean McNamee]

Looking at the graphs this would seem to make sense.  All of the tests
except the one using 'typical_history' have regressed.  That's because
Brett checked in the upgraded database for typical_history, but not
for the other themes.  We should just upgrade those and check them in.

On Wed, Aug 26, 2009 at 9:46 AM, Thomas Van Lenten
 wrote:
>
>
> On Wed, Aug 26, 2009 at 12:32 PM, Thomas Van Lenten 
> wrote:
>>
>>
>> On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin  wrote:
>>>
>>> PS Every time I want to call it the "EPIC CHANGE".
>>>
>>> On Wed, Aug 26, 2009 at 9:27 AM, Evan Martin wrote:
>>> > Here's a guess: the "history" file is restored each time the test
>>> > runs, and Brett's epoch change means that we need to re-migrate the
>>> > history file every time we start.
>>> >
>>> > (I don't recall how this test works, but it seems logical to test NTP
>>> > performance you'd want some data that the NTP would make use of...)
>>
>> Wouldn't linux show this data also?  or the non theme test also show it?
>
> I spoke too
> soon: http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150
> looks like linux also sees it.
> TVL
>
>>
>> TVL
>>
>>>
>>> >
>>> > On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton
>>> > wrote:
>>> >>
>>> >> If you look at
>>> >>
>>> >>
>>> >>  http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
>>> >>
>>> >> You'll see a pretty big spike in new tab performance between r24415
>>> >> and r24419
>>> >>
>>> >>
>>> >>  http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
>>> >>
>>> >> Anyone know what's going on? This is a very serious regression and
>>> >> there were no Mac-specific changes anywhere in the vicinity that I
>>> >> could see. I filed
>>> >>
>>> >>  http://code.google.com/p/chromium/issues/detail?id=20312
>>> >>
>>> >> to cover the regression.
>>> >>
>>> >> --
>>> >> Mike Pinkerton
>>> >> Mac Weenie
>>> >> pinker...@google.com
>>> >>
>>> >> >>
>>> >>
>>> >
>>>
>>>
>>
>
>
> >
>

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Mike Pinkerton]

I don't think that's it, because it's just one test that's affected.
If it were the epoch change, I'd expect more tests to show similar
bumps.

On Wed, Aug 26, 2009 at 9:28 AM, Evan Martin wrote:
> PS Every time I want to call it the "EPIC CHANGE".
>
> On Wed, Aug 26, 2009 at 9:27 AM, Evan Martin wrote:
>> Here's a guess: the "history" file is restored each time the test
>> runs, and Brett's epoch change means that we need to re-migrate the
>> history file every time we start.
>>
>> (I don't recall how this test works, but it seems logical to test NTP
>> performance you'd want some data that the NTP would make use of...)
>>
>> On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton 
>> wrote:
>>>
>>> If you look at
>>>
>>>  http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
>>>
>>> You'll see a pretty big spike in new tab performance between r24415 and 
>>> r24419
>>>
>>>  http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
>>>
>>> Anyone know what's going on? This is a very serious regression and
>>> there were no Mac-specific changes anywhere in the vicinity that I
>>> could see. I filed
>>>
>>>  http://code.google.com/p/chromium/issues/detail?id=20312
>>>
>>> to cover the regression.
>>>
>>> --
>>> Mike Pinkerton
>>> Mac Weenie
>>> pinker...@google.com
>>>
>>> >>>
>>>
>>
>



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

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Evan Martin]

Here's a guess: the "history" file is restored each time the test
runs, and Brett's epoch change means that we need to re-migrate the
history file every time we start.

(I don't recall how this test works, but it seems logical to test NTP
performance you'd want some data that the NTP would make use of...)

On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton wrote:
>
> If you look at
>
>  http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
>
> You'll see a pretty big spike in new tab performance between r24415 and r24419
>
>  http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
>
> Anyone know what's going on? This is a very serious regression and
> there were no Mac-specific changes anywhere in the vicinity that I
> could see. I filed
>
>  http://code.google.com/p/chromium/issues/detail?id=20312
>
> to cover the regression.
>
> --
> Mike Pinkerton
> Mac Weenie
> pinker...@google.com
>
> >
>

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

[chromium-dev] Copying of profiles across systems

[Avi Drissman]

I've heard people proclaim the principle of being able to copy a profile
across systems as being a deciding factor for certain changes (e.g. the
history epoch change). However, it doesn't seem to be universally held or
obeyed, and I'm not sure to the extent to which it can be obeyed. So some
questions:

- Is "profile platform independence" a guiding principle?
- To what extent do we work to make it reality?
- In the cases where it can't be kept (e.g. download folder path) should we
keep a copy for each platform?
- Is it worth rewriting today's code that doesn't conform (e.g. extensions
and themes which use full paths and platform path separators)?

Avi

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

[chromium-dev] Re: Major tab cold regression on mac around r24415

[Thomas Van Lenten]

On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin  wrote:

>
> PS Every time I want to call it the "EPIC CHANGE".
>
> On Wed, Aug 26, 2009 at 9:27 AM, Evan Martin wrote:
> > Here's a guess: the "history" file is restored each time the test
> > runs, and Brett's epoch change means that we need to re-migrate the
> > history file every time we start.
> >
> > (I don't recall how this test works, but it seems logical to test NTP
> > performance you'd want some data that the NTP would make use of...)


Wouldn't linux show this data also?  or the non theme test also show it?

TVL


>
> >
> > On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkerton
> wrote:
> >>
> >> If you look at
> >>
> >>
> http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150
> >>
> >> You'll see a pretty big spike in new tab performance between r24415 and
> r24419
> >>
> >>
> http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=24415:24419
> >>
> >> Anyone know what's going on? This is a very serious regression and
> >> there were no Mac-specific changes anywhere in the vicinity that I
> >> could see. I filed
> >>
> >>  http://code.google.com/p/chromium/issues/detail?id=20312
> >>
> >> to cover the regression.
> >>
> >> --
> >> Mike Pinkerton
> >> Mac Weenie
> >> pinker...@google.com
> >>
> >> >>
> >>
> >
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Brett Wilson]

On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> I've heard people proclaim the principle of being able to copy a profile
> across systems as being a deciding factor for certain changes (e.g. the
> history epoch change). However, it doesn't seem to be universally held or
> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
> questions:
>
> - Is "profile platform independence" a guiding principle?
> - To what extent do we work to make it reality?

I don't think this is a guiding principle. We should do it when it's
reasonable. I think most places it is reasonable to do so.

> - In the cases where it can't be kept (e.g. download folder path) should we
> keep a copy for each platform?

I don't think so.

> - Is it worth rewriting today's code that doesn't conform (e.g. extensions
> and themes which use full paths and platform path separators)?

I don't think so, although I do wonder if full paths are necessary,
even if we're not worried about platform portability (not knowing
anything about what these are used for if there are any).

Brett

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

[chromium-dev] Re: Copying of profiles across systems

[John Abd-El-Malek]

I think this is one of those things that aren't worth the effort.  Brett's
change was also to fix other bugs, so it wasn't just for this.  I'd be
surprised if people spend time to fix bugs solely for this.

On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman  wrote:

> I've heard people proclaim the principle of being able to copy a profile
> across systems as being a deciding factor for certain changes (e.g. the
> history epoch change). However, it doesn't seem to be universally held or
> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
> questions:
>
> - Is "profile platform independence" a guiding principle?
> - To what extent do we work to make it reality?
> - In the cases where it can't be kept (e.g. download folder path) should we
> keep a copy for each platform?
> - Is it worth rewriting today's code that doesn't conform (e.g. extensions
> and themes which use full paths and platform path separators)?
>
> Avi
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Darin Fisher]

On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman  wrote:

> I've heard people proclaim the principle of being able to copy a profile
> across systems as being a deciding factor for certain changes (e.g. the
> history epoch change). However, it doesn't seem to be universally held or
> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
> questions:
>
> - Is "profile platform independence" a guiding principle?
>

Yes, sort of.



> - To what extent do we work to make it reality?
>

Not as much as we probably should.



> - In the cases where it can't be kept (e.g. download folder path) should we
> keep a copy for each platform?
>

Good question.  That seems fairly reasonable.



> - Is it worth rewriting today's code that doesn't conform (e.g. extensions
> and themes which use full paths and platform path separators)?
>

Is is a bug if we store absolute file paths in the profile directory.  You
should at least be able to copy it from one directory to another on your
system.

-Darin

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

[chromium-dev] Re: Copying of profiles across systems

[Dan Kegel]

On Wed, Aug 26, 2009 at 12:28 PM, Darin Fisher wrote:
>> I've heard people proclaim the principle of being able to copy a profile
>> across systems as being a deciding factor for certain changes (e.g. the
>> history epoch change). However, it doesn't seem to be universally held or
>> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
>> questions:
>>
>> - Is "profile platform independence" a guiding principle?
>
> Yes, sort of.

I really like the idea of being able to move people between
operating systems and just bringing the profile along
without having to export and import...

(seems to me there are online services that offer that
convenience, but being able to do it with the raw file
is cool.)

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

[chromium-dev] Re: Copying of profiles across systems

[Stuart Morgan]

On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> - Is "profile platform independence" a guiding principle?
> [...]
> - Is it worth rewriting today's code that doesn't conform

It didn't seem to be when I asked about password storage a while back.
Passwords aren't even portable from machine to machine--and I would be
strongly opposed to making the password storage system platform
agnostic, since it would mean abandoning an important piece of OS
integration (including transparent password portability across
browsers) on the Mac.

That's not to say that we couldn't aim for making most of a profile
portable, but I would be sad if we made a hard-and-fast rule that
everything must be completely portable even at the cost of platform
integration.

-Stuart

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

[chromium-dev] Re: Copying of profiles across systems

[Avi Drissman]

Then password management would also fall under the category of "can't be
made portable" and that's fine.

It's just that I've heard "profile platform independence" tossed around as
being a guiding principle and I was surprised that some people treated it as
so.

Avi
/who wonders how it fits into
http://dev.chromium.org/developers/core-principles

On Wed, Aug 26, 2009 at 11:53 AM, Stuart Morgan
wrote:

> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> > - Is "profile platform independence" a guiding principle?
> > [...]
> > - Is it worth rewriting today's code that doesn't conform
>
> It didn't seem to be when I asked about password storage a while back.
> Passwords aren't even portable from machine to machine--and I would be
> strongly opposed to making the password storage system platform
> agnostic, since it would mean abandoning an important piece of OS
> integration (including transparent password portability across
> browsers) on the Mac.
>
> That's not to say that we couldn't aim for making most of a profile
> portable, but I would be sad if we made a hard-and-fast rule that
> everything must be completely portable even at the cost of platform
> integration.
>
> -Stuart
>

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

[chromium-dev] Re: Copying of profiles across systems

[Darin Fisher]

On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson  wrote:

>
> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> > I've heard people proclaim the principle of being able to copy a profile
> > across systems as being a deciding factor for certain changes (e.g. the
> > history epoch change). However, it doesn't seem to be universally held or
> > obeyed, and I'm not sure to the extent to which it can be obeyed. So some
> > questions:
> >
> > - Is "profile platform independence" a guiding principle?
> > - To what extent do we work to make it reality?
>
> I don't think this is a guiding principle. We should do it when it's
> reasonable. I think most places it is reasonable to do so.
>
> > - In the cases where it can't be kept (e.g. download folder path) should
> we
> > keep a copy for each platform?
>
> I don't think so.
>
> > - Is it worth rewriting today's code that doesn't conform (e.g.
> extensions
> > and themes which use full paths and platform path separators)?
>
> I don't think so, although I do wonder if full paths are necessary,
>

It was painful to remove all of the full paths from mozilla's profile.  It
was something people wanted because they wanted to be able to just copy
their profile from one computer to another.  Think of moving a profile from
WinXP to Vista where the path to your windows profile changes.

-darin



> even if we're not worried about platform portability (not knowing
> anything about what these are used for if there are any).
>
> Brett
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Dan Kegel]

On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
>> I really like the idea of being able to move people between
>> operating systems and just bringing the profile along
>> without having to export and import...
>>
>> (seems to me there are online services that offer that
>> convenience, but being able to do it with the raw file
>> is cool.)
>
> In what scenarios would this be useful?  If it's easy to do, it'd be cool,
> but it seems like this would have a very small minority of users.

When migrating users between operating systems.  Say,
a company decides to migrate all its office workers from
Windows to Linux.   Or if somebody installs Ubuntu on
a Windows machine on its own; I believe they try
to migrate settings when you do that.

One goal of Chrome was to make operating systems not matter;
one way to do that is to make the profile file (mostly) portable.
- Dan

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

[chromium-dev] Re: Copying of profiles across systems

[John Abd-El-Malek]

On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher  wrote:

> On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson wrote:
>
>>
>> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
>> > I've heard people proclaim the principle of being able to copy a profile
>> > across systems as being a deciding factor for certain changes (e.g. the
>> > history epoch change). However, it doesn't seem to be universally held
>> or
>> > obeyed, and I'm not sure to the extent to which it can be obeyed. So
>> some
>> > questions:
>> >
>> > - Is "profile platform independence" a guiding principle?
>> > - To what extent do we work to make it reality?
>>
>> I don't think this is a guiding principle. We should do it when it's
>> reasonable. I think most places it is reasonable to do so.
>>
>> > - In the cases where it can't be kept (e.g. download folder path) should
>> we
>> > keep a copy for each platform?
>>
>> I don't think so.
>>
>> > - Is it worth rewriting today's code that doesn't conform (e.g.
>> extensions
>> > and themes which use full paths and platform path separators)?
>>
>> I don't think so, although I do wonder if full paths are necessary,
>>
>
> It was painful to remove all of the full paths from mozilla's profile.  It
> was something people wanted because they wanted to be able to just copy
> their profile from one computer to another.  Think of moving a profile from
> WinXP to Vista where the path to your windows profile changes.
>

I think moving between different versions of the OS is a simpler and more
common problem than moving between different OSs.  I could come up with
convoluted scenarios about why I'd want to move my profile between different
OSs, but if it's not a common user request, then it's not worth the effort
IMO.


> -darin
>
>
>
>> even if we're not worried about platform portability (not knowing
>> anything about what these are used for if there are any).
>>
>> Brett
>>
>>
>>
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 12:48 PM, Dan Kegel  wrote:

>
> On Wed, Aug 26, 2009 at 12:28 PM, Darin Fisher wrote:
> >> I've heard people proclaim the principle of being able to copy a profile
> >> across systems as being a deciding factor for certain changes (e.g. the
> >> history epoch change). However, it doesn't seem to be universally held
> or
> >> obeyed, and I'm not sure to the extent to which it can be obeyed. So
> some
> >> questions:
> >>
> >> - Is "profile platform independence" a guiding principle?
> >
> > Yes, sort of.
>
> I really like the idea of being able to move people between
> operating systems and just bringing the profile along
> without having to export and import...
>
> (seems to me there are online services that offer that
> convenience, but being able to do it with the raw file
> is cool.)


In what scenarios would this be useful?  If it's easy to do, it'd be cool,
but it seems like this would have a very small minority of users.

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

[chromium-dev] Re: Copying of profiles across systems

[Michael Nordman]

Is the OS in the user-agent string?
"Mozilla/5.0 (*Windows*; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML,
like Gecko) Chrome/3.0.195.6 Safari/532.0"

There's a chance that http resource caches will contain data tweeked per OS.
Maybe for cosmetic purposes... to make it look more OSX'y or ChromeOS'y or
Windows'y... or perhaps for functional purposes like  plugin works
better on this and  plugin works better on that in some odd corner
case.


On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel  wrote:

>
> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
> >> I really like the idea of being able to move people between
> >> operating systems and just bringing the profile along
> >> without having to export and import...
> >>
> >> (seems to me there are online services that offer that
> >> convenience, but being able to do it with the raw file
> >> is cool.)
> >
> > In what scenarios would this be useful?  If it's easy to do, it'd be
> cool,
> > but it seems like this would have a very small minority of users.
>
> When migrating users between operating systems.  Say,
> a company decides to migrate all its office workers from
> Windows to Linux.   Or if somebody installs Ubuntu on
> a Windows machine on its own; I believe they try
> to migrate settings when you do that.
>
> One goal of Chrome was to make operating systems not matter;
> one way to do that is to make the profile file (mostly) portable.
> - Dan
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Ben Goodger (Google)]

BTW we have two separate prefs files, "Preferences" and "Local State"
to support this sort of thing in the pref system at least.

Whether or not people put the right settings in the right data stores
is another question.

-Ben

On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> I've heard people proclaim the principle of being able to copy a profile
> across systems as being a deciding factor for certain changes (e.g. the
> history epoch change). However, it doesn't seem to be universally held or
> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
> questions:
>
> - Is "profile platform independence" a guiding principle?
> - To what extent do we work to make it reality?
> - In the cases where it can't be kept (e.g. download folder path) should we
> keep a copy for each platform?
> - Is it worth rewriting today's code that doesn't conform (e.g. extensions
> and themes which use full paths and platform path separators)?
>
> Avi
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Tony Chang]

FWIW, I think this distinction is confusing without good use cases
backed by tests to enforce the two separate files.  I think we should
just merge them for now (which would simplify the code and be one less
file to read on startup) and re-split once we know what the use cases
are.

You could also imagine just having one file and having a json subtree
provide the distinction.

On Wed, Aug 26, 2009 at 1:11 PM, Ben Goodger (Google)  wrote:
>
> BTW we have two separate prefs files, "Preferences" and "Local State"
> to support this sort of thing in the pref system at least.
>
> Whether or not people put the right settings in the right data stores
> is another question.
>
> -Ben
>
> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
>> I've heard people proclaim the principle of being able to copy a profile
>> across systems as being a deciding factor for certain changes (e.g. the
>> history epoch change). However, it doesn't seem to be universally held or
>> obeyed, and I'm not sure to the extent to which it can be obeyed. So some
>> questions:
>>
>> - Is "profile platform independence" a guiding principle?
>> - To what extent do we work to make it reality?
>> - In the cases where it can't be kept (e.g. download folder path) should we
>> keep a copy for each platform?
>> - Is it worth rewriting today's code that doesn't conform (e.g. extensions
>> and themes which use full paths and platform path separators)?
>>
>> Avi
>>
>> >
>>
>
> >
>

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

[chromium-dev] Re: Formatting substrings in a views::Label

[Aaron Boodman]

Argh. Forgot attachment.



On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote:
> I'm playing with different ideas for the extension install dialog, and
> would like to do something like the attacked mock.
>
> I can see that there is no support for this in Label presently and I'm
> told by Dean that the APIs for doing this are different across
> platforms. Is it worth adding an abstraction to Label for this?
>
> - a
>

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

<>

[chromium-dev] Re: Copying of profiles across systems

[Avi Drissman]

On Wed, Aug 26, 2009 at 2:31 PM, Ben Goodger (Google) wrote:

> Note that even upgrading Windows OS from XP to Vista involves changing
> paths:
>
> c:\Documents and Settings -> c:\Users
>
> Do we ever write paths such as this?
>

Yes.

>From my Preferences file on Windows:

 "id": "bfjgbcjfpbbfepcccpaffkjofcmglifg",
>  "images": {
> "theme_button_background": "C:\\Documents and
> Settings\\avi\\Local Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2rMBDA",
> "theme_frame": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYk6wBDA",
> "theme_ntp_background": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYzZwBDA",
> "theme_toolbar": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2bMBDA"
>  },
>  "properties": {


This is from the themes section.

Avi

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

[chromium-dev] Re: Copying of profiles across systems

[John Abd-El-Malek]

On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel  wrote:

>
> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
> >> I really like the idea of being able to move people between
> >> operating systems and just bringing the profile along
> >> without having to export and import...
> >>
> >> (seems to me there are online services that offer that
> >> convenience, but being able to do it with the raw file
> >> is cool.)
> >
> > In what scenarios would this be useful?  If it's easy to do, it'd be
> cool,
> > but it seems like this would have a very small minority of users.
>
> When migrating users between operating systems.  Say,
> a company decides to migrate all its office workers from
> Windows to Linux.   Or if somebody installs Ubuntu on
> a Windows machine on its own; I believe they try
> to migrate settings when you do that.
>
> One goal of Chrome was to make operating systems not matter;
> one way to do that is to make the profile file (mostly) portable.
>



On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher  wrote:

> On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson 
>  wrote:
>
>>
>> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
>> > I've heard people proclaim the principle of being able to copy a profile
>> > across systems as being a deciding factor for certain changes (e.g. the
>> > history epoch change). However, it doesn't seem to be universally held
>> or
>> > obeyed, and I'm not sure to the extent to which it can be obeyed. So
>> some
>> > questions:
>> >
>> > - Is "profile platform independence" a guiding principle?
>> > - To what extent do we work to make it reality?
>>
>> I don't think this is a guiding principle. We should do it when it's
>> reasonable. I think most places it is reasonable to do so.
>>
>> > - In the cases where it can't be kept (e.g. download folder path) should
>> we
>> > keep a copy for each platform?
>>
>> I don't think so.
>>
>> > - Is it worth rewriting today's code that doesn't conform (e.g.
>> extensions
>> > and themes which use full paths and platform path separators)?
>>
>> I don't think so, although I do wonder if full paths are necessary,
>>
>
> It was painful to remove all of the full paths from mozilla's profile.  It
> was something people wanted because they wanted to be able to just copy
> their profile from one computer to another.  Think of moving a profile from
> WinXP to Vista where the path to your windows profile changes.
>

I think moving between different versions of the OS is a simpler and more
common problem than moving between different OSs.  I could come up with
convoluted scenarios about why I'd want to move my profile between different
OSs, but if it's not a common user request, then it's not worth the effort
IMO.

- Dan
>
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[Peter Kasting]

On Wed, Aug 26, 2009 at 2:37 PM, Avi Drissman  wrote:

> On Wed, Aug 26, 2009 at 2:31 PM, Ben Goodger (Google) 
> wrote:
>
>> Note that even upgrading Windows OS from XP to Vista involves changing
>> paths:
>>
>> c:\Documents and Settings -> c:\Users
>>
>> Do we ever write paths such as this?
>>
>
> Yes.
>
> From my Preferences file on Windows:
>
>  "id": "bfjgbcjfpbbfepcccpaffkjofcmglifg",
>>  "images": {
>> "theme_button_background": "C:\\Documents and
>> Settings\\avi\\Local Settings\\Application Data\\Chromium\\User
>> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2rMBDA",
>> "theme_frame": "C:\\Documents and Settings\\avi\\Local
>> Settings\\Application Data\\Chromium\\User
>> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYk6wBDA",
>> "theme_ntp_background": "C:\\Documents and
>> Settings\\avi\\Local Settings\\Application Data\\Chromium\\User
>> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYzZwBDA",
>> "theme_toolbar": "C:\\Documents and Settings\\avi\\Local
>> Settings\\Application Data\\Chromium\\User
>> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2bMBDA"
>>  },
>>  "properties": {
>
>
> This is from the themes section.
>

We should fix this to use relative paths.  Miranda, you want to take a look?

PK

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

[chromium-dev] Formatting substrings in a views::Label

[Aaron Boodman]

I'm playing with different ideas for the extension install dialog, and
would like to do something like the attacked mock.

I can see that there is no support for this in Label presently and I'm
told by Dean that the APIs for doing this are different across
platforms. Is it worth adding an abstraction to Label for this?

- a

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

[chromium-dev] Re: Copying of profiles across systems

[Michael Nordman]

+ chromium-dev (this time, sorry for the resend)
Is the OS in the user-agent string?
"Mozilla/5.0 (*Windows*; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML,
like Gecko) Chrome/3.0.195.6 Safari/532.0"

There's a chance that http resource caches will contain data tweeked per OS.
Maybe for cosmetic purposes... to make it look more OSX'y or ChromeOS'y or
Windows'y... or perhaps for functional purposes like  plugin works
better on this and  plugin works better on that in some odd corner
case.

On Wed, Aug 26, 2009 at 1:20 PM, Dan Kegel  wrote:
>
>>
>> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow
>> wrote:
>> >> I really like the idea of being able to move people between
>> >> operating systems and just bringing the profile along
>> >> without having to export and import...
>> >>
>> >> (seems to me there are online services that offer that
>> >> convenience, but being able to do it with the raw file
>> >> is cool.)
>> >
>> > In what scenarios would this be useful?  If it's easy to do, it'd be
>> cool,
>> > but it seems like this would have a very small minority of users.
>>
>> When migrating users between operating systems.  Say,
>> a company decides to migrate all its office workers from
>> Windows to Linux.   Or if somebody installs Ubuntu on
>> a Windows machine on its own; I believe they try
>> to migrate settings when you do that.
>>
>> One goal of Chrome was to make operating systems not matter;
>> one way to do that is to make the profile file (mostly) portable.
>> - Dan
>>
>> >>
>>
>

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

[chromium-dev] Copy/Paste suddenly not working?

[Andrew Herrgott]

Hello.

I'm using Chrome on Ubuntu Hardy.  Yesterday, my copy/paste
functionality seemed to disappear from Chrome.  I can copy/paste to
and from other applications.  I can also select text and drag it from
Chrome to textpad.

However, ctrl x / ctrl c / ctrl v and the right click menu cut/copy/
paste all seem to not be functioning.

Suggestions on how to troubleshoot?

Did a new version come out recently that may have triggered this
change?  I'm on v 4.0.202.2.


Many thanks,
Andrew

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

[chromium-dev] newbie question on ubuntu 8.04 : checking my directory and gclient sync is setup properly

[TC]

I am a newbie Chromium developer on ubuntu 8.04.
This is the first time I execute the "gclient sync" command.
Please check whether my directory and gclient sync is setup properly.
Thanks.
$ echo $CHROMIUM_ROOT
/home/tcma/chromium

$ gclient sync
...
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
parser.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
scopes.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
execution.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
execution.h
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
factory.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
global-handles.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
version.cc
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/
ChangeLog
U/home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/
SConstruct
 U   /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8
Updated to revision 2739.

 running '/usr/bin/python src/tools/gyp/gyp_chromium' in '/
home/tcma/chromium/home/chrome-svn/tarball/chromium'
Updating projects from gyp files...

 running '/usr/bin/python src/build/win/
clobber_generated_headers.py src/webkit/glue/devtools_strings.grd src/
webkit/glue/inspector_strings.grd src/webkit/glue/webkit_resources.grd
src/chrome/app/generated_resources.grd src/chrome/app/
google_chrome_strings.grd src/chrome/app/theme/theme_resources.grd src/
chrome/app/chromium_strings.grd src/chrome/browser/
browser_resources.grd src/chrome/renderer/renderer_resources.grd src/
chrome/common/common_resources.grd' in '/home/tcma/chromium/home/
chrome-svn/tarball/chromium'

WARNING: "src/third_party/WebKit/WebKitLibraries" is no longer part of
this client.  It is recommended that you manually remove it.


WARNING: "src/third_party/GTM" is no longer part of this client.  It
is recommended that you manually remove it.

...

WARNING: "src/third_party/python_24" is no longer part of this
client.  It is recommended that you manually remove it.


WARNING: "src/third_party/WebKit/WebKit/mac" is no longer part of this
client.  It is recommended that you manually remove it.

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

[chromium-dev] Re: Copy/Paste suddenly not working?

[Peter Kasting]

On Mon, Aug 24, 2009 at 4:48 PM, Andrew Herrgott wrote:

> I'm using Chrome on Ubuntu Hardy.  Yesterday, my copy/paste
> functionality seemed to disappear from Chrome.  I can copy/paste to
> and from other applications.  I can also select text and drag it from
> Chrome to textpad.
>
> However, ctrl x / ctrl c / ctrl v and the right click menu cut/copy/
> paste all seem to not be functioning.
>
> Suggestions on how to troubleshoot?
>
> Did a new version come out recently that may have triggered this
> change?  I'm on v 4.0.202.2.
>

You may be running into
http://code.google.com/p/chromium/issues/detail?id=19648 .

In the future, please search the bug database for things like "copy linux"
or other likely phrases.  You also should send messages like this to
chromium-discuss, not chromium-dev.

PK

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

[chromium-dev] Re: Copying of profiles across systems

[Ben Goodger (Google)]

Note that even upgrading Windows OS from XP to Vista involves changing paths:

c:\Documents and Settings -> c:\Users

Do we ever write paths such as this?

Local state should be data that can be thrown away without much loss
of user experience. Generally these things include window positions,
file system paths etc.

It is much more desirable to share personal data (the contents of my
NTP, omnibox, etc) across machines and OSes.

-Ben

On Wed, Aug 26, 2009 at 1:33 PM, John Abd-El-Malek wrote:
>
>
> On Wed, Aug 26, 2009 at 12:41 PM, Darin Fisher  wrote:
>>
>> On Wed, Aug 26, 2009 at 12:16 PM, Brett Wilson 
>> wrote:
>>>
>>> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
>>> > I've heard people proclaim the principle of being able to copy a
>>> > profile
>>> > across systems as being a deciding factor for certain changes (e.g. the
>>> > history epoch change). However, it doesn't seem to be universally held
>>> > or
>>> > obeyed, and I'm not sure to the extent to which it can be obeyed. So
>>> > some
>>> > questions:
>>> >
>>> > - Is "profile platform independence" a guiding principle?
>>> > - To what extent do we work to make it reality?
>>>
>>> I don't think this is a guiding principle. We should do it when it's
>>> reasonable. I think most places it is reasonable to do so.
>>>
>>> > - In the cases where it can't be kept (e.g. download folder path)
>>> > should we
>>> > keep a copy for each platform?
>>>
>>> I don't think so.
>>>
>>> > - Is it worth rewriting today's code that doesn't conform (e.g.
>>> > extensions
>>> > and themes which use full paths and platform path separators)?
>>>
>>> I don't think so, although I do wonder if full paths are necessary,
>>
>> It was painful to remove all of the full paths from mozilla's profile.  It
>> was something people wanted because they wanted to be able to just copy
>> their profile from one computer to another.  Think of moving a profile from
>> WinXP to Vista where the path to your windows profile changes.
>
> I think moving between different versions of the OS is a simpler and more
> common problem than moving between different OSs.  I could come up with
> convoluted scenarios about why I'd want to move my profile between different
> OSs, but if it's not a common user request, then it's not worth the effort
> IMO.
>>
>> -darin
>>
>>>
>>> even if we're not worried about platform portability (not knowing
>>> anything about what these are used for if there are any).
>>>
>>> Brett
>>>
>>>
>>
>>
>>
>
>
> >
>

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

[chromium-dev] Re: Formatting substrings in a views::Label

[Brett Wilson]

+finnur who did this for the about box.

Brett

On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote:
> Argh. Forgot attachment.
>
>
>
> On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote:
>> I'm playing with different ideas for the extension install dialog, and
>> would like to do something like the attacked mock.
>>
>> I can see that there is no support for this in Label presently and I'm
>> told by Dean that the APIs for doing this are different across
>> platforms. Is it worth adding an abstraction to Label for this?
>>
>> - a
>>
>
> >
>

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

[chromium-dev] Re: Subversion tags for stable/beta/dev?

[Aaron Boodman]

Checking up on this. I don't see the tags in src.chromium.org yet. Can
we get this going for the next dev release?

- a

On Tue, Aug 11, 2009 at 1:30 PM, Aaron Boodman wrote:
> Hooray, thanks Mark.
>
> - a
>
> On Tue, Aug 11, 2009 at 1:22 PM, Mark Larson (Google) 
> wrote:
>> Yes, I think we can add something so each channel has a persistent URL. I'll
>> discuss with Aaron offline.
>>
>> On Sat, Aug 8, 2009 at 00:17, Darin Fisher  wrote:
>>>
>>> On Fri, Aug 7, 2009 at 11:59 PM, Aaron Boodman  wrote:

 Ok, sorry I got defensive. Short answer is we don't know if it can
 handle the load. I will add a bug to myself to investigate.
>>>
>>> Oh, I didn't think you were overly defensive...
>>>

 Do you have any opinion on adding the tags? I guess the cost would be
 that when we do new releases the release manager would have to update
 the tag.
>>>
>>> It sounds like a reasonable request to me.
>>> -Darin
>>>

 - a

 On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisher wrote:
 > I totally agree.  Reducing the cost of maintaining docs is very nice
 > indeed
 > ;-)
 > -Darin
 >
 > On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman  wrote:
 >>
 >> We can put a cache in front of it if needed. Actually I'd like to put
 >> something dumb and simple in front of it anyway, so we could have
 >> shorter URLs that aren't tied to viewvc.
 >>
 >> But I think having the docs be checked in and not having a separate
 >> deploy step is worth some extra complexity on the frontend. In Gears
 >> the docs being out of date, or out of sync with the various versions
 >> was an annoying problem.
 >>
 >> - a
 >>
 >> On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisher
 >> wrote:
 >> > This is pretty cool, but my experience with ViewVC is that it is
 >> > kind of
 >> > slow.  Do we know if it can handle the additional load this will
 >> > generate?
 >> > -Darin
 >> >
 >> > On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman 
 >> > wrote:
 >> >>
 >> >> Hi all,
 >> >>
 >> >> I was wondering if the release managers could add a tag in
 >> >> Subversion
 >> >> for each of the stable, beta, and dev release channels. I want a
 >> >> ViewVC URL that I can give people that will always refer to the
 >> >> version of the code that is on stable (or whatever) at that moment.
 >> >>
 >> >> The reason I want to do this is because the extensions possee is
 >> >> checking our docs into source control, so that they can be viewed
 >> >> live
 >> >> from viewvc. They're still in progress, but you can see them
 >> >> starting
 >> >> to come together here:
 >> >>
 >> >>
 >> >>
 >> >> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html
 >> >>
 >> >> The cool thing about this approach is that when we branch releases,
 >> >> the docs from trunk will be branched too. So the docs for a certain
 >> >> release area always with the code for that release.
 >> >>
 >> >> If we had the aforementioned tags, the canonical URL for, eg, the
 >> >> stable extension docs could just be:
 >> >>
 >> >>
 >> >>
 >> >>
 >> >> http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html
 >> >>
 >> >> - a
 >> >>
 >> >> >> >>
 >> >
 >> >
 >
 >
>>>
>>>
>>> >>>
>>
>>
>

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

[chromium-dev] Re: newbie question on ubuntu 8.04 : checking my directory and gclient sync is setup properly

[Evan Martin]

Seems fine.  Have you ran into problems?

On Sun, Aug 23, 2009 at 4:36 AM, TC wrote:
>
> I am a newbie Chromium developer on ubuntu 8.04.
> This is the first time I execute the "gclient sync" command.
> Please check whether my directory and gclient sync is setup properly.
> Thanks.
> $ echo $CHROMIUM_ROOT
> /home/tcma/chromium
>
> $ gclient sync
> ...
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> parser.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> scopes.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> execution.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> execution.h
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> factory.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> global-handles.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/src/
> version.cc
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/
> ChangeLog
> U    /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8/
> SConstruct
>  U   /home/tcma/chromium/home/chrome-svn/tarball/chromium/src/v8
> Updated to revision 2739.
>
>  running '/usr/bin/python src/tools/gyp/gyp_chromium' in '/
> home/tcma/chromium/home/chrome-svn/tarball/chromium'
> Updating projects from gyp files...
>
>  running '/usr/bin/python src/build/win/
> clobber_generated_headers.py src/webkit/glue/devtools_strings.grd src/
> webkit/glue/inspector_strings.grd src/webkit/glue/webkit_resources.grd
> src/chrome/app/generated_resources.grd src/chrome/app/
> google_chrome_strings.grd src/chrome/app/theme/theme_resources.grd src/
> chrome/app/chromium_strings.grd src/chrome/browser/
> browser_resources.grd src/chrome/renderer/renderer_resources.grd src/
> chrome/common/common_resources.grd' in '/home/tcma/chromium/home/
> chrome-svn/tarball/chromium'
>
> WARNING: "src/third_party/WebKit/WebKitLibraries" is no longer part of
> this client.  It is recommended that you manually remove it.
>
>
> WARNING: "src/third_party/GTM" is no longer part of this client.  It
> is recommended that you manually remove it.
>
> ...
>
> WARNING: "src/third_party/python_24" is no longer part of this
> client.  It is recommended that you manually remove it.
>
>
> WARNING: "src/third_party/WebKit/WebKit/mac" is no longer part of this
> client.  It is recommended that you manually remove it.
>
> >
>

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

[chromium-dev] [Linux] tcmalloc && google-perftools profiling

[陈智昌]

I've checked in a change to enable tcmalloc on Linux via a gyp flag
(r24538).  If you set the gyp variable linux_use_tcmalloc to 1, it
will build the tcmalloc library (which includes the cpu profiler and
the heap profiler).  You can then generate cpu profiles and heap
profiles for Chromium on Linux and analyze them with the
google-perftools pprof script.  I've written up the basics of this at
http://code.google.com/p/chromium/wiki/LinuxProfiling.  For an example
of what a Chromium cpu profile looks like, take a look at
http://chromium.googlecode.com/issues/attachment?aid=8129389678904867605&name=cpuprofile.pdf
which shows the heavy cpu usage of our tabstrip code.

-Will

PS: I haven't enabled tcmalloc by default because the perf cycler
results didn't change substantially in the experiments I ran on the
buildbots.  The memory bot isn't working yet for Linux, so I'm also
concerned about an increase in memory usage, so I'm waiting for that
to be enabled before experimenting with this again.
PPS: google-perftools profiling only works on the browser process for
now, due to various issues that can be addressed (needing filesystem
access to write out the profiles [doesn't work with sandbox], profile
filename is specified in an environment variable, which is the same
value across browser/renderer processes, etc.).

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

[chromium-dev] Creating a SkBitmap filled with one color

[Paweł Hajdan Jr .]

How do I create a SkBitmap of arbitrary size, filled with color of my choice
(on Linux)?
I'd need that for Linux extension shelf, and the Windows code for that seems
not easily portable to Linux.

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Evan Stade]

Use cairo instead of Skia if you can avoid it in gtk code.

-- Evan Stade



On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
Jr. wrote:
> How do I create a SkBitmap of arbitrary size, filled with color of my choice
> (on Linux)?
> I'd need that for Linux extension shelf, and the Windows code for that seems
> not easily portable to Linux.
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Nico Weber]

When I talked with Aaron, he said porting the shelf to OS X isn't
something I should tackle unless I'm _really_ running out of things to
do, since they're not even sure they're going to keep it. Has this
changed, or is the situation different on linux for some reason?

Nico

On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
Jr. wrote:
> How do I create a SkBitmap of arbitrary size, filled with color of my choice
> (on Linux)?
> I'd need that for Linux extension shelf, and the Windows code for that seems
> not easily portable to Linux.
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Dean McNamee]

To answer the technical (non-political) part of this question.

Create a SkBitmap which backs to some pixels.  Create a SkCanvas on
top of it.  Call drawPaint or more directly drawColor.

On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber  wrote:
>
> When I talked with Aaron, he said porting the shelf to OS X isn't
> something I should tackle unless I'm _really_ running out of things to
> do, since they're not even sure they're going to keep it. Has this
> changed, or is the situation different on linux for some reason?
>
> Nico
>
> On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
> Jr. wrote:
>> How do I create a SkBitmap of arbitrary size, filled with color of my choice
>> (on Linux)?
>> I'd need that for Linux extension shelf, and the Windows code for that seems
>> not easily portable to Linux.
>> >
>>
>
> >
>

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

[chromium-dev] Re: Subversion tags for stable/beta/dev?

[Paweł Hajdan Jr .]

Seconded. Tags would make my work on packaging for Gentoo much easier.

On Wed, Aug 26, 2009 at 15:51, Aaron Boodman  wrote:

>
> Checking up on this. I don't see the tags in src.chromium.org yet. Can
> we get this going for the next dev release?
>
> - a
>
> On Tue, Aug 11, 2009 at 1:30 PM, Aaron Boodman wrote:
> > Hooray, thanks Mark.
> >
> > - a
> >
> > On Tue, Aug 11, 2009 at 1:22 PM, Mark Larson (Google)
> wrote:
> >> Yes, I think we can add something so each channel has a persistent URL.
> I'll
> >> discuss with Aaron offline.
> >>
> >> On Sat, Aug 8, 2009 at 00:17, Darin Fisher  wrote:
> >>>
> >>> On Fri, Aug 7, 2009 at 11:59 PM, Aaron Boodman 
> wrote:
> 
>  Ok, sorry I got defensive. Short answer is we don't know if it can
>  handle the load. I will add a bug to myself to investigate.
> >>>
> >>> Oh, I didn't think you were overly defensive...
> >>>
> 
>  Do you have any opinion on adding the tags? I guess the cost would be
>  that when we do new releases the release manager would have to update
>  the tag.
> >>>
> >>> It sounds like a reasonable request to me.
> >>> -Darin
> >>>
> 
>  - a
> 
>  On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisher
> wrote:
>  > I totally agree.  Reducing the cost of maintaining docs is very nice
>  > indeed
>  > ;-)
>  > -Darin
>  >
>  > On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman 
> wrote:
>  >>
>  >> We can put a cache in front of it if needed. Actually I'd like to
> put
>  >> something dumb and simple in front of it anyway, so we could have
>  >> shorter URLs that aren't tied to viewvc.
>  >>
>  >> But I think having the docs be checked in and not having a separate
>  >> deploy step is worth some extra complexity on the frontend. In
> Gears
>  >> the docs being out of date, or out of sync with the various
> versions
>  >> was an annoying problem.
>  >>
>  >> - a
>  >>
>  >> On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisher
>  >> wrote:
>  >> > This is pretty cool, but my experience with ViewVC is that it is
>  >> > kind of
>  >> > slow.  Do we know if it can handle the additional load this will
>  >> > generate?
>  >> > -Darin
>  >> >
>  >> > On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman 
>  >> > wrote:
>  >> >>
>  >> >> Hi all,
>  >> >>
>  >> >> I was wondering if the release managers could add a tag in
>  >> >> Subversion
>  >> >> for each of the stable, beta, and dev release channels. I want a
>  >> >> ViewVC URL that I can give people that will always refer to the
>  >> >> version of the code that is on stable (or whatever) at that
> moment.
>  >> >>
>  >> >> The reason I want to do this is because the extensions possee is
>  >> >> checking our docs into source control, so that they can be
> viewed
>  >> >> live
>  >> >> from viewvc. They're still in progress, but you can see them
>  >> >> starting
>  >> >> to come together here:
>  >> >>
>  >> >>
>  >> >>
>  >> >>
> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html
>  >> >>
>  >> >> The cool thing about this approach is that when we branch
> releases,
>  >> >> the docs from trunk will be branched too. So the docs for a
> certain
>  >> >> release area always with the code for that release.
>  >> >>
>  >> >> If we had the aforementioned tags, the canonical URL for, eg,
> the
>  >> >> stable extension docs could just be:
>  >> >>
>  >> >>
>  >> >>
>  >> >>
>  >> >>
> http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html
>  >> >>
>  >> >> - a
>  >> >>
>  >> >> >> >>
>  >> >
>  >> >
>  >
>  >
> >>>
> >>>
> >>> >>>
> >>
> >>
> >
>
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Erik Kay]

On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber wrote:
>
> When I talked with Aaron, he said porting the shelf to OS X isn't
> something I should tackle unless I'm _really_ running out of things to
> do, since they're not even sure they're going to keep it. Has this
> changed, or is the situation different on linux for some reason?

Yes, extension UI is in a fair amount of flux, so some of this isn't
really worth diving into.  However, there are pieces of that work that
are relatively safe to bite off (which Pawel has mostly done for
Linux):
- ExtensionView - a way to display a RenderViewHost outside of a
TabContents in Chrome's UI
- a basic implementation of ExtensionShelf (essentially just drawing a
list of ExtensionViews based on an order specified by the
ExtensionShelfModel).  This is mostly just so you have a place to test
and use your ExtensionView.

Anything more than that (grab handles, dragging, moles, etc.) I'd
advise against.

Erik


>
> Nico
>
> On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
> Jr. wrote:
>> How do I create a SkBitmap of arbitrary size, filled with color of my choice
>> (on Linux)?
>> I'd need that for Linux extension shelf, and the Windows code for that seems
>> not easily portable to Linux.
>> >
>>
>
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Paweł Hajdan Jr .]

Thanks for all the answers, especially the first one from erg. I'm going to
use Skia, because another method (SetBackground in RWHV) requires that.

On Wed, Aug 26, 2009 at 16:33, Tony Chang  wrote:

> There's an example of how to do this with skia in
> src/app/resource_bundle.cc around line 146.  That said, you should use
> cairo to paint in GTK.
>
> On Wed, Aug 26, 2009 at 4:27 PM, Dean McNamee  wrote:
> >
> > To answer the technical (non-political) part of this question.
> >
> > Create a SkBitmap which backs to some pixels.  Create a SkCanvas on
> > top of it.  Call drawPaint or more directly drawColor.
> >
> > On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber  wrote:
> >>
> >> When I talked with Aaron, he said porting the shelf to OS X isn't
> >> something I should tackle unless I'm _really_ running out of things to
> >> do, since they're not even sure they're going to keep it. Has this
> >> changed, or is the situation different on linux for some reason?
> >>
> >> Nico
> >>
> >> On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
> >> Jr. wrote:
> >>> How do I create a SkBitmap of arbitrary size, filled with color of my
> choice
> >>> (on Linux)?
> >>> I'd need that for Linux extension shelf, and the Windows code for that
> seems
> >>> not easily portable to Linux.
> >>> >
> >>>
> >>
> >> >
> >>
> >
> > > >
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Adam Langley]

On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
Jr. wrote:
> How do I create a SkBitmap of arbitrary size, filled with color of my choice
> (on Linux)?

Without any testing at all, it would look a little like

SkBitmap bitmap;
bitmap.setConfig(SkBitmap::kARGB__Config, width, height);
bitmap.allocPixels();
SkCanvas canvas(bitmap);
SkPaint paint;
paint.setARGB(a, r, g, b);
paint.setStyle(SkPaint::kFill_Style);
SkIRect rect;
rect.set(left, top, right, bottom);
canvas.drawIRect(rect, paint);


AGL

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Elliot Glaysher (Chromium)]

See what I do in GtkThemeProvider::LoadThemeBitmap:

SkBitmap* bitmap = new SkBitmap;
bitmap->setConfig(SkBitmap::kARGB__Config,
  kToolbarImageWidth, kToolbarImageHeight);
bitmap->allocPixels();
bitmap->eraseRGB(color->red >> 8, color->green >> 8, color->blue >> 8);
return bitmap;

-- Elliot

On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
Jr. wrote:
> How do I create a SkBitmap of arbitrary size, filled with color of my choice
> (on Linux)?
> I'd need that for Linux extension shelf, and the Windows code for that seems
> not easily portable to Linux.
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Dean McNamee]

On Wed, Aug 26, 2009 at 4:14 PM, Elliot Glaysher (Chromium)
 wrote:
>
> See what I do in GtkThemeProvider::LoadThemeBitmap:
>
>    SkBitmap* bitmap = new SkBitmap;
>    bitmap->setConfig(SkBitmap::kARGB__Config,
>                      kToolbarImageWidth, kToolbarImageHeight);
>    bitmap->allocPixels();
>    bitmap->eraseRGB(color->red >> 8, color->green >> 8, color->blue >> 8);

This code is incorrect, you should divide by 257, not 256.  See the
GDK_COLOR_RGB macro.

>    return bitmap;
>
> -- Elliot
>
> On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
> Jr. wrote:
>> How do I create a SkBitmap of arbitrary size, filled with color of my choice
>> (on Linux)?
>> I'd need that for Linux extension shelf, and the Windows code for that seems
>> not easily portable to Linux.
>> >
>>
>
> >
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Tony Chang]

There's an example of how to do this with skia in
src/app/resource_bundle.cc around line 146.  That said, you should use
cairo to paint in GTK.

On Wed, Aug 26, 2009 at 4:27 PM, Dean McNamee  wrote:
>
> To answer the technical (non-political) part of this question.
>
> Create a SkBitmap which backs to some pixels.  Create a SkCanvas on
> top of it.  Call drawPaint or more directly drawColor.
>
> On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber  wrote:
>>
>> When I talked with Aaron, he said porting the shelf to OS X isn't
>> something I should tackle unless I'm _really_ running out of things to
>> do, since they're not even sure they're going to keep it. Has this
>> changed, or is the situation different on linux for some reason?
>>
>> Nico
>>
>> On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan
>> Jr. wrote:
>>> How do I create a SkBitmap of arbitrary size, filled with color of my choice
>>> (on Linux)?
>>> I'd need that for Linux extension shelf, and the Windows code for that seems
>>> not easily portable to Linux.
>>> >
>>>
>>
>> >
>>
>
> >
>

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

[chromium-dev] Re: layout test dashboard

[Ojan Vafai]

One final update.

   1. The bogus results on windows are gone.
   2. BUG*** now actually links to the bug.
   3. Hides WONTFIX tests by default, with a checkbox to show them.
   4. Linux release bot is now listed (debug coming soon)
   5. The dashboard now shows (highlights in blue) all cases where a test
   either has expectations that never happen or doesn't have expectations that
   do happen (see the 'extra' and 'missing' columns).

The only work I still plan to do on it is to make it perform a bit better.
Please file bugs if there are other additions that would be useful to you.

Ojan

On Tue, Aug 25, 2009 at 10:15 AM, Ojan Vafai  wrote:

> One more thing (since people are asking), you can see all the platforms'
> expectations for a test from the view for any builder. The ones that don't
> apply to this builder are greyed out. For example, see
> LayoutTests/fast/dom/HTMLObjectElement/object-as-frame.html on the "WebKit"
> builder.
> Ojan
>
> On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai  ium.org> wrote:
>
>> A first version of the layout test flakiness dashboard is up.
>>
>> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
>>
>> Some of the key features:
>>
>>- updates roughly as quickly as the bots have run the tests (no
>>post-processing, stdio parsing or crons)
>>- sortable by any column include "flakiness"
>>- builder + sort order permalinks (i.e. you can copy-paste URLs for a
>>given builder + sort order)
>>- highlights tests with missing expectations (i.e. the test passed,
>>but is marked only as failing)
>>- prints out test run times for tests that took > 1 second
>>- shows the expectations for a test on all platforms
>>
>> Taking a look at the dashboard, you can immediately see a couple things:
>>
>>1. A bunch of cases where we currently have the missing expectations
>>for a test. For example, LayoutTests/accessibility/plugin.html fails on
>>Windows, but is only listed as failing on the Mac.
>>2. We have a few dozen very slow tests that considerably slow down how
>>long the tests take to run.
>>
>> How do you get this awesomeness for UI tests, unittests, etc? It's
>> actually *really* easy. Someone just needs to add something to the test
>> runners for those test types that spits out JSON files in the right format
>> and copies them to the appropriate place. Let me know if you're interested
>> in adding support for a new test type.
>>
>> Known issues:
>>
>>1. The JS that generates the page could stand to be faster.
>>2. The windows builders have a bunch of junk entries with windows
>>style paths. Ignore them for now, they'll gradually fall off the end of 
>> the
>>tests tracked by the dashboard. Only the tests with unix style paths 
>> should
>>be looked at.
>>
>> If you have bugs or feature requests. Please file them at crbug.com and
>> CC me. One feature request that I have is to also highlight cases where we
>> list an expectation for a test that never happens (e.g. the test is listed
>> as "PASS CRASH FAIL", but has never crashed.
>>
>> Ojan
>>
>
>

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Nico Weber]

> This code is incorrect, you should divide by 257, not 256.  See the
> GDK_COLOR_RGB macro.

That's not true. GDK_COLOR_RGB multiplies by 257 (= 0x10001) to
distribute the bits evenly (
http://www.mindcontrol.org/~hplus/graphics/expand-bits.html ). To get
back, you can just shift (or, formulated differently, i == (i*257)/256
for all i < 256).

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

[chromium-dev] Re: Creating a SkBitmap filled with one color

[Dean McNamee]

Yes, this can be reformulated easier as

i * 257 = i * 256 + i

and i / 256 will always be zero for i < 256.  Anyway, I suppose it
doesn't matter.  The question is what to do for mapping 16-bit back to
8-bit, when it wasn't necessarily originally produced from 8-bit.  I
suppose that dividing by 256 is the right thing to do, sorry about
that.  It just seemed strange to not do the inverse, but yeah, you're
right...

On Wed, Aug 26, 2009 at 5:21 PM, Nico Weber  wrote:
>> This code is incorrect, you should divide by 257, not 256.  See the
>> GDK_COLOR_RGB macro.
>
> That's not true. GDK_COLOR_RGB multiplies by 257 (= 0x10001) to
> distribute the bits evenly (
> http://www.mindcontrol.org/~hplus/graphics/expand-bits.html ). To get
> back, you can just shift (or, formulated differently, i == (i*257)/256
> for all i < 256).
>

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

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

[Nick Baum]

Making these dialogs tab-modal is a great improvement, and very Chrome-y!
Thanks for helping with that.
Let me take a stab at answering your questions. Ben and Glen, chime in if
you disagree.
-Nick

On Fri, Aug 21, 2009 at 10:03 AM, Viet-Trung Luu wrote:

>
> Having played with my proof-of-concept for tab-modal file selection
> (etc.) sheets (CL: ), I think
> it's time for a draft design document. I'd especially appreciate
> feedback from the UI people. Here goes
>
> Definitions:
> A tab-specific dialog box or sheet ("dialog" for short) is a dialog
> which is entirely restricted to a single tab and does not impair the
> function of other tabs. In particular, one can still select or create
> other tabs, and browse "normally" in them. We actually need to
> distinguish between two types of tab-specific dialogs (justification
> below):
> (1) Explicitly user-activated dialogs, such as open/save/print; call
> these (fully) tab-modal dialogs.
> (2) Dialogs caused by content, such as download (carpet-bombing)
> blocking/http auth login; call these content-modal dialogs.
>
> Justification for distinction:
> Since in case (2) the user did not explicitly choose to have the dialog
> displayed, the user should be able to get rid of it easily, e.g., by
> navigating away or by closing the tab. A risk of not allowing these
> things (navigation or tab closure) while a content-modal dialog is up is
> that a site with nasty contents might be able to constantly cause such
> dialogs to appear, without the user being able to get away from that
> site. In case (1), the user specifically wanted the dialog, and
> shouldn't be able to accidentally navigate away or change the contents
> of the tab under the dialog.


I understand the distinction, but I'm not sure we want to prevent the user
from closing the tab in either case. We try very hard to not prevent the
user from closing things when they want to (see Recently Closed behavior).

What are the cases where we currently prevent a tab from being closed?

>
>
> Differences in behaviour between (1) and (2):
> (1) A tab-modal dialog impairs all function in its tab until it is
> dismissed. In particular, navigation should be disabled. For example,
> one should not be able to use a bookmark to change the page contents
> while a save or print dialog is up. To indicate that things are
> disabled, the tool/bookmark-bar should appear fully disabled.
> (2) A content-modal dialog impairs only interaction with the web
> contents in the tab until it is dismissed (implicit is that it impairs
> saving and printing of the contents of that tab). It can be dismissed by
> navigating to another page, by closing the tab, or in the usual way
> (OK/Cancel/whatever).
> We want to play down the differences. The behaviour of either should be
> obvious to the user, and what the user wants and expects.
>
> UI issues/questions:
> (a) When a tab-modal dialog is up, should the Page menu still be active?
> (Probably not.) The Wrench menu? (Well, it's in the toolbar, so no. But,
> on Windows and Linux, you don't have a global application menu bar, so
> yes? I've gone with "no" on Mac. Note that if the answer is "yes" for
> the Page menu, then most of its contents would have to be disabled!)


I think both should be active, and things that don't make sense should be
disabled.

>
> (b) Should a tab-modal (e.g., open/save/print) dialog impair tab
> closure? Since the user chose to do something, probably yes. A different
> answer would be "no" for open, but "yes" for save/print -- but this adds
> complication and breaks consistency.


No (see above)

>
> (c) If "yes" for (b), how should this be indicated to the user? What
> should happen to the tab-close button (on each tab)? Maybe instead of a
> normal hover highlight, the tab-close button should get a red highlight
> or something like that?
> (d) If "yes" for (b), what should the behaviour be upon attempted window
> closure? We could disable it completely (ugh -- too mysterious). Better,
> perhaps just select a tab with a tab-modal dialog showing? Which one if
> there are more than one? By z-order (i.e., selected first, then
> left-to-right)? Should it do so before closing any tabs (including the
> ones which can be closed), or should it close some/all of the tabs which
> can be closed?
> (e) (Mac) Where should a tab-modal sheet hang from? The bottom of the
> tool/bookmark-bar? This is aesthetically right, and should be okay since
> we visually indicate that the toolbar is disabled. [N.B. Not yet
> implemented.]


I'd say from the bottom of the tool/bookmark bar. Note that I don't think
the toolbar should be disabled in this case, you can still use
forward/back/reload/omnibox.

>
>
> Probably, there were other things, but I don't remember right now.
>
> - Trung
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options

[chromium-dev] Re: layout test dashboard

[Peter Kasting]

On Wed, Aug 26, 2009 at 5:12 PM, Ojan Vafai  wrote:

> The only work I still plan to do on it is to make it perform a bit better.
> Please file bugs if there are other additions that would be useful to you.
>

This is super-minor, but it might be nice to indicate, for the "flakiness"
column, that the reading order is "newer -> older".

PK

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

[chromium-dev] Re: Formatting substrings in a views::Label

[Finnur Thorarinsson]

Yes, the views class Link is a specialization of the class Label, and it is
responsible for handling hyperlinks.

On Wed, Aug 26, 2009 at 15:32, Brett Wilson  wrote:

> +finnur who did this for the about box.
>
> Brett
>
> On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote:
> > Argh. Forgot attachment.
> >
> >
> >
> > On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote:
> >> I'm playing with different ideas for the extension install dialog, and
> >> would like to do something like the attacked mock.
> >>
> >> I can see that there is no support for this in Label presently and I'm
> >> told by Dean that the APIs for doing this are different across
> >> platforms. Is it worth adding an abstraction to Label for this?
> >>
> >> - a
> >>
> >
> > > >
> >
>

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

[chromium-dev] Re: Copying of profiles across systems

[PhistucK]

Bearing the upcoming Chrome OS in mind, this should be taken into account
quite strongly.Regular programs will probably not move cleanly and nicely
from Windows to Chrome OS, but, at least, Google products should migrate
seamlessly, without any data loss (and passwords are a very important part,
too), in my opinion.

Having a specific export option for passwords only (only during the
transition, only when the profile is not used anymore in the former OS),
even unencrypted and then re-encrypt them when Chrome on the new OS finds an
old profile from another platform - could be some sort of a solution.

☆PhistucK


On Wed, Aug 26, 2009 at 23:20, Dan Kegel  wrote:

>
> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
> >> I really like the idea of being able to move people between
> >> operating systems and just bringing the profile along
> >> without having to export and import...
> >>
> >> (seems to me there are online services that offer that
> >> convenience, but being able to do it with the raw file
> >> is cool.)
> >
> > In what scenarios would this be useful?  If it's easy to do, it'd be
> cool,
> > but it seems like this would have a very small minority of users.
>
> When migrating users between operating systems.  Say,
> a company decides to migrate all its office workers from
> Windows to Linux.   Or if somebody installs Ubuntu on
> a Windows machine on its own; I believe they try
> to migrate settings when you do that.
>
> One goal of Chrome was to make operating systems not matter;
> one way to do that is to make the profile file (mostly) portable.
> - Dan
>
> >
>

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

[chromium-dev] Loading problems chromium on mac os x

[n179911]

Hi,

I have download the source of chromium and compile it on mac osx.
After I build it, I load sites like 'www.cnn.com', 'www.nytimes.com',
it starts loading but it never finishes. I eventually get this
'The following pages have become unresponsive. You can wait for them
to become responsive or kill them'.

But when I load 'www.google.com' or 'news.google.com', they both work fine.
I have been gclient sync the last couple of days, but I see the same problem.

Does anyone here see the same problem?
Thank you.

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

[chromium-dev] Re: Loading problems chromium on mac os x

[Amanda Walker]

If you are running Chromium from inside Xcode, make sure that you turn
off the "Stop on Debugger()/DebugStr()" option in the Run menu.  The
Flash plugin makes a call to Debugger() when it starts up--normally
this is harmless, but if you are running from Xcode instead of the
Finder, it will cause pages with Flash content to stop responding
unless you turn off that option.

--Amanda

On Wed, Aug 26, 2009 at 9:21 PM, n179911 wrote:
>
> Hi,
>
> I have download the source of chromium and compile it on mac osx.
> After I build it, I load sites like 'www.cnn.com', 'www.nytimes.com',
> it starts loading but it never finishes. I eventually get this
> 'The following pages have become unresponsive. You can wait for them
> to become responsive or kill them'.
>
> But when I load 'www.google.com' or 'news.google.com', they both work fine.
> I have been gclient sync the last couple of days, but I see the same problem.
>
> Does anyone here see the same problem?
> Thank you.
>
> >
>



-- 
"Portability is generally the result of advance planning rather than trench
warfare involving #ifdef" -- Henry Spencer (1992)

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

[chromium-dev] Git woes

[Nico Weber]

Trying to pull:

thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
remote: Counting objects: 1859, done.
remote: Compressing objects: 100% (1267/1267), done.
remote: Total 1393 (delta 1087), reused 195 (delta 107)
Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
fatal: cannot pread pack file: No such file or directory
fatal: index-pack failed

Ideas? The interwebs suggest deleting some file from my .git folder
that's not in there.

Nico

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

[chromium-dev] Re: Git woes

[Jeremy Moskovich]

Git is comprised of billions of tiny orthogonal binaries.
When this happened to me the cause was some old git binaries in the path
that where being called by others, the version mismatch was silent and
caused this error.

Have you upgraded to a new version of git recently that might cause such a
mismatch?

Best regards,
Jeremy

On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber  wrote:

>
> Trying to pull:
>
> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
> remote: Counting objects: 1859, done.
> remote: Compressing objects: 100% (1267/1267), done.
> remote: Total 1393 (delta 1087), reused 195 (delta 107)
> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
> fatal: cannot pread pack file: No such file or directory
> fatal: index-pack failed
>
> Ideas? The interwebs suggest deleting some file from my .git folder
> that's not in there.
>
> Nico
>
> >
>

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

[chromium-dev] Re: Formatting substrings in a views::Label

[Tim Steele]

fwiw, another way to write a dialog like this platform independently without
an extra abstraction for Label would be to use our html UI; that's what I
did for the sync setup dialog/wizard flow, and so far so good!

On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman  wrote:

>
> I'm playing with different ideas for the extension install dialog, and
> would like to do something like the attacked mock.
>
> I can see that there is no support for this in Label presently and I'm
> told by Dean that the APIs for doing this are different across
> platforms. Is it worth adding an abstraction to Label for this?
>
> - a
>
> >
>

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

[chromium-dev] The webkit canary bots, now with performance tests!

[Darin Fisher]

Thanks to bevc and nsylvain, we now have performance bots testing chromium
with the very latest webkit code:
http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=XP+Perf+(webkit.org)&builder=Linux+Perf+(webkit.org)&reload=none
(no mac bot yet)

The dashboard is here:
http://build.chromium.org/buildbot/perf/dashboard/overview-canary.html

Now, we can see with much finer granularity the impact of webkit changes on
the chromium performance tests!  No more guessing as to what will happen to
performance when we roll deps ;-)  Marvelous!

-Darin

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

[chromium-dev] Re: Git woes

[Nico Weber]

Not knowingly, at least. `git --version` says 1.6.0.2, which I believe
is what it always said.

On Wed, Aug 26, 2009 at 10:50 PM, Jeremy Moskovich wrote:
> Git is comprised of billions of tiny orthogonal binaries.
> When this happened to me the cause was some old git binaries in the path
> that where being called by others, the version mismatch was silent and
> caused this error.
> Have you upgraded to a new version of git recently that might cause such a
> mismatch?
> Best regards,
> Jeremy
>
> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber  wrote:
>>
>> Trying to pull:
>>
>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>> remote: Counting objects: 1859, done.
>> remote: Compressing objects: 100% (1267/1267), done.
>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> Ideas? The interwebs suggest deleting some file from my .git folder
>> that's not in there.
>>
>> Nico
>>
>> >>
>
>

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

[chromium-dev] Re: The webkit canary bots, now with performance tests!

[Adam Barth]

Yay!  This is fantastic!

Adam


On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisher wrote:
> Thanks to bevc and nsylvain, we now have performance bots testing chromium
> with the very latest webkit code:
> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=XP+Perf+(webkit.org)&builder=Linux+Perf+(webkit.org)&reload=none
> (no mac bot yet)
> The dashboard is here:
> http://build.chromium.org/buildbot/perf/dashboard/overview-canary.html
> Now, we can see with much finer granularity the impact of webkit changes on
> the chromium performance tests!  No more guessing as to what will happen to
> performance when we roll deps ;-)  Marvelous!
> -Darin
> >
>

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