After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687024 - x11: fix return value of gdk_keyval_from_name
x11: fix return value of gdk_keyval_from_name
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-10-28 06:53 UTC by Daiki Ueno
Modified: 2013-04-29 04:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
x11: fix return value of gdk_keyval_from_name (981 bytes, patch)
2012-10-28 06:53 UTC, Daiki Ueno
none Details | Review
gdk: fix return value of gdk_keyval_from_name (1.25 KB, patch)
2012-10-31 01:40 UTC, Daiki Ueno
rejected Details | Review

Description Daiki Ueno 2012-10-28 06:53:19 UTC
According to te doc, gdk_keyval_from_keyval shall return GDK_KEY_VoidSymbol when the key name is invalid.  However, it returns 0 (NoSymbol) instead on X11.

$ python
>>> from gi.repository import Gdk
>>> Gdk.keyval_from_name("foobarbaz")
0L
>>> Gdk.KEY_VoidSymbol
16777215

Other backends seem to return VoidSymbol properly.
Comment 1 Daiki Ueno 2012-10-28 06:53:22 UTC
Created attachment 227438 [details] [review]
x11: fix return value of gdk_keyval_from_name

Cast the return value of XStringToKeysym to VoidSymbol if it is NoSymbol.
Comment 2 Matthias Clasen 2012-10-29 01:14:07 UTC
This will require some checking of callers to make sure we're not breaking code which has be adapted to the actual return value of 0
Comment 3 Daiki Ueno 2012-10-30 05:57:05 UTC
Just out of curiousity, what was the reason to use VoidSymbol rather than NoSymbol here?
Comment 4 Matthias Clasen 2012-10-30 17:51:12 UTC
No idea
Comment 5 Daiki Ueno 2012-10-31 01:40:13 UTC
Created attachment 227696 [details] [review]
gdk: fix return value of gdk_keyval_from_name

For all backends, return 0 (NoSymbol) instead of GDK_KEY_VoidSymbol
if the key name is invalid (previously only x11 backend returned 0).
Adjust the doc as well.
--
So, maybe safer to fix other backends and the doc so it returns NoSymbol.

The x11 code has been there since gtk+ 1.x and I have actually seen checks like "keyval != 0" in several places.  Even though GDK_KEY_VoidSymbol might be useful in some cases (since it is a valid keysym), callers should check the return value.
Comment 6 Matthias Clasen 2012-10-31 10:59:40 UTC
grepping for VoidSymbol in gtk/ brings up several places where we do check for it, so I don't think we can get away with changing the semantics of this function
Comment 7 Daiki Ueno 2012-11-08 21:42:48 UTC
Comment on attachment 227696 [details] [review]
gdk: fix return value of gdk_keyval_from_name

Okay, so fwiw I grepped for "\<(Gdk\.|gdk_)keyval_from_name\>" in freshly checked out gnome-apps-3.8 moduleset and it seems the affected modules are:

* spice-gtk
  spice-gtk-0.14/gtk/spice-grabsequence.c:88
* orca
  orca/src/orca/keybindings.py:76
* ibus
  ibus-1.4.99.20120822/setup/keyboardshortcut.py:179
* accerciser
  accerciser/macaroon/macaroon/record/main.py:440

Other modules either check with VoidSymbol or don't have any check.

Probably we should also go through NoSymbol / VoidSymbol usage in
gtk+/gdk/x11/*.c
Comment 8 Matthias Clasen 2012-11-10 00:45:22 UTC
I've already made up my mind: we can't change the semantics. We should fix all backends to consistently return VoidSymbol, as documented.
Comment 9 Daiki Ueno 2012-11-10 01:08:16 UTC
I'm not pushing the semantics change (read comment 7 again).  I marked the 2nd patch as "rejected" and provided the list of modules that need fix to check keyval == VoidSymbol instead of keyval == 0.

I think other backends return VoidSymbol already (through gdkkeynames.c:_gdk_keyval_from_name).
Comment 10 Matthias Clasen 2012-11-12 00:03:35 UTC
ah, ok
Comment 11 Matthias Clasen 2013-04-29 04:19:49 UTC
This is probably obsoleted by use stripping backends from keyval translation