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 157492 - Second double click gets eaten
Second double click gets eaten
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Backend: X11
2.5.x
Other Linux
: Normal normal
: Small API
Assigned To: gtk-bugs
gtk-bugs
: 157458 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-06 00:58 UTC by Soren Sandmann Pedersen
Modified: 2015-09-05 04:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A patch (6.39 KB, patch)
2005-03-26 23:56 UTC, Soren Sandmann Pedersen
needs-work Details | Review
generalization to allow suppressing double-clicks too (6.28 KB, patch)
2006-01-10 15:34 UTC, Matthias Clasen
needs-work Details | Review

Description Soren Sandmann Pedersen 2004-11-06 00:58:34 UTC
If a user double clicks two times quickly in the same spot it won't work,
because the first click of the second double click will actually be interpreted
as the third click of a triple click. This is a problem in contexts where triple
clicks are not used and two double clicks in a row makes sense.

This is a problem in the sysprof profiler where double clicks are used to
navigate a tree. 

A possible solution is to add

    gdk_window_set/get_triple_clicks ()

and possibly have GtkTreeView call that by default.
Comment 1 Soren Sandmann Pedersen 2004-11-06 01:57:05 UTC
*** Bug 157458 has been marked as a duplicate of this bug. ***
Comment 2 Federico Mena Quintero 2004-12-14 18:37:29 UTC
See also bug #159101 for a related issue.
Comment 3 Soren Sandmann Pedersen 2005-03-26 23:56:40 UTC
Created attachment 39298 [details] [review]
A patch

This patch adds the triple click setting.
Comment 4 Matthias Clasen 2005-07-21 05:43:02 UTC
Should probably generalized to allow ignoring double-clicks as well.
Comment 5 Matthias Clasen 2006-01-10 15:34:18 UTC
Created attachment 57106 [details] [review]
generalization to allow suppressing double-clicks too

Does this look good ?
Comment 6 Federico Mena Quintero 2006-01-11 18:22:42 UTC
This is pretty interesting.

One thing I had discussed with Jimmy Krehl (jimmyk@novell.com) is to extend GdkEventPrivate to have a num_clicks field, and for there to be a corresponding gdk_button_event_get_num_clicks().  Then it would be easier to implement things like word processors which use 2, 3, 4, clicks to select words, lines, paragraphs, respectively.

Anyway.  What the API has to allow is this:

I am a pushbutton which the user is likely to double-click.  I want to say gdk_window_set_max_clicks (button->window, 1).  If the user double-clicks or N-clicks, I'll only get a single BUTTON_PRESS event.

Does that work with the patch in comment #5?
Comment 7 Matthias Clasen 2006-01-11 18:56:45 UTC
What the patch does is only to suppress the synthesized 2button and 3button
events. If you click 5 times, you will get five button_press events, instead
of 

button_press
button_press
2button_press
button_press
3button_press
button_press
button_press
2button_press
Comment 8 Matthias Clasen 2006-01-11 18:58:03 UTC
I forgot to mention that it makes a real difference if you are interested in 
double clicks, since the current code prevents quick succession of double clicks
Comment 9 Matthias Clasen 2006-06-19 19:40:18 UTC
did not get the necessary discussion to include it in 2.10...
Comment 10 Matthias Clasen 2006-12-21 06:43:46 UTC
Federicos comment seems to indicate that he wants to drop the subsequent clicks if a window has max-clicks==1 and the user double- or triple-clicks. 
Comment 11 Federico Mena Quintero 2006-12-21 16:57:32 UTC
I'd say we can start with these requirements:

1. I want to be able to ignore multiple clicks (use case: users double-click on everything and we don't want to perform certain things more than once).

2. I want to allow more than 3 clicks for a word processor that wants to select words/lines/paragraphs on each subsequent click.  (One can implement this by hand in the word processor, but it's painful and error-prone, and everyone forgets about double_click_timeout/threshold anyway).

3. I'm not sure how to categorize Søren's original case.
Comment 12 Matthias Clasen 2006-12-22 15:14:41 UTC
honestly ? 

quadruple-click sounds like a usability nightmare, even for people with reasonable manual dexterity 
Comment 13 Matthias Clasen 2015-09-05 04:18:27 UTC
we have a gesture framework with a multipress gesture now