Hi! I've been using the IceWM window manager and just switching to Xfce because it's really nice and straightforward. However, one thing I got used to in IceWM is its keyboard-accessibility (basically everything can be done via the keyboard). So now in Xfce I am missing an integral part of my regular workflow: Opening applications from the panel menu by pressing their first (or some other unique) letter. Global shortcuts would pretty much clutter my keyboard namespace and I don't like having to maintain a shortcut list in the menu _and_ a list of keyboard shortcuts. But something like "Ctrl-Esc M" to start my mail application really speeds up my desktop experience. Even longer series of mnemonics are easily remembered if often used. Since GtkMenuItem supports mnemonics out of the box (iirc), it shouldn't be hard to support them in the panel menu. I'd just add another attribute in the menu.xml <app> and <menu> tags specifying the mnemonic, or use the regular Mne_monic syntax. The menu editor would have to be updated, of course. IceWM just uses the first letter of every (non-system) entry, maybe a more intelligent algorithm could provide suitable defaults. Hope someone finds time and motivation to implement this, I'm unfortunately too busy to go at it myself... Regards, Andre P.S.: Yes, I do use emacs :-) Ctrl-X Ctrl-S Ctrl-X Ctrl-C
Unfortunately I don't think this will be doable -- at least not your 'better' option. The 4.4 menu system has been thrown out in favor of a standards-compliant one for 4.6 (and we don't add new features to the stable branch). The menu standard doesn't really give a good way of doing keyboard mnemonics, or embedding them into .desktop files. Although... hmm. Hey, Jannis, what do you think about this? Could we add a 'X-KbdMnemonic=' key to the .desktop file parser, with some API in libxfce4menu to return this? Not sure if we want to just do simple characters, or allow full accelerators (e.g., "<Shift><Control>m"). Then xfdesktop could, of there's a mnemonic key, add one to the menu label by searching for the first instance of that char (and if there isn't one, it could do like some GUIs do for Asian langauages, and tack on e.g. " (_F)" to the end of the string). The downside to this would be having to edit system .desktop files, or keeping local copies in $HOME that could potentially get out of sync with the system. Maybe we can work to get this standardised later...
Oh, as for the other possibility -- by default using the first letter as a mnemonic, I don't believe gtk supports this. I'm not really willing to add a hack to make that work; that would be something to ask the gtk guys to do -- in the absence of menu items with mnemonics, force the first char of each item to act as a 'soft' mnemonic.
(In reply to comment #1) > Hey, Jannis, what do you think about this? Could we add a 'X-KbdMnemonic=' key > to the .desktop file parser, with some API in libxfce4menu to return this? Not > sure if we want to just do simple characters, or allow full accelerators (e.g., > "<Shift><Control>m"). Then xfdesktop could, of there's a mnemonic key, add one > to the menu label by searching for the first instance of that char (and if > there isn't one, it could do like some GUIs do for Asian langauages, and tack > on e.g. " (_F)" to the end of the string). Could be done easily, absolutely no problem. This feature might indeed be useful for some - there's just one problem: > The downside to this would be having to edit system .desktop files, or keeping > local copies in $HOME that could potentially get out of sync with the system. This might be a reason for a lot of people not to use the feature, so it might be a waste of time. Only very few applications will ship .desktop files with X-KbdMnemonic anyway, unless there's a standard for something like this. If a user modifies a .desktop file, he'll have to copy it to $HOME in order to make the changes permanent (e.g. to keep them after switching to a different Linux distribution or after reinstalling the system). Usually, you don't want to keep copies of .desktop files as their contents might soon be outdated (new translations added to the original or whatever). I guess what I want to say is that I don't think its worth it unless there is a standard (like a $XDG_DATA_DIRS/.menu-mnemonics database with a desktop-file-id => mnemonic mapping).
(In reply to comment #3) > (In reply to comment #1) > > The downside to this would be having to edit system .desktop files, or keeping > > local copies in $HOME that could potentially get out of sync with the system. > > This might be a reason for a lot of people not to use the feature, so it might > be a waste of time. Only very few applications will ship .desktop files with > X-KbdMnemonic anyway, unless there's a standard for something like this. > If a user modifies a .desktop file, he'll have to copy it to $HOME in order to > make the changes permanent (e.g. to keep them after switching to a different > Linux distribution or after reinstalling the system). Usually, you don't want > to keep copies of .desktop files as their contents might soon be outdated (new > translations added to the original or whatever). Well, I kinda see this more as a local custom menu thing. For example, I've made menu items in my top level menu for claws-mail, terminal, firefox, etc. so I can get at them easily. The corresponding .desktop files are in ~/.local/share/applications/, and I don't expect them to change (ever). For a real menu editor, it would be nice to be able to set mnemonics for local stuff, though people would most likely not understand the difference and might set mnemonics for system stuff as well. Then they go and uninstall one of them, and the system .desktop file gets removed, but the one in their homedir with the mnemonic doesn't, and then it still shows in the menu even tho it's uninstalled (though the smart thing to do for *any* menu item saved in the user's homedir would be to add a TryExec= line to check for the app). > I guess what I want to say is that I don't think its worth it unless there is a > standard (like a $XDG_DATA_DIRS/.menu-mnemonics database with a desktop-file-id > => mnemonic mapping). I don't completely agree, but it's up to you. I think a database mapping is a bit excessive, and would really not be particularly workable or usable (impossible to have unique mnemonics for different apps). I dunno...
(In reply to comment #4) > Well, I kinda see this more as a local custom menu thing. For example, I've > made menu items in my top level menu for claws-mail, terminal, firefox, etc. so > I can get at them easily. The corresponding .desktop files are in > ~/.local/share/applications/, and I don't expect them to change (ever). For a Well, using a purely .desktop file based menu system (as I understand) really complicates things. This top-level menu mnemonics issue is really the most important to me. So would it make sense to just invent some other way for the new system to add custom user entries that just link to system-wide .desktop files? I agree, those shouldn't be modified. I'm thinking of some kind of custom .desktop file that references the system wide file. Would the Type="Link" key be appropriate? A custom URL scheme for linking .desktop files--probably not a good idea... What would it take to add another Type="Include" key value and then specify the target Desktop-File Id file in the TryExec (or a new custom) key? After all, the Type key should be backward-compatible, but this would be an XDG suggestion I guess :-) It could also simplify the "Hidden" key handling and provide easy ways to override specific settings like adding a mnemonic, changing the title or icon, etc... A thought on launcher menus in general: Microsoft Windows implements the "first letter searching" feature. This is because their menu is not actually a menu but more of a special file list view. This is quite contrary to the notion of a "menu", which Xfce uses through GtkMenu. This is probably the source of the problem because menu entries are usually static items, not a list of "files". That's my current thoughts on the subject, hope the discussion will bring forward a feasable solution.
(In reply to comment #5) > Well, using a purely .desktop file based menu system (as I understand) really > complicates things. This top-level menu mnemonics issue is really the most > important to me. So would it make sense to just invent some other way for the > new system to add custom user entries that just link to system-wide .desktop > files? I agree, those shouldn't be modified. Oh, god, no. No more custom add-on crap that doesn't really fit anywhere. That's more or less what I did for the last menu, and that was a nightmare to maintain (it *still* has problems after over 3 years). > I'm thinking of some kind of custom .desktop file that references the system > wide file. Would the Type="Link" key be appropriate? A custom URL scheme for > linking .desktop files--probably not a good idea... What would it take to add > another Type="Include" key value and then specify the target Desktop-File Id > file in the TryExec (or a new custom) key? After all, the Type key should be > backward-compatible, but this would be an XDG suggestion I guess :-) It could > also simplify the "Hidden" key handling and provide easy ways to override > specific settings like adding a mnemonic, changing the title or icon, etc... I'm not sure... need to think about this, but it sounds overly complicated. > A thought on launcher menus in general: Microsoft Windows implements the "first > letter searching" feature. This is because their menu is not actually a menu > but more of a special file list view. This is quite contrary to the notion of a > "menu", which Xfce uses through GtkMenu. This is probably the source of the > problem because menu entries are usually static items, not a list of "files". > > That's my current thoughts on the subject, hope the discussion will bring > forward a feasable solution. Mmm, so, possible solutions without touching the menu spec: 1) File an enhancement request with gtk to do essentially type-ahead find in menus (similar to what's done in gtktreeview). 2. Create a GtkMenuItem subclass that automatically sets mnemonics (that don't show underlines, somehow) on items that don't have a mnemonic set. 3. Create GtkMenuItem subclass that implements type-ahead find. 4. Don't use a menu, but approximate the behavior with something else that already does what we want. #1 is easest for me -- I don't have to do a damned thing but file a bug report on gnome.org. Maybe this is a good long-term solution, but at best it would first appear in gtk 2.16 (I think they're skipping 2.14 to re-sync glib and gtk version numbers). #2 sounds not too difficult, though I'm not sure if I can hide the underline (which I guess wouldn't be such a big deal if I can't). I already have a GtkMenuItem subclass, so I could just add it to that. #3 sounds a bit harder than #2, but would really give the best behavior IMHO. I'm not sure I have the time or desire to put that much work into it, though. #4 is just retarded and is too much effort for what it gets us.
*** Bug 5065 has been marked as a duplicate of this bug. ***
What's the status of this? GtkMenuItem http://library.gnome.org/devel/gtk/unstable/GtkMenuItem.html seems to support mnemonics.
*** Bug 5938 has been marked as a duplicate of this bug. ***
I also miss this feature. But of course it is a pain to add mnemonics manually. However it is possible to add them dynamically if an efficient algorithm is used. Here is the code I use for my Qt programs: http://www.qtrac.eu/alt_key_api.html I know you use Gtk+ so wouldn't be able to use this code directly, but it shows how it can be done. And, of course, this requires no changes to .desktop files. The code respects existing mnemonics and fails gracefully (i.e., no mnemonic is added if a unique character can't be found). It also works fast because it uses the Kuhn-Munkres algorithm. Incidentally, the implementation tries first letter of each string, first letter of each word in a string, or any letter at all (in that order of preference). The code uses Qt collection types but has #ifdefs for std::vector etc. So the only real Qt dependency is QString (a UTF-16/UCS-2 string type) and the use of qmake to create the makefile. I guess that replacing QString with a UTF-8 string type might not be straightforward since the code accesses individual characters. I'd be willing to port the code if C++ was acceptable (I haven't programmed C for many years) and if someone was willing to help since I've never built a Gtk+ library before and don't know how to create suitable makefiles or how Gtk+ strings work.
I agree with comment #6. Ideally, this should be addressed directly in GTK+, so that a possible solution can be used across all GTK+ applications.