Bugzilla – Full Text Bug Listing
| Summary: | [KeyBindings] Problem with F10 key in Linux environment | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | kishan <kishansaralaya> | ||||
| Component: | SWT | Assignee: | Bogdan Gheorghe <gheorghe> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipsebugs, ericwill, kishansaralaya, ljh68, nico290382, pwebster, remy.suen, shawn.t.rutledge, skarthik, vladimir.prus | ||||
| Version: | 3.2 | Keywords: | triaged | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
kishan
This is part of GTK. F10 is expected to open the first menu in the menu bar. PW (In reply to comment #1) > This is part of GTK. F10 is expected to open the first menu in the menu bar. > > > PW > Is it possible to override this behavior in eclipse IDE or in any User applications. Hi SWT. The question is, it is possible to override this behaviour. I don't even see the F10 key event in my display filter. PW kishan, I'll point out if you do figure out how to override F10, you'll be a misbehaving GTK app. PW In general, we have only some control over which keys are eaten by the Window Manager, and which ones get through to the application. F10 on GTK (and Windows and Motif), moves the focus to the first item in the menu bar. Application code should not attempt to override this behavior because users expect it. I'm tempted to close this as WONTFIX but we should investigate to get the platforms to be consistent if possible. Created attachment 63337 [details]
an RCP application which includes key binding
I am attaching an RCP application which contains 2 menu items. They are assigned F9 & F10 keys and i run this in Linux platform. The menu item which is having F9 key binding works fine but the one with F10 key binding is not working. But surprisingly it works fine in windows..... :)
It would be nice to allow overriding the F10 key behavior, especially for Visual C++ users. For debugging in Visual C++, F10 is the default "step over" key and F11 is the default "step into" key. The habit to use these two keys for step over/into is very hard to change, as in my case. Considering Visual C++'s large user base, it's a good idea to enable assigning F10 key to "step into". The end of last comment should read '... enable assigning F10 key to "step over" '. I don't care if some GTK developer capriciously decided that F10 ought to pop down some menu in every application. This is terrible for usability! F10 is not a memorable keystroke! Control-W to close a window is memorable; Control-F to Find something is memorable. All 12 of those non-descript function keys should be available for application-specific behavior, and applications like Eclipse that ostensibly allow you to change the custom key assignments for every function, ought to be able to actually work that way. (The only way the lack of memorability will be solved is when the F keys have little displays in them to show what they will do in a particular context. e.g. the Optimus keyboard) F keys have been a chafing point ever since WordPerfect for DOS back in the 1980's, if not before. (But nobody is arguing to just accept the WordPerfect standard these days, are they? despite how many people had to memorize that one.) Deciding on global standards for what the F keys will do is NOT the answer. If they were physically labeled with specific functions on every PC keyboard in the world, like e.g. the old Sun keyboards have keys for "help" and "search" and so on, that would be different; but they are not. I want my F10 to be "step over" because of years of muscle memory, dammit! I have been using Linux since about 1994 and this is the first time I've EVER heard of F10 being reserved for the File menu. And Visual Studio is not the only IDE which maps F10 to "step over", either. I don't mind if Eclipse ships with this obtuse mapping by default, but since I can remap F10 in the preferences, I very much expect it to actually obey this preference after it has been set. And I refuse to believe that would be impossible to implement. When to you plan to ever fix this? It is just wrong to hard code F keys (or any other key combo). Can REALLY be THAT hard???? (In reply to comment #11) > When to you plan to ever fix this? We're planning on looking into this. > It is just wrong to hard code F keys (or any other key combo). The accessibility folks say otherwise. > Can REALLY be THAT hard???? Let us know if disabling the GTK behaviour helps, for example from google: http://fixunix.com/debian/532717-unable-change-menubar_accel-value.html PW I don't use gnome. Further more, if I did, I would not want to change it for all applications - just this one. If users wish it otherwise, and for each one that has openly complained you can bet there are 100 or 1000s of other that just gave up, how can the "The accessibility folks say otherwise" ???? Please inform the "accessibility folks" that real user preference come before their "theoretical" considerations. It's one thing to have it default, it's quite another to disallow overriding that default. What's more, developers are a different community, and need different "accessibility" considerations. Is there any way to directly contact the accessibility team? (In reply to comment #13) > I don't use gnome. Further more, if I did, I would not want to change it for > all applications - just this one. If this functionality is important to you, try out the workaround and give us feedback. > bet there are 100 or 1000s of other that just gave up, how can the "The > accessibility folks say otherwise" ???? Please inform the "accessibility folks" Sorry, "The accessibility folks say otherwise" was a response to "It is just wrong to hard code F keys (or any other key combo).". It has no bearing on the fact that we said we would look into this. > It's one thing to have it default, it's quite another to disallow overriding > that default. What's more, developers are a different community, and need > different "accessibility" considerations. I would image that one option considered would be the ability to make F10->Menu optional, but AFAIK this is low priority. > > Is there any way to directly contact the accessibility team? > See http://wiki.eclipse.org/Platform_UI/Accessibility_Features and the "IBM Accessibility checklist" for more information. Accessibility is often defined by the platform in combination with appropriate government laws (in the case of eclipse, check with GTK+). PW FWIW, putting
gtk-menu-bar-accel = ""
in /usr/share/themes/Qt/gtk-2.0/gtkrc (which is read from ~/.gtkrc-2.0 and ~/.gtkrc-2.0-kde on my system) fixes the problem.
I'd consider this behaviour an serious out-of-box usability issue. If I am running Eclipse (a cross-platform Java application) inside KDE session, why should I care about whatever guidelines Gtk or Gnome might have? Especially if that eats up a shortcut that is likely to be useful in IDE.
(In reply to comment #15) > I'd consider this behaviour an serious out-of-box usability issue. It is a configurability issue ... not a usability issue. > If I am > running Eclipse (a cross-platform Java application) One of Eclipse's stated goal is to be a good platform citizen (the opposite of "work the same way on every platform"), and codes towards that end. We try and fix behaviours that make eclipse stand out from the other platform apps (with varying degrees of success). That being said, this is still open to consider the overriding behaviour. PW (In reply to comment #15) > FWIW, putting > > gtk-menu-bar-accel = "" > > in /usr/share/themes/Qt/gtk-2.0/gtkrc (which is read from ~/.gtkrc-2.0 and > ~/.gtkrc-2.0-kde on my system) fixes the problem. Thanks, you are right! I had already gone to the extent of labeling my keycaps to try to learn the "new" mappings but now I can go back to the familiar ones. BTW Qt Creator uses the Visual Studio mappings too. Lately I have been using it too. So it's easier to remap one tool than all the others, on multiple OSes. I believe you can define custom keybinds inside GTK themes these days, and there is support to feed this into Eclipse (i.e. have Eclipse load some custom GTK CSS with your keybinds). If this doesn't work, then I don't there is much we can do. |