[chromium-dev] GYP is great

[Adam Barth]

I know there has been some amount of pain transitioning over to GYP,
but I, for one, really appreciate it.  I've been wanting to reorganize
some of the SSL UI code for a while now but I've been scared of
screwing up the Mac and Linux builds.  GYP lets me hack without
breaking other build systems.

Thanks,
Adam

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Darin Fisher]

I mean.. there's a registry setting or something that can be set to disable
it.-darin

On Wed, May 13, 2009 at 8:40 PM, Darin Fisher  wrote:

> FYI:  Don't use GetShortPathName.  It isn't supported on some Windows
> systems.  We had a significant number of users that could not use Firefox
> until we stopped using it.
> -Darin
>
>
> On Wed, May 13, 2009 at 7:29 PM, Brett Wilson  wrote:
>
>>
>> On Wed, May 13, 2009 at 7:24 PM, Brett Wilson 
>> wrote:
>> > On Wed, May 13, 2009 at 6:12 PM, Greg Spencer 
>> wrote:
>> >> On Wed, May 13, 2009 at 4:07 PM, Brett Wilson 
>> wrote:
>> >>>
>> >>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker 
>> >>> wrote:
>> >>> >
>> >>> > Perhaps what we need is a companion to FilePath.  For example:
>> >>> >
>> >>> > FilePath: much as it is now, lightweight, "alternative to string
>> >>> > manipulation".
>> >>> > FileReference: heavierweight, can talk to the file system and have
>> >>> > carnal knowledge of platform specifics for things like resolving /
>> >>> > canonicalizing pathnames, determining whether or not they refer to
>> the
>> >>> > same files, generating C strings that can be passed to 3rd party
>> >>> > libraries, etc.
>> >>>
>> >>> I think this is very dangerous.
>> >>>
>> >>> I think Greg should not be talking to the filesystem when inserting
>> >>> filenames into a set. We don't allow filesystem access from the UI
>> >>> thread of Chrome, and I think other parts of our system should also
>> >>> not do filesystem access on their critical threads, especially if they
>> >>> want to be more part of Chrome in the future.
>> >>
>> >> Well, so the use I have for this in O3D at the moment is in our
>> importer,
>> >> which currently is a separate command-line tool that reads Collada
>> files and
>> >> writes out our wire format for geometry.  So it isn't meant to be
>> occuring
>> >> in a UI thread, but I could see times when it might be useful to know
>> for
>> >> sure if two files reference the same file in the UI thread (dragging
>> and
>> >> dropping a file onto a drop zone, for instance).
>> >> I do need to know if I have the same file more than once in a set
>> because
>> >> the COLLADA file might reference the same texture multiple times, or
>> (more
>> >> dangerous) it might reference a file that is one file on Windows,
>> >> but (incorrectly) maps to two different files in the (Unix-path-format)
>> .tgz
>> >> files.  To detect that, I need canonicalization.
>> >
>> > You can't actually canonicalize a filename on Windows, so I think it's
>> > dangerous to write a component that claims to do it.
>>
>> I guess you could call GetShortPathName every time you see a name. But
>> I think that's a crazy solution. I still think you should do my
>> suggestion below.
>>
>>
>> > I think you just need to come up with some simple rules that makes it
>> > work most of the time. Personally I would do ASCII lowercasing and
>> > stop worrying about it. If you use ICU to lower-case "correctly,"
>> > Windows won't necessarily agree and you won't be able to use that
>> > file.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Darin Fisher]

FYI:  Don't use GetShortPathName.  It isn't supported on some Windows
systems.  We had a significant number of users that could not use Firefox
until we stopped using it.
-Darin


On Wed, May 13, 2009 at 7:29 PM, Brett Wilson  wrote:

>
> On Wed, May 13, 2009 at 7:24 PM, Brett Wilson  wrote:
> > On Wed, May 13, 2009 at 6:12 PM, Greg Spencer 
> wrote:
> >> On Wed, May 13, 2009 at 4:07 PM, Brett Wilson 
> wrote:
> >>>
> >>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker 
> >>> wrote:
> >>> >
> >>> > Perhaps what we need is a companion to FilePath.  For example:
> >>> >
> >>> > FilePath: much as it is now, lightweight, "alternative to string
> >>> > manipulation".
> >>> > FileReference: heavierweight, can talk to the file system and have
> >>> > carnal knowledge of platform specifics for things like resolving /
> >>> > canonicalizing pathnames, determining whether or not they refer to
> the
> >>> > same files, generating C strings that can be passed to 3rd party
> >>> > libraries, etc.
> >>>
> >>> I think this is very dangerous.
> >>>
> >>> I think Greg should not be talking to the filesystem when inserting
> >>> filenames into a set. We don't allow filesystem access from the UI
> >>> thread of Chrome, and I think other parts of our system should also
> >>> not do filesystem access on their critical threads, especially if they
> >>> want to be more part of Chrome in the future.
> >>
> >> Well, so the use I have for this in O3D at the moment is in our
> importer,
> >> which currently is a separate command-line tool that reads Collada files
> and
> >> writes out our wire format for geometry.  So it isn't meant to be
> occuring
> >> in a UI thread, but I could see times when it might be useful to know
> for
> >> sure if two files reference the same file in the UI thread (dragging and
> >> dropping a file onto a drop zone, for instance).
> >> I do need to know if I have the same file more than once in a set
> because
> >> the COLLADA file might reference the same texture multiple times, or
> (more
> >> dangerous) it might reference a file that is one file on Windows,
> >> but (incorrectly) maps to two different files in the (Unix-path-format)
> .tgz
> >> files.  To detect that, I need canonicalization.
> >
> > You can't actually canonicalize a filename on Windows, so I think it's
> > dangerous to write a component that claims to do it.
>
> I guess you could call GetShortPathName every time you see a name. But
> I think that's a crazy solution. I still think you should do my
> suggestion below.
>
>
> > I think you just need to come up with some simple rules that makes it
> > work most of the time. Personally I would do ASCII lowercasing and
> > stop worrying about it. If you use ICU to lower-case "correctly,"
> > Windows won't necessarily agree and you won't be able to use that
> > file.
>
> >
>

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Brett Wilson]

On Wed, May 13, 2009 at 7:24 PM, Brett Wilson  wrote:
> On Wed, May 13, 2009 at 6:12 PM, Greg Spencer  wrote:
>> On Wed, May 13, 2009 at 4:07 PM, Brett Wilson  wrote:
>>>
>>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker 
>>> wrote:
>>> >
>>> > Perhaps what we need is a companion to FilePath.  For example:
>>> >
>>> > FilePath: much as it is now, lightweight, "alternative to string
>>> > manipulation".
>>> > FileReference: heavierweight, can talk to the file system and have
>>> > carnal knowledge of platform specifics for things like resolving /
>>> > canonicalizing pathnames, determining whether or not they refer to the
>>> > same files, generating C strings that can be passed to 3rd party
>>> > libraries, etc.
>>>
>>> I think this is very dangerous.
>>>
>>> I think Greg should not be talking to the filesystem when inserting
>>> filenames into a set. We don't allow filesystem access from the UI
>>> thread of Chrome, and I think other parts of our system should also
>>> not do filesystem access on their critical threads, especially if they
>>> want to be more part of Chrome in the future.
>>
>> Well, so the use I have for this in O3D at the moment is in our importer,
>> which currently is a separate command-line tool that reads Collada files and
>> writes out our wire format for geometry.  So it isn't meant to be occuring
>> in a UI thread, but I could see times when it might be useful to know for
>> sure if two files reference the same file in the UI thread (dragging and
>> dropping a file onto a drop zone, for instance).
>> I do need to know if I have the same file more than once in a set because
>> the COLLADA file might reference the same texture multiple times, or (more
>> dangerous) it might reference a file that is one file on Windows,
>> but (incorrectly) maps to two different files in the (Unix-path-format) .tgz
>> files.  To detect that, I need canonicalization.
>
> You can't actually canonicalize a filename on Windows, so I think it's
> dangerous to write a component that claims to do it.

I guess you could call GetShortPathName every time you see a name. But
I think that's a crazy solution. I still think you should do my
suggestion below.


> I think you just need to come up with some simple rules that makes it
> work most of the time. Personally I would do ASCII lowercasing and
> stop worrying about it. If you use ICU to lower-case "correctly,"
> Windows won't necessarily agree and you won't be able to use that
> file.

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Brett Wilson]

On Wed, May 13, 2009 at 6:12 PM, Greg Spencer  wrote:
> On Wed, May 13, 2009 at 4:07 PM, Brett Wilson  wrote:
>>
>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker 
>> wrote:
>> >
>> > Perhaps what we need is a companion to FilePath.  For example:
>> >
>> > FilePath: much as it is now, lightweight, "alternative to string
>> > manipulation".
>> > FileReference: heavierweight, can talk to the file system and have
>> > carnal knowledge of platform specifics for things like resolving /
>> > canonicalizing pathnames, determining whether or not they refer to the
>> > same files, generating C strings that can be passed to 3rd party
>> > libraries, etc.
>>
>> I think this is very dangerous.
>>
>> I think Greg should not be talking to the filesystem when inserting
>> filenames into a set. We don't allow filesystem access from the UI
>> thread of Chrome, and I think other parts of our system should also
>> not do filesystem access on their critical threads, especially if they
>> want to be more part of Chrome in the future.
>
> Well, so the use I have for this in O3D at the moment is in our importer,
> which currently is a separate command-line tool that reads Collada files and
> writes out our wire format for geometry.  So it isn't meant to be occuring
> in a UI thread, but I could see times when it might be useful to know for
> sure if two files reference the same file in the UI thread (dragging and
> dropping a file onto a drop zone, for instance).
> I do need to know if I have the same file more than once in a set because
> the COLLADA file might reference the same texture multiple times, or (more
> dangerous) it might reference a file that is one file on Windows,
> but (incorrectly) maps to two different files in the (Unix-path-format) .tgz
> files.  To detect that, I need canonicalization.

You can't actually canonicalize a filename on Windows, so I think it's
dangerous to write a component that claims to do it.

I think you just need to come up with some simple rules that makes it
work most of the time. Personally I would do ASCII lowercasing and
stop worrying about it. If you use ICU to lower-case "correctly,"
Windows won't necessarily agree and you won't be able to use that
file.

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: Changes to FilePath?

[Greg Spencer]

On Wed, May 13, 2009 at 4:07 PM, Brett Wilson  wrote:

> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker 
> wrote:
> >
> > Perhaps what we need is a companion to FilePath.  For example:
> >
> > FilePath: much as it is now, lightweight, "alternative to string
> manipulation".
> > FileReference: heavierweight, can talk to the file system and have
> > carnal knowledge of platform specifics for things like resolving /
> > canonicalizing pathnames, determining whether or not they refer to the
> > same files, generating C strings that can be passed to 3rd party
> > libraries, etc.
>
> I think this is very dangerous.
>
> I think Greg should not be talking to the filesystem when inserting
> filenames into a set. We don't allow filesystem access from the UI
> thread of Chrome, and I think other parts of our system should also
> not do filesystem access on their critical threads, especially if they
> want to be more part of Chrome in the future.


