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 758467 - Worm is uncontrollable briefly after spawned
Worm is uncontrollable briefly after spawned
Status: RESOLVED FIXED
Product: gnome-nibbles
Classification: Applications
Component: general
3.19.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-nibbles-maint
gnome-nibbles-maint
Depends on:
Blocks:
 
 
Reported: 2015-11-21 18:59 UTC by Michael Catanzaro
Modified: 2016-02-15 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Handle input from window rather than view (1.77 KB, patch)
2016-02-14 15:37 UTC, Gabriel Ivașcu
none Details | Review
Handle key pressed event in gnome-nibbles.vala (1.88 KB, patch)
2016-02-15 16:09 UTC, Gabriel Ivașcu
none Details | Review
Handle key pressed event in gnome-nibbles.vala (2.56 KB, patch)
2016-02-15 17:00 UTC, Gabriel Ivașcu
committed Details | Review

Description Michael Catanzaro 2015-11-21 18:59:12 UTC
After a worm spawns, there is a brief period before it's possible to control the worm with the arrow keys. That's bad....
Comment 1 Razvan Chitu 2015-12-22 15:21:15 UTC
I think this bugged was solved by one of my previous patches. I tested it and to me it appears that the delay is gone. Iulian, can you please test too?
Comment 2 Iulian Radu 2015-12-28 12:05:57 UTC
It still happens for me if I try pressing a key as soon as the countdown reaches 0. It works if you press the key as soon as the level is loaded though.
Comment 3 Gabriel Ivașcu 2016-02-13 15:16:02 UTC
I can't seem to be able to reproduce this.. it appears to be working fine for me. Are you talking about spawning after death or spawning when a new level begins?
Comment 4 Michael Catanzaro 2016-02-13 19:01:04 UTC
Um, I'm pretty sure I've hit this when spawing after death before, as I remember one level where my worm unfortunately started out advancing towards a wall, and I barely had enough time to turn him away from the wall due to this, died several times in a row there. :D

But I'm having trouble reproducing it now... seems to be working fine, though realistically I know there haven't been any changes to this since Iulian's last comment.
Comment 5 Gabriel Ivașcu 2016-02-14 15:37:06 UTC
Created attachment 321121 [details] [review]
Handle input from window rather than view

(In reply to Iulian Radu from comment #2)
> It still happens for me if I try pressing a key as soon as the countdown
> reaches 0.

After having a closer look I realized that Iulian was right here. This behaves somewhat like your first key press is being ignored if you start pressing as soon as the countdown reaches zero.

I'm not sure what is causing this, but after taking a look at other games (Quadrapassel for example) I noticed that another way to handle input is to use the window's key_pressed_event signal. After trying the same here, the problem seems to have disappeared.

Not sure if this a proper fix or just a workaround so I'll let you decide that.
Comment 6 Michael Catanzaro 2016-02-14 17:37:39 UTC
Review of attachment 321121 [details] [review]:

Hm, I'm not sure why this fixes it... one behavior difference is that this is a RUN_LAST signal, meaning signal handlers that are connected normally run before the object's own handler. The other difference is that now the parent class's handler will run as we're not overriding it anymore.

::: src/gnome-nibbles.vala
@@ +156,3 @@
         var builder = new Gtk.Builder.from_resource ("/org/gnome/nibbles/ui/nibbles.ui");
         window = builder.get_object ("nibbles-window") as Gtk.ApplicationWindow;
+        window.key_press_event.connect (key_press_event_cb);

Can you try doing this in the NibblesView constructor instead? I bet this will work there:

key_press_event.connect (key_press_event_cb)

It seems like a better place for the code.

::: src/nibbles-view.vala
@@ -901,3 @@
-    public override bool key_press_event (Gdk.EventKey event)
-    {
-        return game.handle_keypress (event.keyval);

The other thing you could try, to see if it makes a difference, is to try chaining up when the signal is not handled here:

if (game.handle_keypress (event.keyval))
    return TRUE;
return base (event.keyval);

I dunno if that is actually possible in Vala, but if it is, that would be the syntax for it. :D Anyway, if that works, it would probably be a better solution... otherwise, I think what you have is fine.
Comment 7 Michael Catanzaro 2016-02-14 17:38:42 UTC
Er, with lowercase "true" in Vala.
Comment 8 Gabriel Ivașcu 2016-02-15 15:50:27 UTC
I've just tried your suggestions above but neither of them seem to work, that brief moment of uncontrollable worm still happens every time at the beginning of a new level.

As odd as it seems, the problem appears to be gone only by having the signal handled in gnome-nibbles.vala.
Comment 9 Gabriel Ivașcu 2016-02-15 16:09:33 UTC
Created attachment 321266 [details] [review]
Handle key pressed event in gnome-nibbles.vala

Added a comment.
Comment 10 Gabriel Ivașcu 2016-02-15 17:00:01 UTC
Created attachment 321273 [details] [review]
Handle key pressed event in gnome-nibbles.vala

Added a more detailed comment.
Comment 11 Michael Catanzaro 2016-02-15 17:01:01 UTC
Review of attachment 321273 [details] [review]:

As explained on IRC, the only possible explanation for this is that something connects to this signal after the Nibbles application but before the NibblesView. It seems really unlikely, but if you're confident it fixes the issue, go ahead.