On Wed, 2004-09-29 at 08:44, Jean-Marc Lasgouttes wrote: > And what would be the right gtkmm method to get a nice human-readable > version? Well, I'm currently using a modified GLyXKeySym::print to produce gtk-style strings like "Ctrl+N" (in fact, this is also the normal style for qt apps, so I don't know why the qt frontend uses "C-n"). The problem is that I also use a string like "<control>n" to create GTK+ AccelKey objects for the menus. Right now I'm converting from "Ctrl+N" to "<control>N" by string substitution at the time of creating the menu item.
The key difference between this situation and the other frontends is that I'm not just using a label that the backend gives me for the menu accelerators, I'm describing the accelerator to gtkmm and it's making up the label (which just happens to be the same as what we would have given it, just that the Gtk::MenuItem::add_accel_label function is protected so we can't). So to avoid the hackyness of string substitution, I would need binding() to give me a LyXKeySym rather than a string. > The part of the code that handles this shortcuts is designed to work > with xforms and Qt. If changes are needed to get gtk to work, I am > willing to do them. Well, it already works as well as it does for xforms or qt, it's just a question of neatness (ie how we extract the accelerator information from the backend in a gtk-readable form). Those gtkmm warnings have nothing to do with how we're generating the AccelKey. > What I think we should do is expose properly the key sequences to the > frontends. Currently, this does not work very well, because > kb_sequence is a rather opaque object. So, I'm MenuItem::binding() I see that we're just showing the first key of shortcut sequences. Are there a lot of these? Are we that short on accelerator keys that we need to use sequences for menu items? John