Well, so the use I have for this in O3D at the moment is in our importer,
which currently is a separate command-line tool that reads Collada files and
writes out our wire format for geometry.  So it isn't meant to be occuring
in a UI thread, but I could see times when it might be useful to know for
sure if two files reference the same file in the UI thread (dragging and
dropping a file onto a drop zone, for instance).

I do need to know if I have the same file more than once in a set because
the COLLADA file might reference the same texture multiple times, or (more
dangerous) it might reference a file that is one file on Windows,
but (incorrectly) maps to two different files in the (Unix-path-format) .tgz
files.  To detect that, I need canonicalization.

I also need to convert paths in the Collada file to relative paths in our
tgz files.  In order to do that, I need to be able to normalize the path to
the Collada file so I can normalize the paths to the referenced texture
files and strip off common base directories.

I'd really like to avoid the filesystem access too -- it's a real pain in
the ass to do, which is why it hasn't been done yet.  Currently, the user
has to tell me the string to strip off of the pathnames to make them
relative, and if files collide or split, then the output is just 2x bigger,
or just doesn't work.  I'd like to fix those things, but to do it right, I
need a better set of tools, and it seemed to me that if I was needing these
tools, then someone else could use them too.

-Greg.

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Greg Spencer]

On Wed, May 13, 2009 at 4:35 PM, Darin Fisher  wrote:

> The "solution" is to not convert to UTF-16 unless you are trying to
> generate a string to display to the user.  Then you should use the LANG
> information to determine how best to render the text for display to the
> user.
>

Yeah, that would be nice, and I agree, but the reason I need it is that some
third party APIs (probably wrongly) take UTF16 to represent an input file in
their API.  So in order for the third party API to load the file properly, I
need a UTF16 version of the file path.  Also, in all of the O3D code, we
assume that strings are encoded in UTF8 (which is fine and correct for any
string except for filenames on Linux), so any string that might come from
the user would come in as UTF8, and I'd have to translate it into a FilePath
(somehow).


> I know this doesn't really help.  I think it is reasonable to have a
> utility somewhere to perform a conversion to UTF-16 (or UTF-8), but it
> should come with a stern warning, and I kind of prefer it not being a method
> on FilePath since I would prefer people not be tempted to overuse it.
>

Yeah, I think we've beat that to death: it won't be in FilePath.

-Greg.

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

[chromium-dev] Re: Chromium Valgrind Fixit Day!

[Rahul Kuchhal]

A few of these, where root cause is the same (leaking of tasks, for example
11462, 6, 11144 among others) should get fixed once
http://codereview.chromium.org/115328 gets committed.

On Wed, May 13, 2009 at 5:23 PM, Evan Martin  wrote:

