[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
On Aug 23, 3:18 am, Evan Martin e...@chromium.org wrote: It's already the case that if a page grabs a key it overrides the Chrome shortcut, so this would actually work properly with no additional effort. In that case, the issue is that the menu shortcuts won't work reliably, which (1) can get quite frustrating because you never really know what a shortcut will do and (2) leads to the menus or other core functionality remaining inaccessible in case of a clash. Unfortunately for people relying (or even having to rely) on the keyboard, most browsers get this wrong. The solution I had envisioned for Firefox was to clearly separate chrome and content shortcuts depending on the modifier: Alt+Shift +key only for content and Alt+key and Ctrl+(Shift+)key only for chrome. At least the first part has been implemented in Firefox 2.0. For Chrome, being mostly about content, we could easily concede Alt +key to content and instead use a different modifier for accessing the menu buttons (since they're not real menus anyway, the platform consistency argument doesn't necessarily trump other arguments) such as Alt+Shift+key which we already use for accessing the toolbars. The Ctrl+key shortcuts should however remain restricted to Chrome, so that webpages can't e.g. prevent you from closing a tab with Ctrl+W (not sure how somebody without a mouse could currently get away from such a webpage at all). --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
On Aug 23, 2:45 am, Peter Kasting pkast...@google.com wrote: At least IE and Firefox already map this, so I don't think this is a big loss for web pages. It isn't a loss for web pages but for users relying on the keyboard (think handicapped users or netbook users without a proper mouse). And as I said: Firefox actually prevents the clash by using Alt+Shift +accesskey for content. --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
Are you saying a website cannot use such combination as well? (Alt+Shift+AccessKey) ☆PhistucK On Sun, Aug 23, 2009 at 10:00, zeniko zen...@gmail.com wrote: On Aug 23, 2:45 am, Peter Kasting pkast...@google.com wrote: At least IE and Firefox already map this, so I don't think this is a big loss for web pages. It isn't a loss for web pages but for users relying on the keyboard (think handicapped users or netbook users without a proper mouse). And as I said: Firefox actually prevents the clash by using Alt+Shift +accesskey for content. --~--~-~--~~~---~--~~ 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 / Google Summer of Code
On Sat, Aug 22, 2009 at 07:31, Lei Zhangthes...@chromium.org wrote: With the Google Summer of Code program winding down, I'm curious how our GSoC participants are doing. Can the students and their mentors share their experiences? (Assuming you're all done with evaluations and all that.) My project was 'Forging a better Cr on Linux', and Dean was my mentor. I had an eye on doing performance/memory usage work motivated by my attempts to run Chromium on the Beagleboard; an ARM system with 128MB of RAM. Chromium works and you can come along to OSDC (http://2009.osdc.com.au) for my talk There's something on my ARM for all the details :) I didn't get as much done as I would have liked as I was attending classes and sitting exams throughout my Summer of Code, a downside of being a student from the southern hemisphere. This means I'm going to stick around the project to continue working on things I'm interested in. (For my record as much as anyone else) here is a summary of the patches I wrote, in chronological order: == Scale backing store cache size == This would scale the number of DIBs stored based on the system RAM. It's since been replaced by a more complex algorithm. == Set process name on Linux == This was to help distinguish the renderer from the browser (and the zygote, which was just appearing at the time). It was reverted as it broke the UI tests which iterate over the process name. I did not resubmit as 'ps f' provides the same information for less lines of code. == Jankfs == An idea Dean had; write a FUSE filesystem to simluate slow and unreliable storage. See http://groups.google.com/group/chromium-dev/browse_thread/thread/59b0440255c87ed3 == ARM build == The tree had built for ARM at some point in the past but had since bitrotted. I went through building a toolchain, and then a root filesystem, and found 3 gcc ICE (internal compiler errors) on the way. I then made a bunch of changes in working towards building and running Chromium on the Beagleboard: * Hide x86 assembly in the seccomp and chroot sandboxes from the ARM build * A Skia build fix * v8 patch for targeting the ARMv7 Cortex-A8 (found on the beagleboard) * Most significantly, re-wrote v8.gyp to make cross-compiling possible For instructions on building see http://code.google.com/p/chromium/wiki/LinuxChromiumArm == Memory usage in task manager on Linux == Calculates the memory usage of each process. This is committed and working, but the API needs to be re-worked to be less Windows-like before about:memory is ready for Linux. See http://codereview.chromium.org/159777 == Fix proxy settings for Gnome =2.26 == Newer versions of Gnome use a different binary name, this made the Change proxy settings button work for both. == Add ctrl+w accelerator to close bookmark manager for linux == == Fix PR_ImplodeTime for Linux x64 == This was one of the last patches to make the chrome tree compile for x64 without patches, building on Dean's work. Beware the 2038 bug. == One liners == * gcc-4.3 / 4.4 build fixes * gitignore updates * window icons According to the logs I wrote 22 patches. Despite having been around open source projects for a number of years, Chroimum's development process taught me many new things. Having code review for all changes made was a new to me, and line by line review is great at ensuring I got detailed feedback. Dean's mentoring was the most valuable part of the experience. He was great at answering questions and explaining the concepts I was not familiar with. Having the ability to communicate via IM made this very easy and I would encourage mentors and students to follow this setup in future years. Thanks to Dean for mentoring me, and everyone else who reviewed and committed my patches. Cheers, Joel --~--~-~--~~~---~--~~ 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: Handling layout test expectations for failing tests
On Sat, Aug 22, 2009 at 9:51 PM, Jeremy Orlowjor...@chromium.org wrote: It might be worth going through all the LayoutTest bugs and double check they're split up into individual root causes (or something approximating that). I'll try to make time to do a scan in the next week or so, but it'd be great if anyone else had time to help. :-) I've been doing this last week. Maybe we could figure out how to do this in parallel on Monday? :DG --~--~-~--~~~---~--~~ 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: Access keys for Chrome menus, what do you prefer?
On Sat, Aug 22, 2009 at 11:57 PM, zeniko zen...@gmail.com wrote: In that case, the issue is that the menu shortcuts won't work reliably, which (1) can get quite frustrating because you never really know what a shortcut will do and (2) leads to the menus or other core functionality remaining inaccessible in case of a clash. We already have this since web pages take over things like ctrl-w and ctrl-f (and we wouldn't want to change that since in many cases it's important that they do so). The solution I had envisioned for Firefox was to clearly separate chrome and content shortcuts depending on the modifier: Alt+Shift +key only for content and Alt+key and Ctrl+(Shift+)key only for chrome. At least the first part has been implemented in Firefox 2.0. Implementing the second part cannot and should not ever happen. (I don't want to discuss here, it was a long and hairy discussion that we had long ago during Chrome's early design days. Trust me when I say we really thought it through.) For Chrome, being mostly about content, we could easily concede Alt +key to content and instead use a different modifier for accessing the menu buttons (since they're not real menus anyway, the platform consistency argument doesn't necessarily trump other arguments) such as Alt+Shift+key which we already use for accessing the toolbars. If we were going to do this we should just give up. We already have alt-shit-t and that's good enough if we're going to use hard-to-find non-standard access keys. The entire point of alt, alt-f and alt-e is to pick things users will naively try to use. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
I understand the resistance to implement yet another bit of process and effort around layout tests. I really do. However, I found some merit in Dirk's idea -- it allows us to clearly see the impact of a regression. Sadly, I can't come up with a specific example at the moment, but let me pull one out of my ... hat, based on previous experiences. Let's say we had a regression in JSON parsing. But since we already fail parts of the LayoutTests/fast/js/JSON-parse.html, we wouldn't notice it. Especially with DOM bindings, there are tons of tests like this -- we pass only parts of them, so we wouldn't know when our changes or commits upstream introduce regressions that we really ought to be noticing. It's kind of like marking layout tests as flakey: there's no way to determine whether the flakiness is gone other than by recording some extra information. So to me at least, the benefit of this type of solution is not near-zero. My only hesitation comes from having to decide whether we should stop and implement this rather than dedicate all of our resources to plowing ahead in fixing layout tests and driving the number to 0 (and thus eliminating the need for this solution). :DG On Fri, Aug 21, 2009 at 6:43 PM, Ojan Vafaio...@chromium.org wrote: On Fri, Aug 21, 2009 at 4:54 PM, Peter Kasting pkast...@chromium.org wrote: On Fri, Aug 21, 2009 at 4:50 PM, Dirk Pranke dpra...@chromium.org wrote: This is all good feedback, thanks! To clarify, though: what do you think the cost will be? Perhaps you are assuming things about how I would implement this that are different than what I had in mind. Some amount of your time, and some amount of space on the bots. Also, some amount of the rest of the team's time to follow this process. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
