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 419923 - No key press events signals for some keys
No key press events signals for some keys
Status: RESOLVED NOTABUG
Product: gtkmm
Classification: Bindings
Component: general
2.4
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2007-03-18 22:43 UTC by ville.ranki
Modified: 2007-04-15 12:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
test case (766 bytes, text/plain)
2007-03-19 17:48 UTC, Marko Anastasov
Details
C test case (906 bytes, text/plain)
2007-04-06 14:59 UTC, Marko Anastasov
Details

Description ville.ranki 2007-03-18 22:43:23 UTC
For some keys gtkmm does not generate key press
event signals. At least arrow keys, tab, and enter
signals are lost. 

For example ctrl, alt, capslock, and esc generate signals.

Here's some code that i'm using to test this. It
creates a window with no children, and andother
class which has the signal handler.

main:

   Gtk::Window win;
   win.set_title("DrawingArea");
   MyArea area;
   win.add_events(Gdk::KEY_PRESS_MASK);
   win.signal_key_press_event().connect(sigc::mem_fun(area, 
&MyArea::key_press_event));

signal handler:
bool MyArea::key_press_event(GdkEventKey* event) {
	std::cout << "Pressed " << event->keyval << "\n";
	return true;
}

In plain gtk arrow key signals are generated. See:

http://www.gtkforums.com/viewtopic.php?t=187&view=previous&sid=a7c9ab2507ce106b147fde43fe3b7e6d
Comment 1 Marko Anastasov 2007-03-19 17:48:18 UTC
Created attachment 84898 [details]
test case

I've quickly made a simple test case. It seems that really the key_press signal is not emmitted for some reason for the arrow keys, space, enter... (hope to catch time to investigate later), while key_released is ok.
Comment 2 Murray Cumming 2007-03-23 16:21:19 UTC
Could we have an equivalent GTK+ test case please?
Comment 3 Murray Cumming 2007-04-05 12:44:29 UTC
Hey. This is intruiging. How about a C test case?
Comment 4 Marko Anastasov 2007-04-06 14:59:43 UTC
Created attachment 85906 [details]
C test case
Comment 5 Armin Burgmeier 2007-04-12 11:10:24 UTC
The problem here is that g_signal_connect connects before the default signal handler runs and gtkmm signals connect after (by default). Using g_signal_connect_after in the C testcase yields the same result as the C++ version, and using win.signal_key_press_event().connect(sigc::ptr_fun(...), false) in the C++ testcase results in the same behaviour as in the C version.

Probably, the default signal handler of the key press event returns TRUE for some keys and therefore prevents other handlers from being run. However, this is not a gtkmm issue. Perhaps a GTK+ one, but I think it is OK the way it is.
Comment 6 Murray Cumming 2007-04-15 12:06:43 UTC
Ah, sorry. I didn't notice that it was this simple.

This is a fairly well-known behaviour and the solution is mentioned already in the documentation:
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/apbs06.html
I still believe that connect-after is a far better default. I'd rather have these problems than the other problems.

It's unpleasant, but it's not something that we can really change. The closest thing to an open bug about it is this:
http://bugzilla.gnome.org/show_bug.cgi?id=126213

See also:
http://bugzilla.gnome.org/show_bug.cgi?id=89780
http://bugzilla.gnome.org/show_bug.cgi?id=125969