Re: hotlist: now with edit


> 2. (I'd prefer this one) Just remove all hotkeys from the buttons, to
> aviod any confusion. This is reasonable because the buttons are
> accessible not only via Tab, but by other keys (that cannot be entry
> hotkeys anyway):

I think that would be inconsistent with other dialogs.

I'm afraid there is no simple solution to this problem.  There is no list
of currently supported keys and there is no way to test at runtime which
hotkeys are active.

Maybe the dialog hotkeys of the dialog should be disabled if they conflict
with the user entries?  If this happens, the hotkey on the button should
not be shown.

> Change to = Enter
> Edit = F4 (not yet, but I think it's a good idea)
> Up = Left-arrow
> Remove = Del

I remember reading somewhere that "OK" and "Cancel" should not have
hotkeys because they are always bound to Enter and Escape respectively.
I don't remember where I read that, but the GNOME and KDE programs that
come with Red Hat 8.0 don't seen to follow this rule (I checked gedit and
kedit).  On the other hand, Mozilla and qtconfig (Qt configuration) follow
this convention.

I think that all other buttons should have the hotkeys.

> > Hm, if we allow more entries assigned to one hotkey, then pressing
> > the key should "cycle-jump" through entries.
> That's too inconsistent. A hotkey's action is to activate an item
> immediately. It may be utterly confusing when you hit a key but the
> expected action is not fired only because there's another item with the
> same hotkey. So I think it's best to prevent duplicate hotkeys from
> being entered.

I think it's the right thing to do.  There are duplicates even in the
English menus.  For example, F9-C-E can be "Free VFSs now" or "Edit
extension file".  Either the second item should not have its hotkey
highlighted or the hotkey should move between entries without activating

Pavel Roskin

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]