>
> And the award goes to...
>
> % git log origin --since=yesterday --grep=valgrind -i --pretty='format:%an
>  %s'
> thes...@chromium.org  Split NetUtilTest.IDNToUnicode into IDNToUnicodeFast
> e...@chromium.org  valgrind: print the gtest suppression list on startup.
>
> Wait, we've had *one* fix so far?  :~(  (Mine doesn't count, as it's a
> one-liner for logging.)
> I guess there's room for some others where someone didn't mention
> valgrind in their commit message.
>
> I've made progress on two more bugs, but that leaves pretty much all
> the rest unclaimed.
>
> http://code.google.com/p/chromium/issues/list?can=2&q=label:valgrind
>
> On Mon, May 11, 2009 at 2:20 PM, Dan Kegel 
> wrote:
> >
> > We've been using Valgrind to find memory leaks, pointer errors, and race
> > conditions in Chromium on Mac and Linux for a while now.
> > (See the valgrind bots at http://build.chromium.org.)
> > That's cool, but it would be even cooler if we actually fixed the
> > problems Valgrind has found.  According to
> > http://code.google.com/p/chromium/issues/list?q=valgrind
> > we've fixed 24 Valgrind issues already, but there are 60 still open.
> >
> > So let's do something about it!  The first step is for you to visit
> >  http://dev.chromium.org/developers/how-tos/using-valgrind
> > and learn about how to use Valgrind to find problems in Chromium.
> >
> > A few Chromium developers (playmobil, jhawkins, thestig, and myself)
> > are going to host a Valgrind Fixit this Wednesday and Thursday,
> > May 13th and 14th.  We'll be available on the chromium irc channel
> > (irc.freenode.net/#chromium) to help you get started using Valgrind
> > with Chromium.  The page linked above also has suggestions for
> > what to do during the Fixit.  (For instance, be sure to put a note
> > in the bug report saying you've started fixing the bug, so nobody
> > else duplicates your effort.)
> >
> > As incentive for people to help out, we will send a Valgrind mug to
> > whoever contributes the best Valgrind-related fixes, bug reports,
> > and/or triage during those two days (winner will be chosen at the
> > discretion of the valgrind fixit judging panel).
> >
> > Thanks, and see you at the Fixit!
> > - Dan
> >
> > p.s. And thanks to Julian Seward of http://valgrind.org for providing
> > such a wonderful tool!
> >
> > >
> >
>
> >
>

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

[chromium-dev] Re: Chromium Valgrind Fixit Day!

[Evan Martin]

And the award goes to...

% git log origin --since=yesterday --grep=valgrind -i --pretty='format:%an  %s'
thes...@chromium.org  Split NetUtilTest.IDNToUnicode into IDNToUnicodeFast
e...@chromium.org  valgrind: print the gtest suppression list on startup.

Wait, we've had *one* fix so far?  :~(  (Mine doesn't count, as it's a
one-liner for logging.)
I guess there's room for some others where someone didn't mention
valgrind in their commit message.

I've made progress on two more bugs, but that leaves pretty much all
the rest unclaimed.

http://code.google.com/p/chromium/issues/list?can=2&q=label:valgrind

On Mon, May 11, 2009 at 2:20 PM, Dan Kegel  wrote:
>
> We've been using Valgrind to find memory leaks, pointer errors, and race
> conditions in Chromium on Mac and Linux for a while now.
> (See the valgrind bots at http://build.chromium.org.)
> That's cool, but it would be even cooler if we actually fixed the
> problems Valgrind has found.  According to
> http://code.google.com/p/chromium/issues/list?q=valgrind
> we've fixed 24 Valgrind issues already, but there are 60 still open.
>
> So let's do something about it!  The first step is for you to visit
>  http://dev.chromium.org/developers/how-tos/using-valgrind
> and learn about how to use Valgrind to find problems in Chromium.
>
> A few Chromium developers (playmobil, jhawkins, thestig, and myself)
> are going to host a Valgrind Fixit this Wednesday and Thursday,
> May 13th and 14th.  We'll be available on the chromium irc channel
> (irc.freenode.net/#chromium) to help you get started using Valgrind
> with Chromium.  The page linked above also has suggestions for
> what to do during the Fixit.  (For instance, be sure to put a note
> in the bug report saying you've started fixing the bug, so nobody
> else duplicates your effort.)
>
> As incentive for people to help out, we will send a Valgrind mug to
> whoever contributes the best Valgrind-related fixes, bug reports,
> and/or triage during those two days (winner will be chosen at the
> discretion of the valgrind fixit judging panel).
>
> Thanks, and see you at the Fixit!
> - Dan
>
> p.s. And thanks to Julian Seward of http://valgrind.org for providing
> such a wonderful tool!
>
> >
>

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

[chromium-dev] New Jank label in issue tracker

[Ben Goodger (Google)]

Though I've upgraded my desktop PC to fancy hardware, I still use a
Core 2 Duo 2.4GHz laptop with 2GB RAM. This is still a pretty typical
configuration for even high end laptops today. Sad to say under heavy
load (several windows, many tabs in each), the amount of jank I'm
experiencing is pretty high.

To help identify and triage these issues, I've added a "Jank" label in
the bug system. I feel like we should focus on reducing these issues
in the next release cycle - this is an area where we have historically
had a good performance, we should not lose it.

It's hard to write tests for jankiness because time and entropy are
typically the key inputs more than any specific set of pages. But if
you experience jank in your own use of Chrome I encourage you to try
and identify causes and file bugs with this new label.

http://code.google.com/p/chromium/issues/list?can=2&q=label%3AJank

-Ben

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

[chromium-dev] Re: Changes to FilePath?

[Brett Wilson]

On Wed, May 13, 2009 at 4:34 PM, Amanda Walker  wrote:
> On Wed, May 13, 2009 at 7:07 PM, Brett Wilson  wrote:
>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker  wrote:
>>>
>>> Perhaps what we need is a companion to FilePath.  For example:
>>>
>>> FilePath: much as it is now, lightweight, "alternative to string 
>>> manipulation".
>>> FileReference: heavierweight, can talk to the file system and have
>>> carnal knowledge of platform specifics for things like resolving /
>>> canonicalizing pathnames, determining whether or not they refer to the
>>> same files, generating C strings that can be passed to 3rd party
>>> libraries, etc.
>>
>> I think this is very dangerous.
>>
>> I think Greg should not be talking to the filesystem when inserting
>> filenames into a set. We don't allow filesystem access from the UI
>> thread of Chrome, and I think other parts of our system should also
>> not do filesystem access on their critical threads, especially if they
>> want to be more part of Chrome in the future.
>
> But in context, he's passing these things to 3rd party libraries that
> will be doing plenty of file system access (importing and exporting
> data, for example).  That's why I was suggesting something separate
> from FilePath for such use.

Then he doesn't need canonicalization at all. He needs to know how the
third party library is going to use the string for filesystem access
and then do the corresponding transformations. That does not involve
filesystem access.

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: Changes to FilePath?

[Darin Fisher]

On Wed, May 13, 2009 at 2:20 PM, Greg Spencer  wrote:

> On Wed, May 13, 2009 at 2:05 PM, Darin Fisher  wrote:
>>
>> That conversion is not defined.  If you are on Linux, the contents of the
>> file path is just an array of bytes.  It might be UTF-8, in which case you
>> can convert to UTF-16.  However, it may also be some crazy encoding or it
>> may not match any encoding.  This OS does not require it to match an
>> encoding.
>>
>> When we need to convert a FilePath to Unicode, we use the
>> SysWideToNativeMB and SysNativeMBToWide functions from base.  This works by
>> inspecting what the system thinks the current multi-byte encoding is.  On
>> Mac that is UTF-8.  On Linux, it depends on the value of $LANG.  Each time
>> we do such a conversion, we are introducing a potential bug in the product
>> (on Linux at least), so we try hard to avoid them.
>>
>
> Yes, I know that this is how it works (see earlier messages in this
> thread), but can you tell me if there are any Linux apps that manage to do
> this correctly (e.g. without having this bug), and how they do it?
>
> I can't see how any Linux app can do any better than looking at LANG and
> LC_CHAR and hoping that they're set correctly.  Certainly there's no way to
> decode a pathname that includes multiple encodings, and I have no idea what
> happens with NFS mounts between machines with different settings.
>
> I'm just saying why not just do as well as can be done by the best app out
> there, and punt after that?
>
> -Greg.
>


Sorry to repeat information.  This is a long thread!

The "solution" is to not convert to UTF-16 unless you are trying to generate
a string to display to the user.  Then you should use the LANG information
to determine how best to render the text for display to the user.

The program should try its best to preserve the file path in the original
form and not try to convert to UTF-16 and back again since that conversion
may be lossy.

I know this doesn't really help.  I think it is reasonable to have a utility
somewhere to perform a conversion to UTF-16 (or UTF-8), but it should come
with a stern warning, and I kind of prefer it not being a method on FilePath
since I would prefer people not be tempted to overuse it.

-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: Changes to FilePath?

[Amanda Walker]

On Wed, May 13, 2009 at 7:07 PM, Brett Wilson  wrote:
> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker  wrote:
>>
>> Perhaps what we need is a companion to FilePath.  For example:
>>
>> FilePath: much as it is now, lightweight, "alternative to string 
>> manipulation".
>> FileReference: heavierweight, can talk to the file system and have
>> carnal knowledge of platform specifics for things like resolving /
>> canonicalizing pathnames, determining whether or not they refer to the
>> same files, generating C strings that can be passed to 3rd party
>> libraries, etc.
>
> I think this is very dangerous.
>
> I think Greg should not be talking to the filesystem when inserting
> filenames into a set. We don't allow filesystem access from the UI
> thread of Chrome, and I think other parts of our system should also
> not do filesystem access on their critical threads, especially if they
> want to be more part of Chrome in the future.

But in context, he's passing these things to 3rd party libraries that
will be doing plenty of file system access (importing and exporting
data, for example).  That's why I was suggesting something separate
from FilePath for such use.

--Amanda

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

[chromium-dev] Re: Changes to FilePath?

[Brett Wilson]

On Wed, May 13, 2009 at 3:51 PM, Amanda Walker  wrote:
>
> Perhaps what we need is a companion to FilePath.  For example:
>
> FilePath: much as it is now, lightweight, "alternative to string 
> manipulation".
> FileReference: heavierweight, can talk to the file system and have
> carnal knowledge of platform specifics for things like resolving /
> canonicalizing pathnames, determining whether or not they refer to the
> same files, generating C strings that can be passed to 3rd party
> libraries, etc.

I think this is very dangerous.

I think Greg should not be talking to the filesystem when inserting
filenames into a set. We don't allow filesystem access from the UI
thread of Chrome, and I think other parts of our system should also
not do filesystem access on their critical threads, especially if they
want to be more part of Chrome in the future.

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: Changes to FilePath?

[Amanda Walker]

Perhaps what we need is a companion to FilePath.  For example:

FilePath: much as it is now, lightweight, "alternative to string manipulation".
FileReference: heavierweight, can talk to the file system and have
carnal knowledge of platform specifics for things like resolving /
canonicalizing pathnames, determining whether or not they refer to the
same files, generating C strings that can be passed to 3rd party
libraries, etc.

--Amanda


On Wed, May 13, 2009 at 5:22 PM, Greg Spencer  wrote:
> On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai  wrote:
>>
>> If you've got to take an arbitrary FilePath and convert it for display
>> to the user, or take an arbitrary string in a known encoding and
>> re-encode it for the filesystem, then we don't have anything in
>> FilePath for this.  I believe that if we do add something, it should
>> strictly operate only on single pathname components at a time, and not
>> entire pathnames.  We could add it to FilePath or we could add it
>> somewhere else, because it is sort of distinct from what FilePath is
>> really supposed to be, which is just a container for ferrying around
>> native paths.
>
>
> OK, I can see the allure of dealing in terms of lists of encoded strings so
> that you
> can encode them separately.   For my purposes, I need to get a string
> encoded as
> UTF16 (on Windows) or UTF8 (on other platforms) that represents a filename
> so that
> I can pass it to third party APIs, so it has to include the path separators.
>  But that
> can be done as a "join" operation when I get the string out.
>>
>> >> It's also a specification and implementation nightmare.  Everyone has
>> >> a different idea of what "normalization" means.  What's your idea?
>> >
>> > Yes, I know it's a nightmare all around, but I think it would be useful
>> > to
>> > have something that addresses this.  My idea would be the same as
>> > Python's
>> > os.path.normpath, mainly because it's a well-tested, seasoned example
>> > with
>> > test cases.  Windows also has a routine for this (PathCanonicalize) that
>> > could be used (but I know it doesn't work for UNC paths).
>>
>> Why would it be useful?  Do you want to compare paths for equality?
>
> Yes, for instance to be able to place them into a map or set and be sure I
> only have one
> entry for a particular file.  And I want to be able to do absolute to
> relative path conversions
> (as far as possible, anyhow).  And yes, I know that those are *really hard*
> to do properly,
> which argues even more for implementing one in a common library so that
> individual
> developers don't roll their own all the time, thinking that it is easy (and
> consequently
> producing buggy implementations).
>
>>
>> Then we should have an API that compares paths for equality.  It would
>> have to hit the disk to do so.  You might need general-purpose
>> canonization to implement that on some systems.  Great, you need to
>> hit the disk to do that too.  It's fine if you want these things, but
>> we can't put them into FilePath.  It's important that FilePath remain
>> lightweight and not make any system calls, because system calls can
>> block and FilePath is just a data carrier.
>
> Which is why I proposed in my last message not putting them into FilePath,
> since I can see
> that it is not your intention that it support anything that hits the
> filesystem (and I can see why
> you would want that).
>>
>> os.path.normpath is known to be buggy.  It might be well-tested and
>> seasoned, but only within the confines of its known limitations.
>> Watch this. [...]
>
> Yes, I'm aware that you can create situations (especially with symbolic
> links) where
> the same path conversions will succeed or fail depending on the filesystem
> contents.  This is why
> the class would have to have access to the filesystem.
>
>>
>> Again, it sounds like what you really want is a pathname comparator
>> that hits the disk.  You really can't do this stuff correctly on most
>> systems without talking to the filesystem.  You can't even do
>> general-purpose canonization without talking to the filesystem.
>
> Yep.  Totally agreed. (and normcase is probably not the behavior I'm looking
> for, you're right).
>
>>
>> Let me make clear: I'm not trying to shoot down the idea of needing to
>> be able to compare paths or even necessarily canonize them.  I'm
>> arguing primarily against doing it in FilePath, but I'm also also
>> trying to illustrate that doing proper comparisons and canonization is
>> harder than it seems, that even "seasoned and well-tested" APIs are
>> limited in ways that developers don't necessarily expect, and that the
>> semantics and expectations need to be well-defined.
>
> Very well illustrated, and I assure you that I'm well aware that it's a
> bitch to do right.
> -Greg.

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

[chromium-dev] Re: Changes to FilePath?

[Scott Hess]

This post made me think that we should have infrastructure so that
certain unit tests can opt to run in a restricted environment to
enforce that someone doesn't come along and add filesystem-access code
or other known-bad synchronous APIs.

I realize that that is probably hard, and that patches would be
welcome.  Just throwing it out there in hopes that someone says "Hey,
I know how to do that" and someone else says "Hey, do that".

-scott

[It could also be a rathole that only seems like a good idea until you
actually try it, like getting const-ness propagation thoroughly
correct.]


On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai  wrote:
>
> If you've got a file that begins its life as something on-disk, and
> you just need to carry the path to it around, then that's fine, it
> should live its life as a FilePath.
>
> If you've got to create a file using some name where the name is some
> constant in code, use FilePath with ASCII constants.  AppendASCII
> exists to stick new ASCII components onto existing FilePaths.  This is
> fine and is considered safe because ASCII is a subset of any rational
> filesystem encoding.
>
> If you've got to take an arbitrary FilePath and convert it for display
> to the user, or take an arbitrary string in a known encoding and
> re-encode it for the filesystem, then we don't have anything in
> FilePath for this.  I believe that if we do add something, it should
> strictly operate only on single pathname components at a time, and not
> entire pathnames.  We could add it to FilePath or we could add it
> somewhere else, because it is sort of distinct from what FilePath is
> really supposed to be, which is just a container for ferrying around
> native paths.
>
>>> It's also a specification and implementation nightmare.  Everyone has
>>> a different idea of what "normalization" means.  What's your idea?
>>
>> Yes, I know it's a nightmare all around, but I think it would be useful to
>> have something that addresses this.  My idea would be the same as Python's
>> os.path.normpath, mainly because it's a well-tested, seasoned example with
>> test cases.  Windows also has a routine for this (PathCanonicalize) that
>> could be used (but I know it doesn't work for UNC paths).
>
> Why would it be useful?  Do you want to compare paths for equality?
> Then we should have an API that compares paths for equality.  It would
> have to hit the disk to do so.  You might need general-purpose
> canonization to implement that on some systems.  Great, you need to
> hit the disk to do that too.  It's fine if you want these things, but
> we can't put them into FilePath.  It's important that FilePath remain
> lightweight and not make any system calls, because system calls can
> block and FilePath is just a data carrier.
>
> os.path.normpath is known to be buggy.  It might be well-tested and
> seasoned, but only within the confines of its known limitations.
> Watch this.
>
> m...@anodizer bash$ ls -l a/b/../c
> -rw-r--r--  1 mark  staff  0 May 13 15:47 a/b/../c
> m...@anodizer bash$ python
> Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import os.path
 os.path.normpath('a/b/../c')
> 'a/c'
 ^D
> m...@anodizer bash$ ls -l a/c
> ls: a/c: No such file or directory
>
>> Probably the same as os.path.normcase in Python.  I want this stuff so that
>> I can make sure that I can at least semi-reliably compare/manipulate
>> FilePaths to do things like absolute->relative path conversion, or store
>> FilePaths in a set or map and be sure I don't have multiple entries pointing
>> to the same file.  Without these kinds of operations, doing these things is
>> pretty much impossible.
>
> I don't think os.path.normcase does what you're asking for either.
>
> m...@anodizer bash$ ls -lid /System/Library
> 81 drwxr-xr-x  64 root  wheel  2176 May 12 18:37 /System/Library
> m...@anodizer bash$ ls -lid /system/LIBRARY
> 81 drwxr-xr-x  64 root  wheel  2176 May 12 18:37 /system/LIBRARY
> m...@anodizer bash$ python
> Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import sys
 sys.platform
> 'darwin'
 import os.path
 os.path.normcase('/System/Library')
> '/System/Library'
 os.path.normcase('/system/LIBRARY')
> '/system/LIBRARY'
 ^D
>
> Even os.path.realpath returns the same results.
>
> Again, it sounds like what you really want is a pathname comparator
> that hits the disk.  You really can't do this stuff correctly on most
> systems without talking to the filesystem.  You can't even do
> general-purpose canonization without talking to the filesystem.
>
> Let me make clear: I'm not trying to shoot down the idea of needing to
> be able to compare paths or even necessarily canonize them.  I'm
> arguing primarily against doing it in FilePath, but I'm als

[chromium-dev] Re: Changes to FilePath?

[Greg Spencer]

On Wed, May 13, 2009 at 2:05 PM, Darin Fisher  wrote:
>
> That conversion is not defined.  If you are on Linux, the contents of the
> file path is just an array of bytes.  It might be UTF-8, in which case you
> can convert to UTF-16.  However, it may also be some crazy encoding or it
> may not match any encoding.  This OS does not require it to match an
> encoding.
>
> When we need to convert a FilePath to Unicode, we use the SysWideToNativeMB
> and SysNativeMBToWide functions from base.  This works by inspecting what
> the system thinks the current multi-byte encoding is.  On Mac that is UTF-8.
>  On Linux, it depends on the value of $LANG.  Each time we do such a
> conversion, we are introducing a potential bug in the product (on Linux at
> least), so we try hard to avoid them.
>

Yes, I know that this is how it works (see earlier messages in this thread),
but can you tell me if there are any Linux apps that manage to do this
correctly (e.g. without having this bug), and how they do it?

I can't see how any Linux app can do any better than looking at LANG and
LC_CHAR and hoping that they're set correctly.  Certainly there's no way to
decode a pathname that includes multiple encodings, and I have no idea what
happens with NFS mounts between machines with different settings.

I'm just saying why not just do as well as can be done by the best app out
there, and punt after that?

-Greg.

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

[chromium-dev] Re: Why is the Mac Omnibox stealing focus?

[Avi Drissman]

OK, so this was
r15790.
The code already exists to set the focus to the location bar if it already
had it, though.

Avi

On Wed, May 13, 2009 at 2:24 PM, Avi Drissman  wrote:

> I'm implementing save/restore focus when switching tabs, and a recent
> checkin on the Mac omnibox is causing it to steal the focus. To see this:
>
> (gdb) b -[NSWindow makeFirstResponder:]
>
> Then switch tabs:
>
> #5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
> #6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
> (this=0x595a220, display_te...@0x595a260, user_text_length=0) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:281
> #7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
> (this=0x595a220, te...@0x595a260, caret_pos=0) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:203
> #8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
> #9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:215
> #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
> tab_for_state_restoring=0x619da00) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:125
> #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
> contents=0x619da00, should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> location_bar_view_mac.mm:62
> #12 0x00197ac8 in -[ToolbarController
> updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> toolbar_controller.mm:102
> #13 0x00181465 in -[BrowserWindowController
> updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_controller.mm:305
> #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
> contents=0x619da00, should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_cocoa.mm:145
> #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
> should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257
>
> UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
> which, on lines 280-3 insists on becoming the keyboard focus. Why?
>
> 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: Why is the Mac Omnibox stealing focus?

[Avi Drissman]

OK. Will update my bug with that blocker info.

Avi

On Wed, May 13, 2009 at 2:34 PM, Scott Hess  wrote:

> The "why" is probably because I misunderstood something.  With an
> NSTextField there, we can't set the selection without having focus,
> which may have confused me into grabbing focus in cases where it isn't
> needed (or requested).  I've been spending some time figuring out
> where all that code can get called from.  Now that some of the other
> code is more fleshed out, the original reason for it to be there might
> be completely gone.
>
> http://crbug.com/11920
>
> -scott
>
>
> On Wed, May 13, 2009 at 2:27 PM, Avi Drissman  wrote:
> > OK, so this was r15790. The code already exists to set the focus to the
> > location bar if it already had it, though.
> >
> > Avi
> >
> > On Wed, May 13, 2009 at 2:24 PM, Avi Drissman  wrote:
> >>
> >> I'm implementing save/restore focus when switching tabs, and a recent
> >> checkin on the Mac omnibox is causing it to steal the focus. To see
> this:
> >>
> >> (gdb) b -[NSWindow makeFirstResponder:]
> >>
> >> Then switch tabs:
> >>
> >> #5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
> >> #6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
> >> (this=0x595a220, display_te...@0x595a260, user_text_length=0) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:281
> >> #7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
> >> (this=0x595a220, te...@0x595a260, caret_pos=0) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:203
> >> #8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
> >>
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
> >> #9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:215
> >> #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
> >> tab_for_state_restoring=0x619da00) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:125
> >> #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
> >> contents=0x619da00, should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> location_bar_view_mac.mm:62
> >> #12 0x00197ac8 in -[ToolbarController
> >> updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
> >> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> toolbar_controller.mm:102
> >> #13 0x00181465 in -[BrowserWindowController
> >> updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
> >> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_controller.mm:305
> >> #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
> >> contents=0x619da00, should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_cocoa.mm:145
> >> #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
> >> should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257
> >>
> >> UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
> >> which, on lines 280-3 insists on becoming the keyboard focus. Why?
> >>
> >> 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] Why is the Mac Omnibox stealing focus?

[Avi Drissman]

I'm implementing save/restore focus when switching tabs, and a recent
checkin on the Mac omnibox is causing it to steal the focus. To see this:

(gdb) b -[NSWindow makeFirstResponder:]

Then switch tabs:

#5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
#6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
(this=0x595a220, display_te...@0x595a260, user_text_length=0) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:281
#7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
(this=0x595a220, te...@0x595a260, caret_pos=0) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:203
#8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
#9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:215
#10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
tab_for_state_restoring=0x619da00) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:125
#11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
contents=0x619da00, should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
location_bar_view_mac.mm:62
#12 0x00197ac8 in -[ToolbarController
updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
_cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/toolbar_controller.mm:102
#13 0x00181465 in -[BrowserWindowController
updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
_cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
browser_window_controller.mm:305
#14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
contents=0x619da00, should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
browser_window_cocoa.mm:145
#15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257

UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
which, on lines 280-3 insists on becoming the keyboard focus. Why?

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: Why is the Mac Omnibox stealing focus?

[Scott Hess]

The "why" is probably because I misunderstood something.  With an
NSTextField there, we can't set the selection without having focus,
which may have confused me into grabbing focus in cases where it isn't
needed (or requested).  I've been spending some time figuring out
where all that code can get called from.  Now that some of the other
code is more fleshed out, the original reason for it to be there might
be completely gone.

http://crbug.com/11920

-scott


On Wed, May 13, 2009 at 2:27 PM, Avi Drissman  wrote:
> OK, so this was r15790. The code already exists to set the focus to the
> location bar if it already had it, though.
>
> Avi
>
> On Wed, May 13, 2009 at 2:24 PM, Avi Drissman  wrote:
>>
>> I'm implementing save/restore focus when switching tabs, and a recent
>> checkin on the Mac omnibox is causing it to steal the focus. To see this:
>>
>> (gdb) b -[NSWindow makeFirstResponder:]
>>
>> Then switch tabs:
>>
>> #5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
>> #6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
>> (this=0x595a220, display_te...@0x595a260, user_text_length=0) at
>> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:281
>> #7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
>> (this=0x595a220, te...@0x595a260, caret_pos=0) at
>> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:203
>> #8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
>> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
>> #9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
>> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:215
>> #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
>> tab_for_state_restoring=0x619da00) at
>> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:125
>> #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
>> contents=0x619da00, should_restore_state=true) at
>> /Users/avi/Source/chrome/src/chrome/browser/cocoa/location_bar_view_mac.mm:62
>> #12 0x00197ac8 in -[ToolbarController
>> updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
>> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
>> /Users/avi/Source/chrome/src/chrome/browser/cocoa/toolbar_controller.mm:102
>> #13 0x00181465 in -[BrowserWindowController
>> updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
>> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
>> /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_controller.mm:305
>> #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
>> contents=0x619da00, should_restore_state=true) at
>> /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_cocoa.mm:145
>> #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
>> should_restore_state=true) at
>> /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257
>>
>> UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
>> which, on lines 280-3 insists on becoming the keyboard focus. Why?
>>
>> 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: Changes to FilePath?

[Greg Spencer]

On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai  wrote:

> If you've got to take an arbitrary FilePath and convert it for display
> to the user, or take an arbitrary string in a known encoding and
> re-encode it for the filesystem, then we don't have anything in
> FilePath for this.  I believe that if we do add something, it should
> strictly operate only on single pathname components at a time, and not
> entire pathnames.  We could add it to FilePath or we could add it
> somewhere else, because it is sort of distinct from what FilePath is
> really supposed to be, which is just a container for ferrying around
> native paths.


OK, I can see the allure of dealing in terms of lists of encoded strings so
that you
can encode them separately.   For my purposes, I need to get a string
encoded as
UTF16 (on Windows) or UTF8 (on other platforms) that represents a filename
so that
I can pass it to third party APIs, so it has to include the path separators.
 But that
can be done as a "join" operation when I get the string out.

>> It's also a specification and implementation nightmare.  Everyone has
> >> a different idea of what "normalization" means.  What's your idea?
> >
> > Yes, I know it's a nightmare all around, but I think it would be useful
> to
> > have something that addresses this.  My idea would be the same as
> Python's
> > os.path.normpath, mainly because it's a well-tested, seasoned example
> with
> > test cases.  Windows also has a routine for this (PathCanonicalize) that
> > could be used (but I know it doesn't work for UNC paths).
>
> Why would it be useful?  Do you want to compare paths for equality?


Yes, for instance to be able to place them into a map or set and be sure I
only have one
entry for a particular file.  And I want to be able to do absolute to
relative path conversions
(as far as possible, anyhow).  And yes, I know that those are *really hard*
to do properly,
which argues even more for implementing one in a common library so that
individual
developers don't roll their own all the time, thinking that it is easy (and
consequently
producing buggy implementations).


> Then we should have an API that compares paths for equality.  It would
> have to hit the disk to do so.  You might need general-purpose
> canonization to implement that on some systems.  Great, you need to
> hit the disk to do that too.  It's fine if you want these things, but
> we can't put them into FilePath.  It's important that FilePath remain
> lightweight and not make any system calls, because system calls can
> block and FilePath is just a data carrier.


Which is why I proposed in my last message not putting them into FilePath,
since I can see
that it is not your intention that it support anything that hits the
filesystem (and I can see why
you would want that).

os.path.normpath is known to be buggy.  It might be well-tested and
> seasoned, but only within the confines of its known limitations.
> Watch this. [...]


Yes, I'm aware that you can create situations (especially with symbolic
links) where
the same path conversions will succeed or fail depending on the filesystem
contents.  This is why
the class would have to have access to the filesystem.


> Again, it sounds like what you really want is a pathname comparator
> that hits the disk.  You really can't do this stuff correctly on most
> systems without talking to the filesystem.  You can't even do
> general-purpose canonization without talking to the filesystem.


Yep.  Totally agreed. (and normcase is probably not the behavior I'm looking
for, you're right).


> Let me make clear: I'm not trying to shoot down the idea of needing to
> be able to compare paths or even necessarily canonize them.  I'm
> arguing primarily against doing it in FilePath, but I'm also also
> trying to illustrate that doing proper comparisons and canonization is
> harder than it seems, that even "seasoned and well-tested" APIs are
> limited in ways that developers don't necessarily expect, and that the
> semantics and expectations need to be well-defined.


Very well illustrated, and I assure you that I'm well aware that it's a
bitch to do right.

-Greg.

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Darin Fisher]

On Tue, Apr 28, 2009 at 2:47 PM, Greg Spencer  wrote:

