>>>>> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Attached patch should sort this issue: Add gtk+ style John> accelerator labels to menu items. Previous runtime warnings have John> of course vanished because we're not using Gtk accels any more, John> just plain old labels. It looks OK to me, except for my remark on GLyXKeySym::print below. John> Oh, I don't actually have a cvs-built qt frontend, only a 1.3.x John> one. Fair enough. In case you do not know, it is possible to configure LyX --with-frontend='gtk qt', and you will also have the qt frontend built for you in the same build tree. >> So gtk+ has two types of string representation for an accel, one >> being the internal representation, and the other the user-visible >> one. Right? John> I'm not sure I'd call it the internal representation: the string John> I pass it on construction is probably not stored (just parsed). OK. >> One can only create a AccelKey object from a "<string>n" type of >> string. Right? John> Yes, or from non-string information about the key and modifier John> like so: John> AccelKey (guint accel_key, Gdk::ModifierType accel_mods, const John> Glib::ustring& accel_path="") Hmm, couldn't you use this constructor in GLyXKeySym::print and transform this into a string? This would look better than adding 'Ctrl+' by hand, IMO. John> Right, I've tried that. However, add_accel_label doesn't John> actually do what you'd expect. I've actually looked in the gtk John> source and I'm still not sure how it's meant to work. I tried to look at the API reference for both gtkmm and gtk, and it is really less useful than its Qt counterpart. >> - LyX supports multi-LyXKeysym keyboard sequences (think "C-x C-f" >> in emacs bindings). Does Gtk+ AccelKey support that? John> I doubt it. However, the gtk frontend does seem to support the John> sequences somehow. I haven't looked into how that's handled. The sequences are supported internally by LyX. JMarc
