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 678272 - Touchscreen event handling
Touchscreen event handling
Status: RESOLVED OBSOLETE
Product: gnome-mines
Classification: Applications
Component: general
git master
Other Linux
: High enhancement
: ---
Assigned To: gnome-mines-maint
gnome-mines-maint
touch
: 724824 (view as bug list)
Depends on: 728483
Blocks:
 
 
Reported: 2012-06-17 21:12 UTC by Kat
Modified: 2018-05-22 11:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (7.31 KB, patch)
2015-10-31 11:19 UTC, Isaac Lenton
none Details | Review
Proposed patch (version 2) (7.60 KB, patch)
2015-11-02 19:48 UTC, Isaac Lenton
none Details | Review

Description Kat 2012-06-17 21:12:08 UTC
Add touchscreen event handling.

At the moment, it is possible to single tap a tile to reveal it or single tap a revealed tile to reveal others around it when the mines are marked. It is not possible to mark a mine without a mouse.

I suggest that a double tap on a touchscreen is registered as adding a flag instead of as two individual taps. Another double tap should change the red flag to a blue flag when blue flags are enabled or remove the red flag when blue flags are disabled.
Comment 1 Michael Catanzaro 2013-11-07 18:06:54 UTC
Allan wants a flag button, described at Bug #710616.  I'm not sure if we want to implement both of these?

I don't have a touch device so this is a very uneducated comment, but one possible concern is that if double-tapping isn't very accurate, you could accidentally explode a mine instead of flagging it.
Comment 2 Kat 2013-11-07 18:45:00 UTC
(In reply to comment #1)
> Allan wants a flag button, described at Bug #710616.  I'm not sure if we want
> to implement both of these?

Given that it's a timed game and the aim is to complete it in the shortest time possibly, I wouldn't be too keen to have only mode switching by button.

> I don't have a touch device so this is a very uneducated comment, but one
> possible concern is that if double-tapping isn't very accurate, you could
> accidentally explode a mine instead of flagging it.

That is true, although I have not had this problem myself.
Comment 3 Michael Hasselmann 2013-11-07 19:14:29 UTC
Press-and-hold gestures are a well-known workaround to emulate double-clicks on touch-enabled devices.
Comment 4 Kat 2013-11-07 21:10:10 UTC
That would be interesting to try out…
Comment 5 Michael Catanzaro 2014-02-21 00:54:31 UTC
*** Bug 724824 has been marked as a duplicate of this bug. ***
Comment 6 Michael Catanzaro 2014-02-21 02:53:30 UTC
(In reply to comment #1)
> Allan wants a flag button, described at Bug #710616.  I'm not sure if we want
> to implement both of these?

We're not going to make this a button after all.

(In reply to comment #3)
> Press-and-hold gestures are a well-known workaround to emulate double-clicks on
> touch-enabled devices.

I think this is what we're going to do. As far as I know, we have to handle this manually. Can you estimate roughly how long a touch would be appropriate for it to be considered a flag placement?
Comment 7 Adam Williamson 2014-02-21 02:55:55 UTC
"As far as I know, we have to handle this manually."

Are you *entirely* sure about this? Long press is such a universal action, and I know it's already used in certain other areas of GNOME 3 (though I'm blanking on a specific example ATM). It seems almost inconceivable that it wouldn't be available from some generic library already, and if it isn't, it absolutely *should* be. It seems entirely absurd for every app to re-implement it.
Comment 8 Michael Catanzaro 2014-02-21 15:38:20 UTC
(In reply to comment #7)
> "As far as I know, we have to handle this manually."
> 
> Are you *entirely* sure about this? 

No.  I think we have to listen to GdkEvents emitted by GtkWidget::touch-event, because that's the only relevant API in GTK+ with the word "touch" in its name, but I am most definitely not sure there's not some better way to do this.
Comment 9 Michael Catanzaro 2014-07-20 14:01:03 UTC
(In reply to comment #7)
> Are you *entirely* sure about this?

Nowadays we have [1] which looks easy enough that we could probably write the code without a touchscreen and maybe get it right.

(But this is brand new. I guessed right five months ago. :)

[1] https://developer.gnome.org/gtk3/unstable/GtkGestureLongPress.html
Comment 10 Robert Roth 2014-07-20 15:18:55 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Are you *entirely* sure about this?
> 
> Nowadays we have [1] which looks easy enough that we could probably write the
> code without a touchscreen and maybe get it right.

Yup, and GtkInspector nowadays has touchscreen emulation, so I will take a look at it this week.
> 
> (But this is brand new. I guessed right five months ago. :)
> 
> [1] https://developer.gnome.org/gtk3/unstable/GtkGestureLongPress.html
Comment 11 Robert Roth 2014-10-04 19:54:59 UTC
After thinking a bit about this, I am leaning towards having double-tap as flagging action, because the goal of the game is to find all the mines as fast as possible, and speed being important for best results, having to long-tap for a flag would increase the time required to complete the game.
Comment 12 Kat 2014-11-22 12:20:24 UTC
Indeed, this seems like the best solution. This is also the reason that I would like the game to have consistent behaviour between keyboard+mouse, keyboard+touchpad and keyboard+touchscreen (see bug 678271).
Comment 13 Isaac Lenton 2015-10-31 11:19:46 UTC
Created attachment 314534 [details] [review]
Proposed patch

Another alternative to double clicking or hold clicking is a swipe gesture.  The proposed patch implements this functionality.  Slide right to toggle flags and slide left to remove a flag.  Sliding up or down cancels the gesture/click.

Tested on my touch screen.  Seems to work fine, sometimes with a little lag though.  Perhaps it would be better to convert to integers instead of doubles for the gesture code and do a bound box check rather than a radius check.

The click radius could also be computed or set in the application properties.  Perhaps there is a better way to implement this?  Any suggestions?
Comment 14 Isaac Lenton 2015-11-02 19:48:51 UTC
Created attachment 314681 [details] [review]
Proposed patch (version 2)
Comment 15 Robert Roth 2015-11-04 07:47:20 UTC
Hmmm... I didn't think about swipe until now, it sound better than long-tap or double-tap indeed, but this must be implemented carefully, to:
* work only on touch, and not do the same thing if I mouse-press, move the mouse a bit, and mouse-release
* swipe gesture must be explained in an "interactive tutorial"

@Kat: what do you think about Isaac's proposal to use swipe gestures for flagging and resetting flag?
Comment 16 David King 2015-11-04 07:55:36 UTC
One way of documenting the swipe gesture would be to use the new GtkShortcutsWindow:

https://developer.gnome.org/gtk3/3.19/GtkShortcutsWindow.html#GtkShortcutsWindow.description

Specifically, a GtkShortcutsGesture.
Comment 17 Kat 2015-11-04 12:21:48 UTC
(In reply to Robert Roth from comment #15)
> Hmmm... I didn't think about swipe until now, it sound better than long-tap
> or double-tap indeed, but this must be implemented carefully, to:
> * work only on touch, and not do the same thing if I mouse-press, move the
> mouse a bit, and mouse-release
> * swipe gesture must be explained in an "interactive tutorial"

Would be awesome if we can think of a way to have an overlay over the UI and get the user to repeat the actions, but alternatively can do video in the user help although a UI simulation there would also be a pretty cool idea.

> @Kat: what do you think about Isaac's proposal to use swipe gestures for
> flagging and resetting flag?

Sounds like an interesting solution. Needs to react quite quickly…
Comment 18 GNOME Infrastructure Team 2018-05-22 11:42:48 UTC
-- 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/gnome-mines/issues/4.