> > This means this \unbind entry in user.bind does not have an > > corresponding in the chosen bind file. > > and.... ?
And if we would like to display this item, it is displayed as 'unmatched deleted item'. > >> \bind "" "buffer-close" > >> > >> wouldn't suffice to have no shortcut associated with buffer-close > > I have explained in another thread that 'wildcard' operations like > > that causes GUI troubles. > > i read that, and i find this "wildcard" notion very strange. perhaps i > am overseeing something, but why don't we have an interface where > > \bind "" "buffer-close" > > simply means "there is no key binding associated with buffer-close" etc? Why can not you just address the three problems I described with your proposal? 1. when do you insert this to the bind file? When a user click remove? Since you are removing *all* shortcuts related to buffer-close, you will have to search the tree and remove all of them. 2. how do you 'undo' your removal? 3. How do you display this item if there is already no shortcuts related to 'buffer-close'? > the fact that the gui becomes very complicated also suggests that > something is wrong since this stuff shouldn't be complicated. Please define very. You add a shortcut to the original one, you remove the existing one, and if you dislike the 'unmatched deleted item', I can ignore them. > imo the gui should simply list the available functions and their > associated keybindings My gui has done that. > and setting or removing a keybinding is at the > function level and therefore unambigous. these user set bindings then > override the system ones when they are loaded. Maybe I am too lazy but your 'override all' logic is difficult to implement at both GUI and core levels. At the very least, it is difficult to clear all bindings related to a LFUNC, because you will have to traverse all nested keymaps. > >> should we also add a "add length here... " in the length widget etc > > > > If there is no label, sure. > > that's why we use labels instead of subclassing a zillion widgets. i > took the liberty to commit this: Why do you change the interface just because you dislike subclassing? My implementation is certainly a space-saving way to do search, which is commonly used in other applications like firefox. > http://www.lyx.org/trac/changeset/21254 > > > Will save also 'apply'? > > i would think so, yes. as i see it the apply/ok buttons enforce settings > within sessions and the save between sessions. the apply button is like > the ok button except that is doesn't close the dialog... Isn't that complicated, especially when you are criticizing the complexity of the shortcut panel? Please be specific about 'which' part of the GUI looks complicated, and I will fix it. Bo
