How is the best way to detect double clicks? I looked and there isn’t a
specific event id for a double click (unlike say a mouse down event), so
what would be a good way to determine if the user has double clicked versus
just single clicking? Do you set a timer and if they don’t click again
within a certain threshold, do you assume its just a single click, otherwise
it would be a double click?
Michael Rich
http://www.AlphaX86.com
That was my thought, but I think that a double-click event would be a nice
thing to add to SDL 2. Something that would check the speed value for the
given OS/WM. I don’t want to make guesses as to what the user wants for a
double click speed, and the information’s already there under most OS/WM I
know of.
Could this be added Sam? Also perhaps a single click event… the mouse
down and mouse up would still go down on every mouse button press, but a
click and double-click would be generated as well. (Along the lines of
Borland Builder’s implementation.)> ----- Original Message -----
From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Michael Rich
Sent: Tuesday, January 15, 2002 11:47 AM
To: 'SDL Programming List’
Subject: [SDL] Detecting Double ClicksHow is the best way to detect double clicks? I looked and there isn’t a
specific event id for a double click (unlike say a mouse down event), so
what would be a good way to determine if the user has double clicked versus
just single clicking? Do you set a timer and if they don’t click again
within a certain threshold, do you assume its just a single click, otherwise
it would be a double click?Michael Rich
http://www.AlphaX86.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
“Michael Rich” wrote:
How is the best way to detect double clicks?
call SDL_GetTicks() at each mouse button event and use your a timeout to
determine if the click was part of a multiclick
Joe Tennies wrote:
I don’t want to make guesses as to what the user wants for a
double click speed, and the information’s already there under most OS/WM I
know of.
X11 has no concept of double click – it’s a client thing. We could possibly
add a timestamp to some events to facilitate this, but I don’t think it’s
worth it
— Mattias Engdeg?rd wrote:
Joe Tennies wrote:
I don’t want to make guesses as to what the user wants for a
double click speed, and the information’s already there under most
OS/WM I
know of.X11 has no concept of double click – it’s a client thing. We could
possibly
add a timestamp to some events to facilitate this, but I don’t think
it’s
worth it
Do other OSes have double-clicks? If so, a function such as
SDL_GetDoubleClickTicks() could return the appropriate number of ticks to
wait, if available. If it was not available, simply return NULL and then
the program could use it’s own default value. The program would use this
time to see if a click was a double click or not.
Or if the proposed method of generating single click and double click
events seems better, perhaps SDL could have a default value, which could
be set automatically if the OS supports it and/or set by the program.=====
Dave Brondsema
dave at brondsema.net
http://www.brondsema.net
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
Dave Brondsema wrote:
Do other OSes have double-clicks? If so, a function such as
SDL_GetDoubleClickTicks() could return the appropriate number of ticks to
wait, if available. If it was not available, simply return NULL and then
the program could use it’s own default value.
Such a function would not serve any useful purpose since SDL clients
do not use the platform’s standard GUI. And as you correctly observe,
the program needs a default value anyway so why not use that all the time.
Less complexity and less code in both SDL and the program, what a deal 
Hiya,
DB> Or if the proposed method of generating single click and double click
DB> events seems better, perhaps SDL could have a default value, which could
DB> be set automatically if the OS supports it and/or set by the program.
The idea of SDL is that it’s platform independent, so having parts
which work on only some OS’ is not a good idea.
I’m also against having double click events anyway. If you’re creating
a game and you use mouse buttons as input, you may fire away happily.
You want to be looking for only one event, not two.
Is it REALLY so hard to get the current time when a button is clicked
once and then once more when it’s clicked again, then compare the two?
Neil.
And as you correctly observe, the program needs a default
value anyway so why not use that all the time.
At least with MS windows, you can adjust double click speed
and it would be nice of programs - whether they use the
standard gui or not - to observe this.
Maybe I’m a nervous guy, and two clicks in 20 ms are meant
as two independent clicks, maybe I’m quite slow and two
clicks in 500 ms are my fastest way of “double click”…
Ciao,
Eike
“Eike R. Sauer” wrote:
And as you correctly observe, the program needs a default
value anyway so why not use that all the time.At least with MS windows, you can adjust double click speed
and it would be nice of programs - whether they use the
standard gui or not - to observe this.
Maybe I’m a nervous guy, and two clicks in 20 ms are meant
as two independent clicks, maybe I’m quite slow and two
clicks in 500 ms are my fastest way of “double click”…Ciao,
Eike
Let me second that comment. No matter what platform the code
runs on people need a simple way to adjust the double click
time. I’ve noticed that people who did not grow up with a
mouse int their hand tend to have a much slower double click
time that those who did. And, all of us slow down as we get
older. So a “standard” way to get and set double click time
would be a good thing to have.
On the other hand, I’ve never seen a UI that really needed
double clicks. Just because someone designed them into a UI
sometime in the past is no reason to repeat their mistakes.
Bob P.>
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
Bob Pendleton wrote:
No matter what platform the code
runs on people need a simple way to adjust the double click
time.
as I’ve already said, that’s up to the client. If the game designer
thinks the double-click time should be adjustable he needs to provide
a way to do that anyway, indendent of the host platform. It does not
belong in SDL
I have to agree here. There are all sorts of nasty things that this
would cause if added. Any games that want better isolation of the mouse
would be in trouble. Even if you interpreted a double click as two
individual clicks, you’d lose the location of the first (or second)
click, and there’d be a latency issue because the system would never be
able to send ANY mouse event until the delay specified for a doubleclick
had expired because you couldn’t send a single until you were sure it
wasn’t a double. This would be especially awful if the doubleclick
delay is high.On Tue, 2002-01-15 at 16:56, Neil Griffiths wrote:
Hiya,
DB> Or if the proposed method of generating single click and double click
DB> events seems better, perhaps SDL could have a default value, which could
DB> be set automatically if the OS supports it and/or set by the program.The idea of SDL is that it’s platform independent, so having parts
which work on only some OS’ is not a good idea.I’m also against having double click events anyway. If you’re creating
a game and you use mouse buttons as input, you may fire away happily.
You want to be looking for only one event, not two.Is it REALLY so hard to get the current time when a button is clicked
once and then once more when it’s clicked again, then compare the two?Neil.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
End of Rant.
Jimmy
JimmysWorld.org
Actually, that’s not how most platforms handle double clicks, and there
would be no need for SDL to do it either. Commonly, if you “subscribe” to
all mouse button events, a double click from the user would give you
something like:
1. mouse down
2. mouse up
3. click
4. mouse down
5. mouse up
6. double click
If you don’t want double clicks, either disable the double click feature
altogether, handle the double click event just as if they were click
events, or just ignore the click events altogether and use the up/down
events instead.
Obviously, in the case of SDL, the double click feature should be
disabled by default.
Anyway, I have to agree with the No Double Clicks side; I don’t think
double click belongs in SDL, at least not in the primitive shape of an
explicit “you got a double click” event. (In fact, I don’t think double
clicks should be used at all, ever - but that’s another story.)
Timestamped events OTOH, could be very useful, especially in cases where
you cannot reliably sustain a sufficient frame rate to poll and check the
timing in the application main loop.
For those who want to (ab)use that for double click detection, another
handy thing would be a portable library that allows you to get the system
double click time and that kind of info. Maybe it makes sense to include
it in SDL from the implementation POV, but I doubt it.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 16 January 2002 19:42, Jimmy wrote:
I have to agree here. There are all sorts of nasty things that this
would cause if added. Any games that want better isolation of the
mouse would be in trouble. Even if you interpreted a double click as
two individual clicks, you’d lose the location of the first (or second)
click, and there’d be a latency issue because the system would never be
able to send ANY mouse event until the delay specified for a
doubleclick had expired because you couldn’t send a single until you
were sure it wasn’t a double. This would be especially awful if the
doubleclick delay is high.
Okay. I said we’d do this like Borland did in the VCL, which I’m sure most
people probably haven’t used, but I did explain it.
There would still be a mouse down and mouse up event that would be generated
the instant the mouse button went down or up. A click or double-click event
would be generated later. This would be useful specifically for point and
click games (like a RTS… like Starcraft). Basically, it would end up as a
totally new event type.> ----- Original Message -----
From: jimmy@jimmysworld.org (Jimmy)
To: “SDL Mailing List”
Sent: Wednesday, January 16, 2002 12:42 PM
Subject: Re: Re[2]: [SDL] Detecting Double ClicksI have to agree here. There are all sorts of nasty things that this
would cause if added. Any games that want better isolation of the mouse
would be in trouble. Even if you interpreted a double click as two
individual clicks, you’d lose the location of the first (or second)
click, and there’d be a latency issue because the system would never be
able to send ANY mouse event until the delay specified for a doubleclick
had expired because you couldn’t send a single until you were sure it
wasn’t a double. This would be especially awful if the doubleclick
delay is high.On Tue, 2002-01-15 at 16:56, Neil Griffiths wrote:
Hiya,
DB> Or if the proposed method of generating single click and double
clickDB> events seems better, perhaps SDL could have a default value, which
couldDB> be set automatically if the OS supports it and/or set by the
program.The idea of SDL is that it’s platform independent, so having parts
which work on only some OS’ is not a good idea.I’m also against having double click events anyway. If you’re creating
a game and you use mouse buttons as input, you may fire away happily.
You want to be looking for only one event, not two.Is it REALLY so hard to get the current time when a button is clicked
once and then once more when it’s clicked again, then compare the two?Neil.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–End of Rant.
Jimmy
JimmysWorld.org
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Granted that the signals could be sent seperately, but (and please,
correct me if I’m wrong here) wouldn’t you still have to wait
within the application to find out if a double click followed the single
click in order to behave correctly?
I simply don’t see how the addition of a double click signal of any
kind would be sufficiently useful considering the end application needs
to be aware of the double click delay anyway in order to wait long
enough after a single click to know whether to ignore it or not.
The only think I could see being useful is if the library was able to
report what the system default double click interval is, and that’s not
SDL’s job.
Even if it were useful, adding double click events would open the can of
worms of how many new events to add. After all, I’ve seen triple clicks
in applications before. Far fetched perhaps. But it seems to me that
if you include a special case like this, you’re taking on the
responsibility of all special cases in the same realm.
After saying all that, I can see how a timestamp would be useful in some
cases. BUT the vast majority of times I don’t think it would be, and
it would just waste memory needlessly, especially since a timestamp
measurement can be taken just as easily by the application.On Wed, 2002-01-16 at 14:18, David Olofson wrote:
On Wednesday 16 January 2002 19:42, Jimmy wrote:
I have to agree here. There are all sorts of nasty things that this
would cause if added. Any games that want better isolation of the
mouse would be in trouble. Even if you interpreted a double click as
two individual clicks, you’d lose the location of the first (or second)
click, and there’d be a latency issue because the system would never be
able to send ANY mouse event until the delay specified for a
doubleclick had expired because you couldn’t send a single until you
were sure it wasn’t a double. This would be especially awful if the
doubleclick delay is high.Actually, that’s not how most platforms handle double clicks, and there
would be no need for SDL to do it either. Commonly, if you “subscribe” to
all mouse button events, a double click from the user would give you
something like:
- mouse down
- mouse up
- click
- mouse down
- mouse up
- double click
If you don’t want double clicks, either disable the double click feature
altogether, handle the double click event just as if they were click
events, or just ignore the click events altogether and use the up/down
events instead.Obviously, in the case of SDL, the double click feature should be
disabled by default.Anyway, I have to agree with the No Double Clicks side; I don’t think
double click belongs in SDL, at least not in the primitive shape of an
explicit “you got a double click” event. (In fact, I don’t think double
clicks should be used at all, ever - but that’s another story.)Timestamped events OTOH, could be very useful, especially in cases where
you cannot reliably sustain a sufficient frame rate to poll and check the
timing in the application main loop.For those who want to (ab)use that for double click detection, another
handy thing would be a portable library that allows you to get the system
double click time and that kind of info. Maybe it makes sense to include
it in SDL from the implementation POV, but I doubt it.//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
End of Rant.
Jimmy
JimmysWorld.org
Jimmy wrote:
Granted that the signals could be sent seperately, but (and please,
correct me if I’m wrong here) wouldn’t you still have to wait
within the application to find out if a double click followed the single
click in order to behave correctly?I simply don’t see how the addition of a double click signal of any
kind would be sufficiently useful considering the end application needs
to be aware of the double click delay anyway in order to wait long
enough after a single click to know whether to ignore it or not.
When I single click on the recycle bin on my Windows desktop the bin
icon
is highlighted. When I double click on the bin it is highlighted and
then
it is opened. What Windows is doing is first performing the single click
behavior for an icon. And then, after it determines that I actuallly
double
clicked the icon, it is performing the double click behaviour for an
icon.
An application just gets events, it never has to worry about waiting out
the double click delay time because it just always does the single click
behavior followed by the double click behavior. And, applications often
know that certain regions of the screen (like the area occupied by
icons)
are supposed to respond to double clicks and applications just ignore
single clicks in those areas just like it can ignore double clicks in
areas where they don’t make sense.
Anyway, my opinion is that double clicks are bad, OK?
They are easy for an application to implement if they want to.
It would be a good idea to recommend a default double click
time for people who just have to have double clicks.
Bob P.Granted that the signals could be sent seperately, but (and please,
correct me if I’m wrong here) wouldn’t you still have to wait
within the application to find out if a double click followed the
single click in order to behave correctly?
If you have to, it’s usually because of a user interface design mistake.
(Or rather another design mistake, besides using double clicks in the
first place, IMHO.)
See Bob Pendleton’s description of how the Windows recycle bin behaves.
I simply don’t see how the addition of a double click signal of any
kind would be sufficiently useful considering the end application needs
to be aware of the double click delay anyway in order to wait long
enough after a single click to know whether to ignore it or not.
Simple: Expect one of two things; a single click, or a single click
followed by a double click - never a double click alone. In fact, I don’t
know of any toolkits or environments that will hide the first single
click of a “double click sequence” from you, so you have to do it this
way, or your applications won’t work.
The only think I could see being useful is if the library was able to
report what the system default double click interval is, and that’s not
SDL’s job.
That’s still a good point, though.
Even if it were useful, adding double click events would open the can
of worms of how many new events to add. After all, I’ve seen triple
clicks in applications before.
Older X apps (and some others - usually ported X apps) frequently detect
quadruple clicks as well. (Single: place cursor; double: select word;
triple: select line; quadruple: select all.)
Far fetched perhaps.
Not really.
But it seems to
me that if you include a special case like this, you’re taking on the
responsibility of all special cases in the same realm.
Exactly. That’s why I think it would be much better to include something
useful, like event timestamps, if anything at all.
After saying all that, I can see how a timestamp would be useful in
some cases. BUT the vast majority of times I don’t think it would
be, and it would just waste memory needlessly, especially since a
timestamp measurement can be taken just as easily by the application.
The problem is that if you’re doing heavy rendering, and your frame rate
drops too much, it’s not that easy to do any useful timestamping inside
the application. You need the timestamps generated by the driver/system,
or at least a separate thread.
Sure, you can use an extra thread, but I don’t think it’s very nice
dragging that in - with synchronization and portability issues, just to
get timestamps.
Note that many event/input APIs provide timestamps generated either by
the driver or the OS, so having SDL “doing” the timestamping would
completely eliminate the need for an extra thread in many cases.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 16 January 2002 20:48, Jimmy wrote:
Granted that the signals could be sent seperately, but (and please,
correct me if I’m wrong here) wouldn’t you still have to wait
within the application to find out if a double click followed the
single click in order to behave correctly?If you have to, it’s usually because of a user interface design mistake.
(Or rather another design mistake, besides using double clicks in the
first place, IMHO.)See Bob Pendleton’s description of how the Windows recycle bin behaves.
I checked out a couple of applications and this does seem to hold.
Though a big part of me screams “just because it is already done a way
doesn’t necessarily mean that way is correct”. For example a system
status program called gkrellm: Single click on a graph it adds
additional information to the display. Single click again the
additional info disappears. Double click and the configuration for that
graph comes up. In this case the multiple events cancel themselves out
because when you double click the info turns on and then back off again
as well as opening the configuration opening. That implies it receives
two single clicks and a double click. Blarg
Anyway… fish. I’m sick of double clicks.
I simply don’t see how the addition of a double click signal of any
kind would be sufficiently useful considering the end application needs
to be aware of the double click delay anyway in order to wait long
enough after a single click to know whether to ignore it or not.Simple: Expect one of two things; a single click, or a single click
followed by a double click - never a double click alone. In fact, I don’t
know of any toolkits or environments that will hide the first single
click of a “double click sequence” from you, so you have to do it this
way, or your applications won’t work.The only think I could see being useful is if the library was able to
report what the system default double click interval is, and that’s not
SDL’s job.That’s still a good point, though.
Even if it were useful, adding double click events would open the can
of worms of how many new events to add. After all, I’ve seen triple
clicks in applications before.Older X apps (and some others - usually ported X apps) frequently detect
quadruple clicks as well. (Single: place cursor; double: select word;
triple: select line; quadruple: select all.)Far fetched perhaps.
Not really.
But it seems to
me that if you include a special case like this, you’re taking on the
responsibility of all special cases in the same realm.Exactly. That’s why I think it would be much better to include something
useful, like event timestamps, if anything at all.After saying all that, I can see how a timestamp would be useful in
some cases. BUT the vast majority of times I don’t think it would
be, and it would just waste memory needlessly, especially since a
timestamp measurement can be taken just as easily by the application.The problem is that if you’re doing heavy rendering, and your frame rate
drops too much, it’s not that easy to do any useful timestamping inside
the application. You need the timestamps generated by the driver/system,
or at least a separate thread.Sure, you can use an extra thread, but I don’t think it’s very nice
dragging that in - with synchronization and portability issues, just to
get timestamps.Note that many event/input APIs provide timestamps generated either by
the driver or the OS, so having SDL “doing” the timestamping would
completely eliminate the need for an extra thread in many cases.
Ok, I’ll buy into this point. The added complexity involved with
ensuring an accurate reading probably isn’t worth it compared to the
relatively low cost of wasting timestamps.On Wed, 2002-01-16 at 15:59, David Olofson wrote:
On Wednesday 16 January 2002 20:48, Jimmy wrote:
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
End of Rant.
Jimmy
JimmysWorld.org
[…]
If there is any implementation of doubleclick, it should be this IMO. The
reasons are pretty obvious I should thinks.On Wed, Jan 16, 2002 at 08:18:57PM +0100, David Olofson wrote:
Actually, that’s not how most platforms handle double clicks, and there
would be no need for SDL to do it either. Commonly, if you “subscribe” to
all mouse button events, a double click from the user would give you
something like:
- mouse down
- mouse up
- click
- mouse down
- mouse up
- double click
–
Joseph Carter I swallowed your goldfish
There is no snooze button on a cat who wants breakfast.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020117/b92011ff/attachment.pgp