[chromium-dev] Re: Please announce via email when clobbers are required
Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. By the way, I forgot to mention that a change requiring a clobber was checked in yesterday (monday), so folks building on Windows will need to clobber in order to build. This has been a public service announcement :-) -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Please announce via email when clobbers are required
So how does one know if the change they checked in requires a clobber build? Dave PS I tend to do clean builds once in a while just to ensure that everything is in a good state. (I don't trust incremental builds to stay stable over several days having spent way too much time on messed builds due to non-clean state in other projects in my past.) On Tue, Dec 9, 2008 at 9:37 AM, Mike Pinkerton [EMAIL PROTECTED]wrote: Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. By the way, I forgot to mention that a change requiring a clobber was checked in yesterday (monday), so folks building on Windows will need to clobber in order to build. This has been a public service announcement :-) -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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:09 PM, Brett Wilson [EMAIL PROTECTED] wrote: Be careful because wstring != UTF16String. Yes, hence the need to be very explicit about what these functions actually do (since you can't infer things from types alone). 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). It changes type, but does it also change encoding? Basically, all I really want is for us to be as clear as possible. If the only guarantee is that the function will return a wstring (but it doesn't guarantee the encoding), then we should make that clear in the names/documentation. Same with the narrow version. 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: Please announce via email when clobbers are required
Do we need to clobber Mac builds on these announcements? (The SCons build has only needed clobbering once so far.) On Tue, Dec 9, 2008 at 9:34 AM, Mike Pinkerton [EMAIL PROTECTED] wrote: Hey everyone! Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. Why is this a big deal? The way our build is configured (at least on windows), the solution doesn't stop building if it encounters errors. As a result, you can easily spend a full hour doing a depend build (that's how long it takes on my 3yrold PC, for example) on a tree that's not very old and at the end be left with nothing but an error somewhere in the build output. Sure, you still have to pitch the build and start over, but at least you didn't waste the hour to get to this point. When you're trying to build quickly to test on other platforms, the setback is annoying and wasteful of valuable developer time. Let me know if you can think of better ways to improve this communication for everyone's benefit. Thanks! -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Please announce via email when clobbers are required
Mac did not need a clobber, nor does it generally. Windows certainly required a clobber. On Tue, Dec 9, 2008 at 12:55 PM, Evan Martin [EMAIL PROTECTED] wrote: Do we need to clobber Mac builds on these announcements? (The SCons build has only needed clobbering once so far.) On Tue, Dec 9, 2008 at 9:34 AM, Mike Pinkerton [EMAIL PROTECTED] wrote: Hey everyone! Given that clobbers are sometimes a necessary and required part of our build process, we as a team need to do a better job communicating when they're required. IRC and the waterfall are one step, but for those that don't build on all platforms every day, a passing status message may go un-noticed. As a result, I'm asking folks to please send out an email to this list when a clobber is required. Why is this a big deal? The way our build is configured (at least on windows), the solution doesn't stop building if it encounters errors. As a result, you can easily spend a full hour doing a depend build (that's how long it takes on my 3yrold PC, for example) on a tree that's not very old and at the end be left with nothing but an error somewhere in the build output. Sure, you still have to pitch the build and start over, but at least you didn't waste the hour to get to this point. When you're trying to build quickly to test on other platforms, the setback is annoying and wasteful of valuable developer time. Let me know if you can think of better ways to improve this communication for everyone's benefit. Thanks! -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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
So there's a single StringValue class, but sometimes its type is TYPE_UTF8_STRING and sometimes its type is TYPE_UTF16_STRING? So calling Value::IsType would require two checks to see what type of string it is? I think it would be easier if there was only one string type and internally it keeps track of whether to use a std::string or std::wstring (depending on which CreateString method was used). If you call GetString or GetWString, it'll do the conversion automatically if you created the string using the other type. This makes it easier for consumers of the code and shouldn't require changing any callers. On Mon, 8 Dec 2008, Andrew Scherkus 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 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
I think it would be ok to have GetString and GetAsString both be overloaded to work with std::string and std::wstring while we transition the callers. It's the same as having a single CreateStringValue that takes std::string and std::wstring. Having 2 string types is really confusing and I think it will introduce bugs where people mean to check both but only check one. On Tue, 9 Dec 2008, Andrew Scherkus wrote: Changing the callers would be a much bigger job. If switching to std::string is something we're really interested in, then I'd view this patch as a stepping stone towards reaching that goal. I've got a change ready, but it gives you a good idea on who's using StringValue right now: http://codereview.chromium.org/13230 There's already a few instances where people had to force their input to std::wstring:http://codereview.chromium.org/13230/diff/25/221?context=10 On Tue, Dec 9, 2008 at 12:07 PM, [EMAIL PROTECTED] wrote: That's fine with me as well. Internally, it's always utf8 but we would add helper methods on StringValue so you can CreateStringValue with a wstring or call GetWString. On Tue, 9 Dec 2008, Brett Wilson wrote: On Tue, Dec 9, 2008 at 10:38 AM, [EMAIL PROTECTED] wrote: So there's a single StringValue class, but sometimes its type is TYPE_UTF8_STRING and sometimes its type is TYPE_UTF16_STRING? So calling Value::IsType would require two checks to see what type of string it is? I think it would be easier if there was only one string type and internally it keeps track of whether to use a std::string or std::wstring (depending on which CreateString method was used). If you call GetString or GetWString, it'll do the conversion automatically if you created the string using the other type. This makes it easier for consumers of the code and shouldn't require changing any callers. I think value should always be std::string. That's what it reads from disk anyway. And I would advocate changing the callers (but I don't know how big a job that would be). 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
Looking through some of the code again it gets a bit scary when there's code checking for TYPE_WSTRING but not the other. So how about: CreateStringValue accepts std::string and std::wstring SetString accepts std::string and std::wstring GetString can return std::string or std::wstring and uses lazy conversion when needed We can remove the overloaded std::wstring versions when clients switch over to std::string. On Tue, Dec 9, 2008 at 1:23 PM, Peter Kasting [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 1:17 PM, [EMAIL PROTECTED] wrote: I think it would be ok to have GetString and GetAsString both be overloaded to work with std::string and std::wstring while we transition the callers. It's the same as having a single CreateStringValue that takes std::string and std::wstring. Having 2 string types is really confusing and I think it will introduce bugs where people mean to check both but only check one. I think I'm shifting to this viewpoint. Seems like just having one string type is what we want, and under the hood that type should be represented as UTF-8. I don't care much on the issue of whether we only provide a narrow getter, versus providing an AsWString getter alongside it (the latter seems like it'd be useful unless we think almost no callers should ever need this). 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 Tue, Dec 9, 2008 at 1:58 PM, Andrew Scherkus [EMAIL PROTECTED] wrote: Looking through some of the code again it gets a bit scary when there's code checking for TYPE_WSTRING but not the other. So how about: CreateStringValue accepts std::string and std::wstring SetString accepts std::string and std::wstring GetString can return std::string or std::wstring and uses lazy conversion when needed We can remove the overloaded std::wstring versions when clients switch over to std::string. Sorry to contribute to this bikeshed, but: my experience with hoping that clients will fix themselves has been that it'll never happen. Is it really so hard to globally replace callers to call a GetWString version? --~--~-~--~~~---~--~~ 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] Bookmark Added! GUI redesign ideas
The Bookmark bubble doesn't suit me, so I've made some redesign suggestions: http://sites.google.com/site/chromiumdev/bookmark-added My preference is 2A, since it avoids the unbalanced whitespace we have in the current Bookmarks bubble. Further 2A takes less vertical space, and mousing down to the Close-button is easier. Don't think so? Go ahead and ask me for a javascript prototype to get some statistics of mouse movement timing in 2A vs Original :-) 2A also removes the part Added! and changes Folder: to in, as well as demotes the Edit... button to a smaller link. I never use Edit... and maybe when the Bookmark Manager evolves that Edit... could lead to there with the current bookmark in view. Kind of like the Download bar's excellent Show in folder. If 2A is too radical, then maybe 1A isn't too much so? 1A leaves more space for lengthy translations, while 2A could need to be more flexible, maybe shrinking the textfield for name to manage with lengthy translations. Finally two quick suggestions. 1. Make the bubble appear further to the left, such that the mouse pointer will be closer to Close. 2. The name is always selected when opening the bookmark bubble and with long names you then only see the end of the name. Sometimes that can be very confusing, and I suggest making the selection such that the beginning of the textfield is in view instead of the end of it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
I think 1A is more universally correct. Daniel A. White On Tue, Dec 9, 2008 at 8:29 PM, Simon B. [EMAIL PROTECTED] wrote: The Bookmark bubble doesn't suit me, so I've made some redesign suggestions: http://sites.google.com/site/chromiumdev/bookmark-added My preference is 2A, since it avoids the unbalanced whitespace we have in the current Bookmarks bubble. Further 2A takes less vertical space, and mousing down to the Close-button is easier. Don't think so? Go ahead and ask me for a javascript prototype to get some statistics of mouse movement timing in 2A vs Original :-) 2A also removes the part Added! and changes Folder: to in, as well as demotes the Edit... button to a smaller link. I never use Edit... and maybe when the Bookmark Manager evolves that Edit... could lead to there with the current bookmark in view. Kind of like the Download bar's excellent Show in folder. If 2A is too radical, then maybe 1A isn't too much so? 1A leaves more space for lengthy translations, while 2A could need to be more flexible, maybe shrinking the textfield for name to manage with lengthy translations. Finally two quick suggestions. 1. Make the bubble appear further to the left, such that the mouse pointer will be closer to Close. 2. The name is always selected when opening the bookmark bubble and with long names you then only see the end of the name. Sometimes that can be very confusing, and I suggest making the selection such that the beginning of the textfield is in view instead of the end of it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
One nice thing about the current design (which 1A preserves) is that it's easy to remove an accidentally added bookmark - the remove link is in a consistent easy to view/click spot (upper right, don't have to hunt for it). Mock 2B also preserves this property, but to a lesser extent; lower left is a bit less easy to find as I have to mentally parse the bubble to find its lower border. On Tue, Dec 9, 2008 at 5:29 PM, Simon B. [EMAIL PROTECTED] wrote: The Bookmark bubble doesn't suit me, so I've made some redesign suggestions: http://sites.google.com/site/chromiumdev/bookmark-added My preference is 2A, since it avoids the unbalanced whitespace we have in the current Bookmarks bubble. Further 2A takes less vertical space, and mousing down to the Close-button is easier. Don't think so? Go ahead and ask me for a javascript prototype to get some statistics of mouse movement timing in 2A vs Original :-) 2A also removes the part Added! and changes Folder: to in, as well as demotes the Edit... button to a smaller link. I never use Edit... and maybe when the Bookmark Manager evolves that Edit... could lead to there with the current bookmark in view. Kind of like the Download bar's excellent Show in folder. If 2A is too radical, then maybe 1A isn't too much so? 1A leaves more space for lengthy translations, while 2A could need to be more flexible, maybe shrinking the textfield for name to manage with lengthy translations. Finally two quick suggestions. 1. Make the bubble appear further to the left, such that the mouse pointer will be closer to Close. 2. The name is always selected when opening the bookmark bubble and with long names you then only see the end of the name. Sometimes that can be very confusing, and I suggest making the selection such that the beginning of the textfield is in view instead of the end of it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: UI proposal: Open link in new foreground tab
Or go by the old maxim every preference is the remnant of an unresolved design question :-). On Tue, Dec 9, 2008 at 7:20 PM, Ben Goodger (Google) [EMAIL PROTECTED]wrote: On Tue, Dec 9, 2008 at 4:14 PM, Glen Murphy [EMAIL PROTECTED] wrote: It would be nice if for every preference we added, we took one out. For every preference we add, we should take two out :D -Ben -- --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
Also, as always, aesthetics play a part. Aspect ratio and balance are important considerations. The current Bookmark bubble isn't perfect, but I feel the aspect ratio is pretty good. -Ben On Tue, Dec 9, 2008 at 5:38 PM, Glen Murphy [EMAIL PROTECTED] wrote: I'm about to head out, sorry for the brevity: The original bookmark bubble attempts to keep the flow of user action in a straight line, so that a user who presses the star then knows that they next look at the title, then the folder, then the close button (you can see an imaginary diagonal line joining the star to the close button). This visual hierarchy makes the steps (and side-steps) clearer, and it's something we're keen to maintain and push further. I'd love to see if you have any mocks that incorporate your thoughts while preserving or improving this flow. ~ Glen On Tue, Dec 9, 2008 at 5:29 PM, Simon B. [EMAIL PROTECTED] wrote: The Bookmark bubble doesn't suit me, so I've made some redesign suggestions: http://sites.google.com/site/chromiumdev/bookmark-added My preference is 2A, since it avoids the unbalanced whitespace we have in the current Bookmarks bubble. Further 2A takes less vertical space, and mousing down to the Close-button is easier. Don't think so? Go ahead and ask me for a javascript prototype to get some statistics of mouse movement timing in 2A vs Original :-) 2A also removes the part Added! and changes Folder: to in, as well as demotes the Edit... button to a smaller link. I never use Edit... and maybe when the Bookmark Manager evolves that Edit... could lead to there with the current bookmark in view. Kind of like the Download bar's excellent Show in folder. If 2A is too radical, then maybe 1A isn't too much so? 1A leaves more space for lengthy translations, while 2A could need to be more flexible, maybe shrinking the textfield for name to manage with lengthy translations. Finally two quick suggestions. 1. Make the bubble appear further to the left, such that the mouse pointer will be closer to Close. 2. The name is always selected when opening the bookmark bubble and with long names you then only see the end of the name. Sometimes that can be very confusing, and I suggest making the selection such that the beginning of the textfield is in view instead of the end of it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
Hi Simon, Thanks for the thoughtful mocks. I like the overall feel of the more horizontal versions better for some reason. However, I also like having the Remove link in the upper right. I think of it somewhat like a close box for the bookmark, and I expect its placement to be in the same place. I also kind of expect the close box to be in the lower right, since that's usually where the OK button is in a dialog box. 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: Bookmark Added! GUI redesign ideas
I do like how the horizontal versions give you extra typing room and have a bit of the long horizontal look of the tab bar, omnibox bar and bookmark bar. Just my $0.02! Andrew On Tue, Dec 9, 2008 at 6:30 PM, Brett Wilson [EMAIL PROTECTED] wrote: Hi Simon, Thanks for the thoughtful mocks. I like the overall feel of the more horizontal versions better for some reason. However, I also like having the Remove link in the upper right. I think of it somewhat like a close box for the bookmark, and I expect its placement to be in the same place. I also kind of expect the close box to be in the lower right, since that's usually where the OK button is in a dialog box. 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: Bookmark Added! GUI redesign ideas
For keyboard users, the most natural flow is in 1A, I would say. Presenting the keyboard (and potentially screen reader) user with the 'Close' button before the edit options might lead many of those users astray. The discoverability here would be (as always with these types of users) top-to-bottom, left-to-right. - Jonas On 12/9/08, Andrew Scherkus [EMAIL PROTECTED] wrote: I do like how the horizontal versions give you extra typing room and have a bit of the long horizontal look of the tab bar, omnibox bar and bookmark bar. Just my $0.02! Andrew On Tue, Dec 9, 2008 at 6:30 PM, Brett Wilson [EMAIL PROTECTED] wrote: Hi Simon, Thanks for the thoughtful mocks. I like the overall feel of the more horizontal versions better for some reason. However, I also like having the Remove link in the upper right. I think of it somewhat like a close box for the bookmark, and I expect its placement to be in the same place. I also kind of expect the close box to be in the lower right, since that's usually where the OK button is in a dialog box. 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 -~--~~~~--~~--~--~---