> On Tue, Apr 28, 2009 at 2:41 PM, Amanda Walker wrote:
>
>>
>> On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer 
>> wrote:
>> > 1) I'd like to add some explicit routines for converting to/from UTF8
>> and
>> > UTF16.  While it's nice (and important) that FilePath uses the
>> platform's
>> > native string, we've found that many third party libraries have made
>> other
>> > assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t)
>> paths
>> > regardless of platform, and converting a FilePath to and from those
>> forms is
>> > a platform-dependent exercise which should be centralized into the class
>> > (i.e. adding "ToUTF8" and "ToWide" functions to the class, and explicit
>> > constructors that take each type).
>>
>> One thing many of us have found, across multiple projects, is that
>> wchar_t is fraught with complication as soon as more than one platform
>> is involved. "wchar_t == UTF16" is a Windowsism (gcc defaults to 4
>> bytes, for example, and L"mumble" gets stored in UCS-4, not UTF-16).
>> Chrome started with more or less what you are suggesting, and we moved
>> off of it after much pain.
>
>
> I understand those issues quite well (but I probably should call the
> conversion method ToUTF16, now that you mention it).  And char* isn't
> necessarily UTF8 on all platforms either.
>
> OK, so what's the currently recommended path for converting to UTF16 or
> UTF8 from a FilePath?
>


That conversion is not defined.  If you are on Linux, the contents of the
file path is just an array of bytes.  It might be UTF-8, in which case you
can convert to UTF-16.  However, it may also be some crazy encoding or it
may not match any encoding.  This OS does not require it to match an
encoding.

When we need to convert a FilePath to Unicode, we use the SysWideToNativeMB
and SysNativeMBToWide functions from base.  This works by inspecting what
the system thinks the current multi-byte encoding is.  On Mac that is UTF-8.
 On Linux, it depends on the value of $LANG.  Each time we do such a
conversion, we are introducing a potential bug in the product (on Linux at
least), so we try hard to avoid them.

-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: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[jack]

Thanks for your tips, Matt. I will check the update and try your
suggestion. -jack

On May 13, 12:07 pm, Matt Perry  wrote:
> Cookies will not help user scripts, but they will help you with toolstrips
> and background pages.  Both of the latter pages run in an extension process
> under a common origin, so you can access your extension's cookies from those
> contexts just fine.  You'd need to use the content script communication if
> you need to inform content scripts about stored settings, though.
> (Note that cookie support is not in yet.)
>
> 2009/5/13 jack 
>
> > Hi Nick,
>
> > Thanks for your feedback. My understanding is that Chrome is actively
> > working on an official user preference system based on HTML 5 local
> > storage. In the meantime, I was suggested trying bookmarks as a
> > workaround. I haven't tried the new release yet, but in last week it
> > didn't work out because it seemed the communication between the
> > content script and extension (namely chromium.extension.connect()
> > blabla) was not ready yet. As for cookie, unless I missed sth, I think
> > it is not a decent solution because of its strict security/domain
> > restriction (to keep in mind user preference should work browser-wide
> > instead of domain-wide).
>
> > Any comments are welcome.
>
> > -Jack
>
> > On May 13, 8:16 am, Nick Baum  wrote:
> > > Hey Jack,
>
> > > This is super cool, thanks for sharing!
>
> > > Matt (cc'd) is working on letting extensions store cookies. Is that what
> > > you're missing?
>
> > > Cheers,
>
> > > -Nick
>
> > > 2009/5/12 jack 
>
> > > > Thanks for your feedback and glad to know it worked for you. Your
> > > > guess is correct. Although such features are OK in Cleeki's IE/Firefox
> > > > addons, I haven't figure out a way for Chrome yet. I tried the trick
> > > > using bookmarking and script/extension communication but it didn't
> > > > work so far. If anybody here knows how to do this, I'd love to know
> > > > and integrate it into the add-on.
>
> > > > -Jack
>
> > > > On 5月12日, 下午10时11分, PhistucK  wrote:
> > > > > Works for me. The IE8 Accelerator importing and the preferences work
> > only
> > > > in
> > > > > the corresponding pages, because the lack of Extensions cookie
> > support, I
> > > > > assume, right?
> > > > > Great job!
>
> > > > > ☆PhistucK
>
> > > > > On Tue, May 12, 2009 at 20:47, jack  wrote:
>
> > > > > > I recently migrated the Firefox add-on, called Cleeki, into Google
> > > > > > Chrome. Cleeki can be used as Google Chrome's Accelerators, only
> > > > > > superior to IE8 accelerators. Basically you select any text to
> > search/
> > > > > > share/publish on the Internet, and preview the results in the same
> > > > > > page instantly.
>
> > > > > > Installation guideline:http://blog.cleeki.com/?p=70
> > > > > > A quick overview:http://blog.cleeki.com/?p=112
>
> > > > > > Based on the discussion last week, there is a known issue in
> > current
> > > > > > Chrome that the first page might not load the add-on script. Also
> > > > > > there is no (easy) user customization yet because of the lack of an
> > > > > > official user preference system. I would like to share the add-on
> > in
> > > > > > this community in case it is helpful for testing any new release of
> > > > > > Chrome. I will actively test it in the up-to-date Chrome and report
> > > > > > any bugs. Any of your bug reporting is also welcome. I hope when
> > > > > > Chrome add-on system becomes official, this add-on will also be
> > ready
> > > > > > (or almost).
>
> > > > > > Thanks for your attention and any of your comments are welcome.
>
> > > > > > -Jack
--~--~-~--~~~---~--~~
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: Skia is moving

[Darin Fisher]

On Wed, May 13, 2009 at 12:53 PM, Brett Wilson  wrote:

> On Wed, May 13, 2009 at 12:39 PM, Darin Fisher  wrote:
> > That is what I meant by pain
> > It only applies to "third party" code that conforms to the google style
> > guide, which says that all include paths must be relative to the root.
>  Come
> > to think of it, I think this could cause problems for such projects,
> since
> > I'm sure the V8 developers don't think of V8 as a third party piece of
> code,
> > and in their world, V8 is not checked out into a directory named
> > third_party.  We'd probably end up having to add "src/third_party" to the
> > include path or something like that.
>
> We already do this for all third_party code, but from chrome we
> include it with the third_party prefix. I think this is a good
> approach. In serverland, they actually change the includes in the
> third party files which I don't think we should do.
>
> Brett
>


This is fairly fragile.  It doesn't work if header foo/A includes header
foo/bar/B.  It works fine if foo/A includes bar/B, which is not the case for
a module "foo" that conforms to google style.

-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: Changes to FilePath?

[Mark Mentovai]

If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.

If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants.  AppendASCII
exists to stick new ASCII components onto existing FilePaths.  This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.

If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this.  I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames.  We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.

>> It's also a specification and implementation nightmare.  Everyone has
>> a different idea of what "normalization" means.  What's your idea?
>
> Yes, I know it's a nightmare all around, but I think it would be useful to
> have something that addresses this.  My idea would be the same as Python's
> os.path.normpath, mainly because it's a well-tested, seasoned example with
> test cases.  Windows also has a routine for this (PathCanonicalize) that
> could be used (but I know it doesn't work for UNC paths).

Why would it be useful?  Do you want to compare paths for equality?
Then we should have an API that compares paths for equality.  It would
have to hit the disk to do so.  You might need general-purpose
canonization to implement that on some systems.  Great, you need to
hit the disk to do that too.  It's fine if you want these things, but
we can't put them into FilePath.  It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.

os.path.normpath is known to be buggy.  It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.

m...@anodizer bash$ ls -l a/b/../c
-rw-r--r--  1 mark  staff  0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.normpath('a/b/../c')
'a/c'
>>> ^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory

> Probably the same as os.path.normcase in Python.  I want this stuff so that
> I can make sure that I can at least semi-reliably compare/manipulate
> FilePaths to do things like absolute->relative path conversion, or store
> FilePaths in a set or map and be sure I don't have multiple entries pointing
> to the same file.  Without these kinds of operations, doing these things is
> pretty much impossible.

I don't think os.path.normcase does what you're asking for either.

m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x  64 root  wheel  2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x  64 root  wheel  2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.platform
'darwin'
>>> import os.path
>>> os.path.normcase('/System/Library')
'/System/Library'
>>> os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
>>> ^D

Even os.path.realpath returns the same results.

Again, it sounds like what you really want is a pathname comparator
that hits the disk.  You really can't do this stuff correctly on most
systems without talking to the filesystem.  You can't even do
general-purpose canonization without talking to the filesystem.

Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them.  I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even "seasoned and well-tested" APIs are
limited in ways that developers don't necessarily expect, and that the
semantics and expectations need to be well-defined.

Mark

--~--~-~--~~~---~--~~
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: Skia is moving

[Brett Wilson]

On Wed, May 13, 2009 at 12:39 PM, Darin Fisher  wrote:
> That is what I meant by pain
> It only applies to "third party" code that conforms to the google style
> guide, which says that all include paths must be relative to the root.  Come
> to think of it, I think this could cause problems for such projects, since
> I'm sure the V8 developers don't think of V8 as a third party piece of code,
> and in their world, V8 is not checked out into a directory named
> third_party.  We'd probably end up having to add "src/third_party" to the
> include path or something like that.

We already do this for all third_party code, but from chrome we
include it with the third_party prefix. I think this is a good
approach. In serverland, they actually change the includes in the
third party files which I don't think we should do.

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: Skia is moving

[Ben Goodger (Google)]

Yes... that's what I'd imagine us doing... just because we suck in
projects A, B, C doesn't mean they need to conform to our "include
starts at the root" convention - as far as they're concerned the root
is src/ in their repo.

-Ben

On Wed, May 13, 2009 at 12:39 PM, Darin Fisher  wrote:
> That is what I meant by pain
> It only applies to "third party" code that conforms to the google style
> guide, which says that all include paths must be relative to the root.  Come
> to think of it, I think this could cause problems for such projects, since
> I'm sure the V8 developers don't think of V8 as a third party piece of code,
> and in their world, V8 is not checked out into a directory named
> third_party.  We'd probably end up having to add "src/third_party" to the
> include path or something like that.
> -Darin
>
> On Wed, May 13, 2009 at 12:35 PM, Ben Goodger (Google) 
> wrote:
>>
>> Really? I don't think we include anything in third_party using
>> third_party in the include path - or is this not what you mean by
>> "pain"?
>>
>> -Ben
>>
>> On Wed, May 13, 2009 at 12:32 PM, Darin Fisher  wrote:
>> > I think that's a good point, and it would make for a much easier to
>> > understand and enforce policy.  It means some potential pain if we ever
>> > wish
>> > to fork a top-level directory off into a separate opensource project.
>> > -Darin
>> >
>> > On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google)
>> > 
>> > wrote:
>> >>
>> >> I do think this distinction is fairly arbitrary in the world of open
>> >> source projects. It is not hard to imagine a time when some of these
>> >> dependencies may have more non-Google contributors than Googlers. It
>> >> is also possible that licensing may change over time.
>> >>
>> >> In addition, it makes it harder to distinguish what top level dirs we
>> >> have that aren't provided by deps.
>> >>
>> >> My personal preference is that everything that isn't hosted in our
>> >> repo goes into third_party regardless of whether its license agrees
>> >> with ours at this moment.
>> >>
>> >> -Ben
>> >>
>> >> On Tue, May 12, 2009 at 3:55 PM, Darin Fisher 
>> >> wrote:
>> >> > On Tue, May 12, 2009 at 3:06 PM, Brett Wilson 
>> >> > wrote:
>> >> >>
>> >> >> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain
>> >> >> 
>> >> >> wrote:
>> >> >> > On Tue, May 12, 2009 at 2:22 PM, Stephen White
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I'm in the process of updating chromium to use tip-of-tree skia,
>> >> >> >> and
>> >> >> >> in
>> >> >> >> the same CL, moving skia to a third_party directory,
>> >> >> >> retrieved via DEPS.  What this means for you:
>> >> >> >
>> >> >> > Hi,
>> >> >> > Why do you want to move it to third party?
>> >> >> > The other projects developed at google that we fetch through DEPS
>> >> >> > like
>> >> >> > googleurl, breakpad, gtests and courgette are all living in src,
>> >> >> > not
>> >> >> > third_party..
>> >> >> > Nicolas
>> >> >>
>> >> >> If our repo is not the canonical representation, they should all be
>> >> >> in
>> >> >> thierd party. So I think that all your examples are in the wrong
>> >> >> place.
>> >> >>
>> >> >> Brett
>> >> >
>> >> >
>> >> > src/courgette is the canonical representation.  we placed googleurl,
>> >> > breakpad, and v8 in src and not third_party because they are
>> >> > developed
>> >> > by
>> >> > our team, so we do not have licensing / copyright concerns.
>> >> > the rule we have been following is to put items in third_party that
>> >> > do
>> >> > not
>> >> > conform to our licensing or that are developed by another group.  i
>> >> > think by
>> >> > this measure it is correct for googleurl, breakpad, and v8 to live in
>> >> > src.
>> >> >  same goes for gtest.  skia seems like a borderline case to me.
>> >> > the point of third_party is to make ease the job of a licensing
>> >> > lawyer
>> >> > who
>> >> > has to figure out what they need to worry about.
>> >> > -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: Skia is moving

[Darin Fisher]

That is what I meant by pain
It only applies to "third party" code that conforms to the google style
guide, which says that all include paths must be relative to the root.  Come
to think of it, I think this could cause problems for such projects, since
I'm sure the V8 developers don't think of V8 as a third party piece of code,
and in their world, V8 is not checked out into a directory named
third_party.  We'd probably end up having to add "src/third_party" to the
include path or something like that.

-Darin


On Wed, May 13, 2009 at 12:35 PM, Ben Goodger (Google) wrote:

> Really? I don't think we include anything in third_party using
> third_party in the include path - or is this not what you mean by
> "pain"?
>
> -Ben
>
> On Wed, May 13, 2009 at 12:32 PM, Darin Fisher  wrote:
> > I think that's a good point, and it would make for a much easier to
> > understand and enforce policy.  It means some potential pain if we ever
> wish
> > to fork a top-level directory off into a separate opensource project.
> > -Darin
> >
> > On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google)  >
> > wrote:
> >>
> >> I do think this distinction is fairly arbitrary in the world of open
> >> source projects. It is not hard to imagine a time when some of these
> >> dependencies may have more non-Google contributors than Googlers. It
> >> is also possible that licensing may change over time.
> >>
> >> In addition, it makes it harder to distinguish what top level dirs we
> >> have that aren't provided by deps.
> >>
> >> My personal preference is that everything that isn't hosted in our
> >> repo goes into third_party regardless of whether its license agrees
> >> with ours at this moment.
> >>
> >> -Ben
> >>
> >> On Tue, May 12, 2009 at 3:55 PM, Darin Fisher 
> wrote:
> >> > On Tue, May 12, 2009 at 3:06 PM, Brett Wilson 
> >> > wrote:
> >> >>
> >> >> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain
> >> >> 
> >> >> wrote:
> >> >> > On Tue, May 12, 2009 at 2:22 PM, Stephen White
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> I'm in the process of updating chromium to use tip-of-tree skia,
> and
> >> >> >> in
> >> >> >> the same CL, moving skia to a third_party directory,
> >> >> >> retrieved via DEPS.  What this means for you:
> >> >> >
> >> >> > Hi,
> >> >> > Why do you want to move it to third party?
> >> >> > The other projects developed at google that we fetch through DEPS
> >> >> > like
> >> >> > googleurl, breakpad, gtests and courgette are all living in src,
> not
> >> >> > third_party..
> >> >> > Nicolas
> >> >>
> >> >> If our repo is not the canonical representation, they should all be
> in
> >> >> thierd party. So I think that all your examples are in the wrong
> >> >> place.
> >> >>
> >> >> Brett
> >> >
> >> >
> >> > src/courgette is the canonical representation.  we placed googleurl,
> >> > breakpad, and v8 in src and not third_party because they are developed
> >> > by
> >> > our team, so we do not have licensing / copyright concerns.
> >> > the rule we have been following is to put items in third_party that do
> >> > not
> >> > conform to our licensing or that are developed by another group.  i
> >> > think by
> >> > this measure it is correct for googleurl, breakpad, and v8 to live in
> >> > src.
> >> >  same goes for gtest.  skia seems like a borderline case to me.
> >> > the point of third_party is to make ease the job of a licensing lawyer
> >> > who
> >> > has to figure out what they need to worry about.
> >> > -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: Skia is moving

