Re: Mouse double-click filtering
- From: Soeren Sandmann <sandmann daimi au dk>
- To: Russell Shaw <rjshaw iprimus com au>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Mouse double-click filtering
- Date: 25 Sep 2003 16:36:23 +0200
Russell Shaw <rjshaw iprimus com au> writes:
Is there a standard way for handling a mouse double-click event?
The problem is that when a double-click happens, it generates a
single-click event (GDK_BUTTON_PRESS) followed by a double-click
event (GDK_2BUTTON_PRESS):
1. GDK_BUTTON_PRESS
2. GDK_BUTTON_RELEASE
3. GDK_BUTTON_PRESS
4. GDK_2BUTTON_PRESS
5. GDK_BUTTON_RELEASE
This falsely triggers the usual callbacks for single-clicks.
I could make a polled function that is called every 20ms that
logs button-press events and then emits a single-click or double-click
signal depending on a user defined click-speed interval, but it all
seems a bit re-inventing the wheel.
One way to handle both single and double clicks on the same location
is when you get the first GDK_BUTTON_PRESS (or RELEASE depending on
your need),
- read the private variable GdkDisplay->double_click_time
[which could go away in a later version of gtk+]
- id = g_timeout_add (double_click_time, not_a_double_click, data)
- if you get a GDK_2BUTTON_PRESS,
g_timeout_remove (id);
do what you want to do in response to a double
click
then in the function not_a_double_click() do whatever you have to do
on a single click.
This will delay the action in response to a single click by the double
click time and is how Mac OS and Windows handle "start_edit" on their
tree widgets.
If you want to avoid the delay, you might be able to get away with
starting the single click action as soon as you get the first click,
then _undoing_ it when the 2BUTTON_PRESS arrives. Chances are that
this will look and feel bad though, unless the single click action is
just starting an invisible background operation.
Søren
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]