> > Do you still display the original one as the trunk does? > > I do not think it is necessary. What one wants to see are the current > bindings, not all the history that lead to them. A bit like how > about:config works in firefox.
If you remove the item, how can you revert? It is definitely helpful to list all lfuncs as the trunk does, because there is otherwise no way for a user to know what lfuncs are available. > > So you only display a shortcut without lfun? How do you treat the > > bindings that are overriding in this way? Remove them? You are also > > removing lfuns that a user needs to know. Keep them? How do I know > > they are overriding? > > OK, what about displaying each lfun only once, but with all its > shortcuts? Then there would not be this notion of showing hiding a > lfun. Each lfun is here once, and the bindings can be like > redo S-C-Z; C-y This makes sense. > Then the user can edit the bindings to add or remove one. There is of > course a small difficulty in KeySequence grabbing code, but I think > the basis is sane. This seems to be what MS Word is doing. But then, what does the remove button do? Removing all shortcuts related to a lfunc? I guess the remove button should be moved to the shortcut edit box... > > You need to revert several items that are overridden, so there is no > > simple revert. > > What do you mean? In case that you can not override several items (C-g a, C-g b overridden by C-g), this is not a problem. > > Also, what if there is no corresponding shortcut in the main bind > > file? Do you display this at all? > > The lfun is shown anyway. Then there is no 'removal' for this unmatched \bind "". In the end, I see that you want to list lfunc with all related keybindings, using a more complicated shortcut edit dialog. In the dialog, you still need to unbind a shortcut specifically to that lfunc (which is not saved as such in user.bind). There is still no better way to handle the 'unmatched unbind'. I really do not see any improvement here. If you dislike the current four-color scheme, I can ignore the 'unmatched unbind case'. They will not do anything anyway. > > Then there is a big problem with setKeySym. QKeyEvent::text() is meant > > to support imput methods, not for the name of keys. > > Yes, probably. And the same reason why typing S-C-o in main window > makes a strange character. This is beyond me. Abdel should definitely be involved. Bo
