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,
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
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 js2...@gmail.com
Hi Nick,
Thanks for your feedback. My understanding is that Chrome is actively
working on an official user preference system based
2009/5/13 jack js2...@gmail.com:
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
(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
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
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)
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 da...@chromium.org wrote:
I think that's a good point, and it would make for a much easier to
understand
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 da...@chromium.org
On Wed, May 13, 2009 at 12:39 PM, Darin Fisher da...@chromium.org 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
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.
Thanks for your tips, Matt. I will check the update and try your
suggestion. -jack
On May 13, 12:07 pm, Matt Perry mpcompl...@chromium.org 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
On Tue, Apr 28, 2009 at 2:47 PM, Greg Spencer gspen...@google.com wrote:
On Tue, Apr 28, 2009 at 2:41 PM, Amanda Walker ama...@chromium.orgwrote:
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com
wrote:
1) I'd like to add some explicit routines for converting to/from UTF8
OK. Will update my bug with that blocker info.
Avi
On Wed, May 13, 2009 at 2:34 PM, Scott Hess sh...@chromium.org 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
OK, so this was
r15790http://src.chromium.org/viewvc/chrome?view=revrevision=15790.
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 a...@google.com wrote:
I'm implementing save/restore focus when
On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai m...@chromium.org 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
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
On Wed, May 13, 2009 at 2:05 PM, Darin Fisher da...@chromium.org 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
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
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
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org 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
On Wed, May 13, 2009 at 7:07 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote:
Perhaps what we need is a companion to FilePath. For example:
FilePath: much as it is now, lightweight, alternative to string
manipulation.
On Wed, May 13, 2009 at 2:20 PM, Greg Spencer gspen...@google.com wrote:
On Wed, May 13, 2009 at 2:05 PM, Darin Fisher da...@chromium.org 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
On Wed, May 13, 2009 at 4:34 PM, Amanda Walker ama...@chromium.org wrote:
On Wed, May 13, 2009 at 7:07 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org wrote:
Perhaps what we need is a companion to FilePath. For example:
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
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? :~(
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 e...@chromium.org wrote:
And the award goes to...
% git log
On Wed, May 13, 2009 at 4:35 PM, Darin Fisher da...@chromium.org 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.
On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org
wrote:
Perhaps what we need is a companion to FilePath. For example:
FilePath: much as it is now, lightweight, alternative to string
On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote:
On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org
wrote:
Perhaps what we need is a companion to FilePath. For example:
On Wed, May 13, 2009 at 7:24 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 6:12 PM, Greg Spencer gspen...@google.com wrote:
On Wed, May 13, 2009 at 4:07 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker ama...@chromium.org
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 bre...@chromium.org wrote:
On Wed, May 13, 2009 at 7:24 PM, Brett
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 da...@chromium.org 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
33 matches
Mail list logo