[Ben Goodger (Google)]

Really? I don't think we include anything in third_party using
third_party in the include path - or is this not what you mean by
"pain"?

-Ben

On Wed, May 13, 2009 at 12:32 PM, Darin Fisher  wrote:
> I think that's a good point, and it would make for a much easier to
> understand and enforce policy.  It means some potential pain if we ever wish
> to fork a top-level directory off into a separate opensource project.
> -Darin
>
> On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) 
> wrote:
>>
>> I do think this distinction is fairly arbitrary in the world of open
>> source projects. It is not hard to imagine a time when some of these
>> dependencies may have more non-Google contributors than Googlers. It
>> is also possible that licensing may change over time.
>>
>> In addition, it makes it harder to distinguish what top level dirs we
>> have that aren't provided by deps.
>>
>> My personal preference is that everything that isn't hosted in our
>> repo goes into third_party regardless of whether its license agrees
>> with ours at this moment.
>>
>> -Ben
>>
>> On Tue, May 12, 2009 at 3:55 PM, Darin Fisher  wrote:
>> > On Tue, May 12, 2009 at 3:06 PM, Brett Wilson 
>> > wrote:
>> >>
>> >> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain
>> >> 
>> >> wrote:
>> >> > On Tue, May 12, 2009 at 2:22 PM, Stephen White
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> I'm in the process of updating chromium to use tip-of-tree skia, and
>> >> >> in
>> >> >> the same CL, moving skia to a third_party directory,
>> >> >> retrieved via DEPS.  What this means for you:
>> >> >
>> >> > Hi,
>> >> > Why do you want to move it to third party?
>> >> > The other projects developed at google that we fetch through DEPS
>> >> > like
>> >> > googleurl, breakpad, gtests and courgette are all living in src, not
>> >> > third_party..
>> >> > Nicolas
>> >>
>> >> If our repo is not the canonical representation, they should all be in
>> >> thierd party. So I think that all your examples are in the wrong
>> >> place.
>> >>
>> >> Brett
>> >
>> >
>> > src/courgette is the canonical representation.  we placed googleurl,
>> > breakpad, and v8 in src and not third_party because they are developed
>> > by
>> > our team, so we do not have licensing / copyright concerns.
>> > the rule we have been following is to put items in third_party that do
>> > not
>> > conform to our licensing or that are developed by another group.  i
>> > think by
>> > this measure it is correct for googleurl, breakpad, and v8 to live in
>> > src.
>> >  same goes for gtest.  skia seems like a borderline case to me.
>> > the point of third_party is to make ease the job of a licensing lawyer
>> > who
>> > has to figure out what they need to worry about.
>> > -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: Skia is moving

[Darin Fisher]

I think that's a good point, and it would make for a much easier to
understand and enforce policy.  It means some potential pain if we ever wish
to fork a top-level directory off into a separate opensource project.
-Darin


On Wed, May 13, 2009 at 10:56 AM, Ben Goodger (Google) wrote:

> I do think this distinction is fairly arbitrary in the world of open
> source projects. It is not hard to imagine a time when some of these
> dependencies may have more non-Google contributors than Googlers. It
> is also possible that licensing may change over time.
>
> In addition, it makes it harder to distinguish what top level dirs we
> have that aren't provided by deps.
>
> My personal preference is that everything that isn't hosted in our
> repo goes into third_party regardless of whether its license agrees
> with ours at this moment.
>
> -Ben
>
> On Tue, May 12, 2009 at 3:55 PM, Darin Fisher  wrote:
> > On Tue, May 12, 2009 at 3:06 PM, Brett Wilson 
> wrote:
> >>
> >> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain  >
> >> wrote:
> >> > On Tue, May 12, 2009 at 2:22 PM, Stephen White
> >> > 
> >> > wrote:
> >> >>
> >> >> I'm in the process of updating chromium to use tip-of-tree skia, and
> in
> >> >> the same CL, moving skia to a third_party directory,
> >> >> retrieved via DEPS.  What this means for you:
> >> >
> >> > Hi,
> >> > Why do you want to move it to third party?
> >> > The other projects developed at google that we fetch through DEPS like
> >> > googleurl, breakpad, gtests and courgette are all living in src, not
> >> > third_party..
> >> > Nicolas
> >>
> >> If our repo is not the canonical representation, they should all be in
> >> thierd party. So I think that all your examples are in the wrong
> >> place.
> >>
> >> Brett
> >
> >
> > src/courgette is the canonical representation.  we placed googleurl,
> > breakpad, and v8 in src and not third_party because they are developed by
> > our team, so we do not have licensing / copyright concerns.
> > the rule we have been following is to put items in third_party that do
> not
> > conform to our licensing or that are developed by another group.  i think
> by
> > this measure it is correct for googleurl, breakpad, and v8 to live in
> src.
> >  same goes for gtest.  skia seems like a borderline case to me.
> > the point of third_party is to make ease the job of a licensing lawyer
> who
> > has to figure out what they need to worry about.
> > -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: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[Matt Perry]

Cookies will not help user scripts, but they will help you with toolstrips
and background pages.  Both of the latter pages run in an extension process
under a common origin, so you can access your extension's cookies from those
contexts just fine.  You'd need to use the content script communication if
you need to inform content scripts about stored settings, though.
(Note that cookie support is not in yet.)

2009/5/13 jack 

