>>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> 1) Optional menus (OptMenu) >> Easy enough John> good ! But it is not for now, is it? What I mean is that it would not be difficult to add more intelligence to the menu backend (and accordingly simplify the frontends), but I am not sure whether Lars would accept that for 1.3.0. I am not talking of big changes like MVC for menus here, just moving code around (and for example moving Opt* handling completely in backend, so that the frontends would not have to care about that). >> The function inset-properties would search for the inset with righ >> name either at point of enclosing. This means that in some cases, >> one would have several 'settings' entries available at the same >> time. John> Sounds llike it would work. And we could solve the lame John> "Open/Close Float" similarly The only problem I see is that we would like a binding for the generic inset-properties (that searches for the nearest item of any kind with properties dialog). Do we want then to put this entry in menus, for the sake of making it discoverable? That would produce: Inset settings C-p Table settings if one is in a table, and the two entries would produce the same effect. So we have to admit that th binding will not be discoverable, but maybe it is not so bad. Also, once we have this binding, I think we should remove right-clicking as binding for properties. JMarc
