[chromium-dev] Re: UI proposal: Open link in new foreground tab
One way to lower the cognitive costs with additional menu options: let users customize menus. A customized menu gets an extra More... as its last option. (Tooltip suggestion: More options exist. This menu is customized.). Click to show remaining options below the fold, including Customize and perhaps Restore customization. Customize would allow moving menu options around. Hide one = move to below the fold. (Full disclusure: I'd personally like to remove any menu options I only do by keyboard, and could do with placing my few often used ones higher up in the menu :-)) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] data resources and localized strings on linux
I wrote a short design doc about handling data resources and localized strings on linux. http://sites.google.com/a/chromium.org/dev/developers/design-documents/linuxresourcesandlocalizedstrings Feedback welcome. tony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Did you move Chromium to ProgramFiles ?
If this is a common scenario, we might need to use another signal. On Dec 6, 6:25 pm, Peter Kasting [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 7:01 PM, cpu [EMAIL PROTECTED] wrote: Due to a series of changes in the last month, the app now thinks it has been installed systemwide. This could cause problems for a small set of our users who may have done this. It would be nice if we could figure things out properly so we don't cause bad side-effects, even when the user has done something we didn't expect. Then again I may have been misunderstanding your email. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: data resources and localized strings on linux
- Is the plan to mmap the data file directly? Avoids copies, but means we should (a) null terminate the string resources (maybe the rc format does this already) and (b) sort the resource entries by resource id for faster lookup. - We should make explicit the byte order for the int32s. We can't support non-x86 anyway because of v8 but it'd nice if it would at least error out during the build on big-endian platforms. - Do we care about compression? (Trading off disk accesses for CPU and memory.) Why not a zip file? On Mon, Dec 8, 2008 at 9:15 AM, [EMAIL PROTECTED] wrote: I wrote a short design doc about handling data resources and localized strings on linux. http://sites.google.com/a/chromium.org/dev/developers/design-documents/linuxresourcesandlocalizedstrings Feedback welcome. tony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: data resources and localized strings on linux
On Mon, Dec 8, 2008 at 10:40 AM, Evan Martin [EMAIL PROTECTED] wrote: - Is the plan to mmap the data file directly? Avoids copies, but means we should (a) null terminate the string resources (maybe the rc format does this already) and (b) sort the resource entries by resource id for faster lookup. Agreed, NUL terminating the strings is a good idea. Also, we should be explicit that they are UTF-8 encoded where it matters. - We should make explicit the byte order for the int32s. We can't support non-x86 anyway because of v8 but it'd nice if it would at least error out during the build on big-endian platforms. They should be unsigned, signed ints have no place as ids, sizes or offets. They should be explicitly *little* endian since it's faster on little endian machines and the same speed on most big-endian machines. - Do we care about compression? (Trading off disk accesses for CPU and memory.) Why not a zip file? Given that text generally compresses well, this would be reasonable although I don't feel strongly about it. Throw it via zlib if need be. AGL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: build issue: File src\chrome\app\theme\google_chrome\BRANDING is missing
On 8 déc, 09:24, [EMAIL PROTECTED] wrote: You need to run a gclient sync rather than an svn update. You won't get all the necessary dependencies with just an svn update. See the end of http://dev.chromium.org/developers/how-tos/get-the-code Forgot the gclient part (took 4 hours to download the tarball, I kind of forgot about it). Did you set the CHROMIUM_BUILD environment variable before you started the hammer build? It sounds like you're trying to compile the official Google Chrome branded version. If you leave the CHROMIUM_BUILD environment variable blank, this shouldn't happen. I no longer get the resource error. Seems the gclient fixed that. The page http://dev.chromium.org/developers/how-tos/build-instructions-windows does make any reference to that variable. What should it be set to ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: data resources and localized strings on linux
All good points. I've added notes about null terminating the strings, little endian byte order, and utf8 encoding. zip or zlib or bzip compression may speed load time. I'm not sure, but I think that would be an iteration we add later. It probably wouldn't help with the theme .so file, but it might help with the locale .so. Seems like something we should profile later. On Mon, 8 Dec 2008, Adam Langley wrote: On Mon, Dec 8, 2008 at 10:40 AM, Evan Martin [EMAIL PROTECTED] wrote: - Is the plan to mmap the data file directly? Avoids copies, but means we should (a) null terminate the string resources (maybe the rc format does this already) and (b) sort the resource entries by resource id for faster lookup. Agreed, NUL terminating the strings is a good idea. Also, we should be explicit that they are UTF-8 encoded where it matters. - We should make explicit the byte order for the int32s. We can't support non-x86 anyway because of v8 but it'd nice if it would at least error out during the build on big-endian platforms. They should be unsigned, signed ints have no place as ids, sizes or offets. They should be explicitly *little* endian since it's faster on little endian machines and the same speed on most big-endian machines. - Do we care about compression? (Trading off disk accesses for CPU and memory.) Why not a zip file? Given that text generally compresses well, this would be reasonable although I don't feel strongly about it. Throw it via zlib if need be. AGL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: data resources and localized strings on linux
Fast question, have you think about adding checksum? On Dec 8, 12:15 pm, [EMAIL PROTECTED] wrote: I wrote a short design doc about handling data resources and localized strings on linux. http://sites.google.com/a/chromium.org/dev/developers/design-document... Feedback welcome. tony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] New Find Bar ownership/hookup design doc
I've been contemplating and prototyping some changes to the way the Find Bar is attached and owned relative to other objects in the Browser UI. To describe what I am thinking I've put together a design doc: http://dev.chromium.org/developers/design-documents/find-bar Please reply with any feedback. -Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Extending Value with std::string support
On Mon, Dec 8, 2008 at 5:28 PM, Andrew Scherkus [EMAIL PROTECTED]wrote: 1) Overload CreateStringValue, GetAsString, etc.. to also accept std::string. Add TYPE_UTF8_STRING to ValueType enum. 2) Overload CreateStringValue, GetAsString, etc.. to also accept std::string. TYPE_STRING becomes TYPE_WIDE_STRING and TYPE_STRING refers to std::string. Are narrow strings always going to be UTF-8? If so, maybe TYPE_UTF8_STRING and TYPE_UTF16_STRING (or is it TYPE_UCS2_STRING?) make the most sense? It would be nice to be explicit. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Extending Value with std::string support
On Mon, Dec 8, 2008 at 7:50 PM, Peter Kasting [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 6:41 PM, Andrew Scherkus [EMAIL PROTECTED] wrote: Darin touched upon this, who said to document that std::string should refer to UTF-8 strings. How about: - CreateStringValue creates a StringValue object that returns TYPE_UTF8_STRING and has a DCHECK(IsStringUTF8(foo)) in the constructor - CreateWideStringValue creates a WideStringValue object that returns TYPE_UTF16_STRING To be honest, I probably lean more toward a single overloaded CreateStringValue(). I think having different function names decreases clarity and increases verbosity. But it's not a big deal. However, if you go with two names, make the names match the TYPE_ returns: CreateUTF8StringValue() and CreateUTF16StringValue(), or something. Be careful because wstring != UTF16String. In other places of the code, we use GetWString, which if you're returning a wstring, I think is the best naming convention (since wstring changes type depending on the platform). Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Extending Value with std::string support
Somewhat in line with the Google style guide, the overloaded CreateStringValue/GetString do accomplish the same thing (variant string type), just with different encodings. I did some partial implementations of #3 and as Peter highlighted, writing GetWideString everywhere started looking really silly. In terms of enums and implementation, would TYPE_STRING and TYPE_WSTRING suffice with documentation and DCHECKs for UTF-8 std::strings? On Mon, Dec 8, 2008 at 8:09 PM, Brett Wilson [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 7:50 PM, Peter Kasting [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 6:41 PM, Andrew Scherkus [EMAIL PROTECTED] wrote: Darin touched upon this, who said to document that std::string should refer to UTF-8 strings. How about: - CreateStringValue creates a StringValue object that returns TYPE_UTF8_STRING and has a DCHECK(IsStringUTF8(foo)) in the constructor - CreateWideStringValue creates a WideStringValue object that returns TYPE_UTF16_STRING To be honest, I probably lean more toward a single overloaded CreateStringValue(). I think having different function names decreases clarity and increases verbosity. But it's not a big deal. However, if you go with two names, make the names match the TYPE_ returns: CreateUTF8StringValue() and CreateUTF16StringValue(), or something. Be careful because wstring != UTF16String. In other places of the code, we use GetWString, which if you're returning a wstring, I think is the best naming convention (since wstring changes type depending on the platform). Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Extending Value with std::string support
On Mon, Dec 8, 2008 at 8:32 PM, Andrew Scherkus [EMAIL PROTECTED] wrote: Somewhat in line with the Google style guide, the overloaded CreateStringValue/GetString do accomplish the same thing (variant string type), just with different encodings. I did some partial implementations of #3 and as Peter highlighted, writing GetWideString everywhere started looking really silly. In terms of enums and implementation, would TYPE_STRING and TYPE_WSTRING suffice with documentation I'm happy with that. and DCHECKs for UTF-8 std::strings? What is the source of the data? We normally don't bother verifying the encoding because that be very clumsy. But depending on the source, this may be helpful. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Extending Value with std::string support
On Mon, Dec 8, 2008 at 8:53 PM, Brett Wilson [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 8:32 PM, Andrew Scherkus [EMAIL PROTECTED] wrote: Somewhat in line with the Google style guide, the overloaded CreateStringValue/GetString do accomplish the same thing (variant string type), just with different encodings. I did some partial implementations of #3 and as Peter highlighted, writing GetWideString everywhere started looking really silly. In terms of enums and implementation, would TYPE_STRING and TYPE_WSTRING suffice with documentation I'm happy with that. and DCHECKs for UTF-8 std::strings? What is the source of the data? We normally don't bother verifying the encoding because that be very clumsy. But depending on the source, this may be helpful. The biggest user I've come across is JSONReader and JSONWriter. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
