GNOME Bugzilla – Bug 669994
GDK_KEY_* do not have equivalents in the C++ API
Last modified: 2018-05-22 12:12:27 UTC
The GDK_KEY_* macro constants currently are accessible only through the <gdk/gdkkeysyms.h>. This is a bit confusing, since ideally one shouldn't need to use the C API, or at least shouldn't need to include a header from the C API. Also, the gtkmm/gdkmm documentation doesn't show that these macros are available. I see the following ways to solve this problem: 1) Do nothing (if this way to do things is intended) 2) Add <gdkmm/keysyms.h> (or similar name) which includes <gdk/gdkkeysyms.h> 3) Add <gdkmm/keysyms.h> (or similar name) which includes <gdk/gdkkeysyms.h> and adds an enum in the Gdk namespace with all the values. Something like namespace Gdk { enum KeyVal { //Or similar name KEY_BackSpace = ... ... }; } I'd vote for the third solution, since it's consistent with the current way to generate enums thoughout gdkmm/gtkmm. Thanks, Mark
Created attachment 210996 [details] Generates keysyms.h from gdkkeysyms.h Any opinions about this bug? I attach a script to generate keysyms.h from the gdk/gdkkeysyms.h file. The script is a modification of gdk/gdkkeysyms-update.pl script which is used to generate gdk/gdkkeysyms.h itself from the upstream X11 headers. Currently the script generates enum values in the following format: namespace Gdk { enum KeyVal { KEY_BackSpace = 0x<hex_value>, <...> }; }
Mark and I had a short email discussion of this bug. I insert part of that discussion here. > Kjell: > You say that "all other enums are fully wrapped", but the problem with > the GDK_KEY_* symbols is that they are *not* enum values in gtk+. That's > unfortunate. If they had been, they would probably have been wrapped in > a gtkmm enum long ago. It would just have required a > _WRAP_ENUM(KeySyms, GdkKeySyms) > in a .hg file. Mark: Technically this is true. But practically here #defines are used as enumeration constants, so an enum would conceptually be equivalent and have all those advantages I mentioned. > Kjell: > I tried to find a gtk+ bug that suggests making an enum with all the > GDK_KEY_*, but I couldn't find one, not even a closed one with status > WONTFIX. > I think it would be better if you file a gtk+ bug, suggesting that > gdk/gdkkeysyms.h should contain an enum instead of about 2300 #define > preprocessor statements. If the gtk+ developers accept that, we don't > need yet another small Perl script for building gtkmm. I think it would > also almost automatically improve the gtk+ documentation, which now just > refers to the gdk/gdkkeysyms.h file for a list of key codes. Mark: I agree. Let's first file a gtk+ bug. > Kjell: > In the meantime, we ought to mention gdk/gdkkeysyms.h in the description > of Gtk::Widget::signal_key_press_event() and > Gtk::Widget::signal_key_release_event(). Mark: OK, I'll prepare a patch.
I see in the gtk+ bug 678975 that you have suggested an anonymous enum in gtk+. enum { GDK_KEY_*** = ***, <...> GDK_KEY_*** = *** }; I suppose this is a compromise you had to accept in the mailing list conversation https://mail.gnome.org/archives/gtk-devel-list/2012-June/msg00052.html It will require some changes in glibmm/tools/enum.pl and probably in gmmproc, _WRAP_ENUM. enum.pl recognizes only typedef enum { .... } Name; A named enum would certainly be best, but even an anonymous enum is better than #define. I'm sure enum.pl and gmmproc can be modified to handle anonymous enums, if necessary, but such changes can wait until we know if your patch in the gtk+ bug 678975 will be implemented.
It seems that the gtk+ won't convert the defines into an enum anytime soon, because of introspection ABI depends on them and must not be broken without a strong reason. Therefore I think we could use the custom generation script as a temporary solution. The generated code would be the same regardless of whether we use gmmproc or custom script. The only difference would be that we receive the benefits now instead of when GTK+ developers will decide to break their ABI. Note, that the build process wouldn't become even a bit more complicated than it is now. The keysyms.h would also be committed into git and manually regenerated only when it becomes out of date. Given that gdkkeysyms.h itself has been updated only six times in the past five years, I don't see how this could be a problem. The attached patch below adds the generator script and the generated keysyms.h file. I haven't forgot about the documentation patch I talked about in comment #2. The implementation of it depends on whether my patch to bug #135978 gets accepted.
Created attachment 220155 [details] [review] Gdk: Wrap keysym #defines in an enum
Review of attachment 220155 [details] [review]: ::: gdk/gdkmm/keysyms-update.pl @@ +6,3 @@ +# Author : Simos Xenitellis <simos at gnome dot org>. +# Authos : Bastien Nocera <hadess@hadess.net> +# Authos : Mark Vender <markv743@yahoo.co.uk> s/Authos/Author/g @@ +92,3 @@ + * released. They appear in the GdkEventKey.keyval field of the GdkEventKey + * structure, which is passed to signal handlers for the "key-press-event" + * and "key-release-event" signals. Keyvals are used in various other contexts, e.g. the accelerators used by GtkWidget, GtkAccelLabel, etc. I don't know if I would place such emphasis on keypress handlers only. At least, I'd suggest describing this as just one example, rather than making it sound like their only purpose.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtkmm/issues/6.