> Hi Nick,
>
> Thanks for your feedback. My understanding is that Chrome is actively
> working on an official user preference system based on HTML 5 local
> storage. In the meantime, I was suggested trying bookmarks as a
> workaround. I haven't tried the new release yet, but in last week it
> didn't work out because it seemed the communication between the
> content script and extension (namely chromium.extension.connect()
> blabla) was not ready yet. As for cookie, unless I missed sth, I think
> it is not a decent solution because of its strict security/domain
> restriction (to keep in mind user preference should work browser-wide
> instead of domain-wide).
>
> Any comments are welcome.
>
> -Jack
>
> On May 13, 8:16 am, Nick Baum  wrote:
> > Hey Jack,
> >
> > This is super cool, thanks for sharing!
> >
> > Matt (cc'd) is working on letting extensions store cookies. Is that what
> > you're missing?
> >
> > Cheers,
> >
> > -Nick
> >
> > 2009/5/12 jack 
> >
> >
> >
> > > Thanks for your feedback and glad to know it worked for you. Your
> > > guess is correct. Although such features are OK in Cleeki's IE/Firefox
> > > addons, I haven't figure out a way for Chrome yet. I tried the trick
> > > using bookmarking and script/extension communication but it didn't
> > > work so far. If anybody here knows how to do this, I'd love to know
> > > and integrate it into the add-on.
> >
> > > -Jack
> >
> > > On 5月12日, 下午10时11分, PhistucK  wrote:
> > > > Works for me. The IE8 Accelerator importing and the preferences work
> only
> > > in
> > > > the corresponding pages, because the lack of Extensions cookie
> support, I
> > > > assume, right?
> > > > Great job!
> >
> > > > ☆PhistucK
> >
> > > > On Tue, May 12, 2009 at 20:47, jack  wrote:
> >
> > > > > I recently migrated the Firefox add-on, called Cleeki, into Google
> > > > > Chrome. Cleeki can be used as Google Chrome's Accelerators, only
> > > > > superior to IE8 accelerators. Basically you select any text to
> search/
> > > > > share/publish on the Internet, and preview the results in the same
> > > > > page instantly.
> >
> > > > > Installation guideline:http://blog.cleeki.com/?p=70
> > > > > A quick overview:http://blog.cleeki.com/?p=112
> >
> > > > > Based on the discussion last week, there is a known issue in
> current
> > > > > Chrome that the first page might not load the add-on script. Also
> > > > > there is no (easy) user customization yet because of the lack of an
> > > > > official user preference system. I would like to share the add-on
> in
> > > > > this community in case it is helpful for testing any new release of
> > > > > Chrome. I will actively test it in the up-to-date Chrome and report
> > > > > any bugs. Any of your bug reporting is also welcome. I hope when
> > > > > Chrome add-on system becomes official, this add-on will also be
> ready
> > > > > (or almost).
> >
> > > > > Thanks for your attention and any of your comments are welcome.
> >
> > > > > -Jack
>

--~--~-~--~~~---~--~~
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: Skia is moving

[Ben Goodger (Google)]

I do think this distinction is fairly arbitrary in the world of open
source projects. It is not hard to imagine a time when some of these
dependencies may have more non-Google contributors than Googlers. It
is also possible that licensing may change over time.

In addition, it makes it harder to distinguish what top level dirs we
have that aren't provided by deps.

My personal preference is that everything that isn't hosted in our
repo goes into third_party regardless of whether its license agrees
with ours at this moment.

-Ben

On Tue, May 12, 2009 at 3:55 PM, Darin Fisher  wrote:
> On Tue, May 12, 2009 at 3:06 PM, Brett Wilson  wrote:
>>
>> On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain 
>> wrote:
>> > On Tue, May 12, 2009 at 2:22 PM, Stephen White
>> > 
>> > wrote:
>> >>
>> >> I'm in the process of updating chromium to use tip-of-tree skia, and in
>> >> the same CL, moving skia to a third_party directory,
>> >> retrieved via DEPS.  What this means for you:
>> >
>> > Hi,
>> > Why do you want to move it to third party?
>> > The other projects developed at google that we fetch through DEPS like
>> > googleurl, breakpad, gtests and courgette are all living in src, not
>> > third_party..
>> > Nicolas
>>
>> If our repo is not the canonical representation, they should all be in
>> thierd party. So I think that all your examples are in the wrong
>> place.
>>
>> Brett
>
>
> src/courgette is the canonical representation.  we placed googleurl,
> breakpad, and v8 in src and not third_party because they are developed by
> our team, so we do not have licensing / copyright concerns.
> the rule we have been following is to put items in third_party that do not
> conform to our licensing or that are developed by another group.  i think by
> this measure it is correct for googleurl, breakpad, and v8 to live in src.
>  same goes for gtest.  skia seems like a borderline case to me.
> the point of third_party is to make ease the job of a licensing lawyer who
> has to figure out what they need to worry about.
> -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] gclient sync and xml.parsers.expat.ExpatError

[Evan Martin]

If you get xml.parsers.expat.ExpatError when running gclient sync,
look at the error output closely and see if there's directory it's
getting confused about.

rm -rf that directory, and sync again.  Worked for me.

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

[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[jack]

Fantástico! I will surely try it out. -jack

On May 13, 10:34 am, Aaron Boodman  wrote:
> 2009/5/13 jack :
>
> > Thanks for your feedback. My understanding is that Chrome is actively
> > working on an official user preference system based on HTML 5 local
> > storage. In the meantime, I was suggested trying bookmarks as a
> > workaround. I haven't tried the new release yet, but in last week it
> > didn't work out because it seemed the communication between the
> > content script and extension (namely chromium.extension.connect()
> > blabla) was not ready yet. As for cookie, unless I missed sth, I think
> > it is not a decent solution because of its strict security/domain
> > restriction (to keep in mind user preference should work browser-wide
> > instead of domain-wide).
>
> The content script communication stuff works in the current release.
> The name has changed to 'chrome.extension.connect()' (not chromium).
>
> - 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: Changes to FilePath?

[Greg Spencer]

(ping)
So, I had another idea.  How about a separate file path manipulation class
that has a well defined character encoding, so that we can do filename
manipulations like with FilePath (and a few more).  It could convert from a
FilePath if given an encoding, and convert back to a FilePath with the
platform's default encoding (using LC_*/LANG on Linux, falling back to
ASCII), or a given encoding.  It could touch the filesystem so that it could
know what ecoding methods and manipulations were valid for the
platform/drive combination.

Since it seems like this is not really something that Chromium needs or
wants right now (and it doesn't belong in base anyhow because of needing to
touch the filesystem), I think I'll work on this for O3D, and later you can
see if you want to use it for Chromium.

-Greg.

On Wed, Apr 29, 2009 at 3:58 PM, Greg Spencer  wrote:

> On Wed, Apr 29, 2009 at 12:22 PM, Mark Mentovai  wrote:
>
>> I understand your problem.  You're saying "I have user-supplied data
>> that I want to build a filename from," and "I have this pathname that
>> I want to display back to the user."  I agree that it would be good to
>
> have a way to handle these cases in base.  I don't know if FilePath
>> proper is the right place to do it.  If we do it in FilePath, it still
>> won't really be right.
>
>
> OK, so it sounds like you're telling me not to use FilePath to represent
> file paths from a disk for my purposes because they can't ever be converted
> reliably to a particular encoding on Linux (which is a requirement for me,
> because of the third party libraries that require a particular encoding).
>
> That's fine, but what do I do instead?  Roll my own FilePath clone that has
> some encoding assumptions?  I can do that, but it has the same issues as the
> ones you're worried about with FilePath, so it seems better to solve the
> issue in one place rather than have two versions that are both insufficient.
>  Man, it would be better if FilePath could reliably know its encoding!  (I
> realize that Linux makes this impossible, it just seems like it would be
> better that way. :-)
>
> Since Linux is the only platform where the encoding is unclear, what if we
> did the best we could on Linux:
>
> When constructing a FilePath from a char* string on Linux:
> - Test the input string for values > 127 to determine if it's really just
> ASCII (and if so, we're out of the woods).
> - Then check LANG, LC_CTYPE, LC_ALL (through appropriate Linux APIs) for an
> encoding that we can support, and note the encoding for later if we are
> requested to do a conversion.
> - If we run into an invalid sequence during a conversion, or an encoding we
> can't convert from, then use a CHECK to crash.
>
> This should work on most filenames, in almost all situations -- I'll bet
> most filenames are ASCII, even on foreign systems, and the ones that aren't
> ASCII have set LANG to something in /etc/profile, so all filenames created
> by any app running on that machine should match that encoding.
>
> Where they don't do that correctly, they're already getting garbage (and
> should expect garbage) from any application they use, not just Chrome, since
> there is no way *any *app can decode a path with multiple encodings in it,
> or where the encoding is different than LANG (or LC_*) says it is.
>
> Chrome already crashes like this when it encounters situations where it's
> just impossible to know what's right, so it's consistent with Chrome's
> behavior in other areas.
>
>
>> it should be the caller's responsibility to only deal with user-created
>> names with
>> this interface.
>
>
> What do you mean here?  Isn't that the case now with FilePath?  (It's the
> file_util routines that actually read the filesystem and make FilePaths out
> of them, afterall).  As for your suggestion to only deal with path
> components, how would you propose to parse user-supplied paths into one of
> these?
>
>
>> > 2) I'd like to make it possible to instantiate a POSIX FilePath object
>> on
>> > Windows and a Windows FilePath on POSIX platforms.  This is because some
>> > libraries (e.g. the zip library, or tar files), use POSIX semantics for
>> > their paths even on Windows (I haven't seen a use case for Windows paths
>> on
>> > POSIX yet, actually).   This would make it possible to use the nice API
>> that
>> > FilePath has to manipulate paths appropriately for these other
>> libraries.
>> > This could be easily accomplished by having POSIX and Windows versions
>> of
>> > FilePath, and then typedef'ing FilePath differently on different
>> platforms
>> > to one of these versions.
>>
>> Sounds pretty Pythonic.
>>
>> FilePath already sort of has some support for this - it does a bunch
>> of things based on feature macros, mostly so that as I was writing it,
>> I could test the Windows semantics without having to (shudder) resort
>> to running on Windows.  These could probably be adapted to do what
>> you're asking.
>
>
> Cool.
>
>
>> > 3) It would be helpful 

[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[Aaron Boodman]

2009/5/13 jack :
> Thanks for your feedback. My understanding is that Chrome is actively
> working on an official user preference system based on HTML 5 local
> storage. In the meantime, I was suggested trying bookmarks as a
> workaround. I haven't tried the new release yet, but in last week it
> didn't work out because it seemed the communication between the
> content script and extension (namely chromium.extension.connect()
> blabla) was not ready yet. As for cookie, unless I missed sth, I think
> it is not a decent solution because of its strict security/domain
> restriction (to keep in mind user preference should work browser-wide
> instead of domain-wide).

The content script communication stuff works in the current release.
The name has changed to 'chrome.extension.connect()' (not chromium).

- 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: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[Nick Baum]

Hi Jack,

We're indeed working on HTML5 local storage, which should meet your needs.
Great to see your progress on this!

-Nick

2009/5/13 jack 

> Hi Nick,
>
> Thanks for your feedback. My understanding is that Chrome is actively
> working on an official user preference system based on HTML 5 local
> storage. In the meantime, I was suggested trying bookmarks as a
> workaround. I haven't tried the new release yet, but in last week it
> didn't work out because it seemed the communication between the
> content script and extension (namely chromium.extension.connect()
> blabla) was not ready yet. As for cookie, unless I missed sth, I think
> it is not a decent solution because of its strict security/domain
> restriction (to keep in mind user preference should work browser-wide
> instead of domain-wide).
>
> Any comments are welcome.
>
> -Jack
>
> On May 13, 8:16 am, Nick Baum  wrote:
> > Hey Jack,
> >
> > This is super cool, thanks for sharing!
> >
> > Matt (cc'd) is working on letting extensions store cookies. Is that what
> > you're missing?
> >
> > Cheers,
> >
> > -Nick
> >
> > 2009/5/12 jack 
> >
> >
> >
> > > Thanks for your feedback and glad to know it worked for you. Your
> > > guess is correct. Although such features are OK in Cleeki's IE/Firefox
> > > addons, I haven't figure out a way for Chrome yet. I tried the trick
> > > using bookmarking and script/extension communication but it didn't
> > > work so far. If anybody here knows how to do this, I'd love to know
> > > and integrate it into the add-on.
> >
> > > -Jack
> >
> > > On 5月12日, 下午10时11分, PhistucK  wrote:
> > > > Works for me. The IE8 Accelerator importing and the preferences work
> only
> > > in
> > > > the corresponding pages, because the lack of Extensions cookie
> support, I
> > > > assume, right?
> > > > Great job!
> >
> > > > ☆PhistucK
> >
> > > > On Tue, May 12, 2009 at 20:47, jack  wrote:
> >
> > > > > I recently migrated the Firefox add-on, called Cleeki, into Google
> > > > > Chrome. Cleeki can be used as Google Chrome's Accelerators, only
> > > > > superior to IE8 accelerators. Basically you select any text to
> search/
> > > > > share/publish on the Internet, and preview the results in the same
> > > > > page instantly.
> >
> > > > > Installation guideline:http://blog.cleeki.com/?p=70
> > > > > A quick overview:http://blog.cleeki.com/?p=112
> >
> > > > > Based on the discussion last week, there is a known issue in
> current
> > > > > Chrome that the first page might not load the add-on script. Also
> > > > > there is no (easy) user customization yet because of the lack of an
> > > > > official user preference system. I would like to share the add-on
> in
> > > > > this community in case it is helpful for testing any new release of
> > > > > Chrome. I will actively test it in the up-to-date Chrome and report
> > > > > any bugs. Any of your bug reporting is also welcome. I hope when
> > > > > Chrome add-on system becomes official, this add-on will also be
> ready
> > > > > (or almost).
> >
> > > > > Thanks for your attention and any of your comments are welcome.
> >
> > > > > -Jack
>

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

[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[jack]

Hi Nick,

Thanks for your feedback. My understanding is that Chrome is actively
working on an official user preference system based on HTML 5 local
storage. In the meantime, I was suggested trying bookmarks as a
workaround. I haven't tried the new release yet, but in last week it
didn't work out because it seemed the communication between the
content script and extension (namely chromium.extension.connect()
blabla) was not ready yet. As for cookie, unless I missed sth, I think
it is not a decent solution because of its strict security/domain
restriction (to keep in mind user preference should work browser-wide
instead of domain-wide).

Any comments are welcome.

-Jack

On May 13, 8:16 am, Nick Baum  wrote:
> Hey Jack,
>
> This is super cool, thanks for sharing!
>
> Matt (cc'd) is working on letting extensions store cookies. Is that what
> you're missing?
>
> Cheers,
>
> -Nick
>
> 2009/5/12 jack 
>
>
>
> > Thanks for your feedback and glad to know it worked for you. Your
> > guess is correct. Although such features are OK in Cleeki's IE/Firefox
> > addons, I haven't figure out a way for Chrome yet. I tried the trick
> > using bookmarking and script/extension communication but it didn't
> > work so far. If anybody here knows how to do this, I'd love to know
> > and integrate it into the add-on.
>
> > -Jack
>
> > On 5月12日, 下午10时11分, PhistucK  wrote:
> > > Works for me. The IE8 Accelerator importing and the preferences work only
> > in
> > > the corresponding pages, because the lack of Extensions cookie support, I
> > > assume, right?
> > > Great job!
>
> > > ☆PhistucK
>
> > > On Tue, May 12, 2009 at 20:47, jack  wrote:
>
> > > > I recently migrated the Firefox add-on, called Cleeki, into Google
> > > > Chrome. Cleeki can be used as Google Chrome's Accelerators, only
> > > > superior to IE8 accelerators. Basically you select any text to search/
> > > > share/publish on the Internet, and preview the results in the same
> > > > page instantly.
>
> > > > Installation guideline:http://blog.cleeki.com/?p=70
> > > > A quick overview:http://blog.cleeki.com/?p=112
>
> > > > Based on the discussion last week, there is a known issue in current
> > > > Chrome that the first page might not load the add-on script. Also
> > > > there is no (easy) user customization yet because of the lack of an
> > > > official user preference system. I would like to share the add-on in
> > > > this community in case it is helpful for testing any new release of
> > > > Chrome. I will actively test it in the up-to-date Chrome and report
> > > > any bugs. Any of your bug reporting is also welcome. I hope when
> > > > Chrome add-on system becomes official, this add-on will also be ready
> > > > (or almost).
>
> > > > Thanks for your attention and any of your comments are welcome.
>
> > > > -Jack
--~--~-~--~~~---~--~~
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: Skia is moving

[Darin Fisher]

Nice work Stephen!!-Darin

On Wed, May 13, 2009 at 9:03 AM, Stephen White wrote:

> Ok, the Skia move is done.
> I've had some reports that you need to clean/rebuild skia.lib, but that a
> full clobber is not necessary.
>
> Thanks to maruel, thomasvl, and nsylvain for helping out with mop-up.
>
> Let me know if you have any further problems.
>
> Stephen
>
> On Tue, May 12, 2009 at 5:22 PM, Stephen White 
> wrote:
>
>> I'm in the process of updating chromium to use tip-of-tree skia, and in
>> the same CL, moving skia to a third_party directory,  retrieved via DEPS.
>>  What this means for you:
>> 1)  Any outstanding CL's in which you've added #include
>> "skia/include/..." will have to be changed to the corresponding
>> path in "third_party/skia/include/..." (be warned that the subdirectory
>> layout is also slightly different).
>> 2)  Going forward, any changes to skia will have to be done via commits to
>> skia.googlecode.com, and then rolling DEPS in chromium (much the same as
>> we now do for WebKit).
>> 3)  The new version of skia appears to render rects whose coordinates are
>> "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled.  There
>> were a couple obvious instances of this in the code which I fixed, but there
>> may be more.
>>
>> After this change, the local skia directory will contain only .gyp files,
>> ext/ (chromium-specific skia utilities), and config/ (new
>> directory, containing SkUserConfig.h).  Everything else will live in
>> third_party/skia.
>>
>> There were ~35 layout test failures due to minor pixel differences which I
>> rebaselined on Windows and Linux, and 8 genuine failures related to masks
>> and stroked text, which I have put in text_expectations.txt and assigned to
>> myself.  (There was another change which broke ~1700 tests on each platform,
>> but I put that change behind an #ifdef for now).
>>
>> Unless I hear otherwise, I'm planning to do this Wednesday morning, 10AM
>> EST (7AM PST).
>>
>> Stephen
>>
>> --
>> All truth passes through three stages. First, it is ridiculed. Second, it
>> is violently opposed. Third, it is accepted as being self-evident. --
>> Schopenhauer
>>
>
>
>
> --
> All truth passes through three stages. First, it is ridiculed. Second, it
> is violently opposed. Third, it is accepted as being self-evident. --
> Schopenhauer
>
> >
>

--~--~-~--~~~---~--~~
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: Skia is moving

[Stephen White]

Ok, the Skia move is done.
I've had some reports that you need to clean/rebuild skia.lib, but that a
full clobber is not necessary.

Thanks to maruel, thomasvl, and nsylvain for helping out with mop-up.

Let me know if you have any further problems.

Stephen

On Tue, May 12, 2009 at 5:22 PM, Stephen White wrote:

> I'm in the process of updating chromium to use tip-of-tree skia, and in the
> same CL, moving skia to a third_party directory, retrieved via DEPS.  What
> this means for you:
> 1)  Any outstanding CL's in which you've added #include
> "skia/include/..." will have to be changed to the corresponding
> path in "third_party/skia/include/..." (be warned that the subdirectory
> layout is also slightly different).
> 2)  Going forward, any changes to skia will have to be done via commits to
> skia.googlecode.com, and then rolling DEPS in chromium (much the same as
> we now do for WebKit).
> 3)  The new version of skia appears to render rects whose coordinates are
> "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled.  There
> were a couple obvious instances of this in the code which I fixed, but there
> may be more.
>
> After this change, the local skia directory will contain only .gyp files,
> ext/ (chromium-specific skia utilities), and config/ (new
> directory, containing SkUserConfig.h).  Everything else will live in
> third_party/skia.
>
> There were ~35 layout test failures due to minor pixel differences which I
> rebaselined on Windows and Linux, and 8 genuine failures related to masks
> and stroked text, which I have put in text_expectations.txt and assigned to
> myself.  (There was another change which broke ~1700 tests on each platform,
> but I put that change behind an #ifdef for now).
>
> Unless I hear otherwise, I'm planning to do this Wednesday morning, 10AM
> EST (7AM PST).
>
> Stephen
>
> --
> All truth passes through three stages. First, it is ridiculed. Second, it
> is violently opposed. Third, it is accepted as being self-evident. --
> Schopenhauer
>



-- 
All truth passes through three stages. First, it is ridiculed. Second, it is
violently opposed. Third, it is accepted as being self-evident. --
Schopenhauer

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

[chromium-dev] Re: Chrome's Accelerators (alternative to IE8 Accelerators) is here

[Nick Baum]

Hey Jack,

This is super cool, thanks for sharing!

Matt (cc'd) is working on letting extensions store cookies. Is that what
you're missing?

Cheers,

-Nick

2009/5/12 jack 

>
> Thanks for your feedback and glad to know it worked for you. Your
> guess is correct. Although such features are OK in Cleeki's IE/Firefox
> addons, I haven't figure out a way for Chrome yet. I tried the trick
> using bookmarking and script/extension communication but it didn't
> work so far. If anybody here knows how to do this, I'd love to know
> and integrate it into the add-on.
>
> -Jack
>
> On 5月12日, 下午10时11分, PhistucK  wrote:
> > Works for me. The IE8 Accelerator importing and the preferences work only
> in
> > the corresponding pages, because the lack of Extensions cookie support, I
> > assume, right?
> > Great job!
> >
> > ☆PhistucK
> >
> >
> >
> > On Tue, May 12, 2009 at 20:47, jack  wrote:
> >
> > > I recently migrated the Firefox add-on, called Cleeki, into Google
> > > Chrome. Cleeki can be used as Google Chrome's Accelerators, only
> > > superior to IE8 accelerators. Basically you select any text to search/
> > > share/publish on the Internet, and preview the results in the same
> > > page instantly.
> >
> > > Installation guideline:http://blog.cleeki.com/?p=70
> > > A quick overview:http://blog.cleeki.com/?p=112
> >
> > > Based on the discussion last week, there is a known issue in current
> > > Chrome that the first page might not load the add-on script. Also
> > > there is no (easy) user customization yet because of the lack of an
> > > official user preference system. I would like to share the add-on in
> > > this community in case it is helpful for testing any new release of
> > > Chrome. I will actively test it in the up-to-date Chrome and report
> > > any bugs. Any of your bug reporting is also welcome. I hope when
> > > Chrome add-on system becomes official, this add-on will also be ready
> > > (or almost).
> >
> > > Thanks for your attention and any of your comments are welcome.
> >
> > > -Jack
> >
>

--~--~-~--~~~---~--~~
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 application has failed to start because pywintypes24.dll was not found.

[Marc-Antoine Ruel]

If you get this error, just delete depot_tools\python.bat and it will
be fine on the next execution.

M-A

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