Multiple-click events

[kimtopley at gmail.com]

True, apart from the delay that you added to the notification of the first click....which is what would force me to use mouse released instead. 


Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Pavel Safrata <pavel.safrata at oracle.com>
Date: Fri, 27 Apr 2012 18:21:31 
To: <kimtopley at gmail.com>
Cc: Alexander Kouznetsov<alexander.kouznetsov at oracle.com>; Jeff Martin<jeff at reportmill.com>; <openjfx-dev-bounces at openjdk.java.net>; openjfx-dev at openjdk.java.net<openjfx-dev at openjdk.java.net>; VIENOT, SIMON<simon.vienot at oracle.com>; Richard Bair<Richard.Bair at oracle.com>
Subject: Re: Multiple-click events

The proposal solves specifically this issue - with the proposed change 
you can always use click handler and check for the clickCount. Today, if 
you do that, double click will cause your code to perform both actions.

Pavel

On 27.4.2012 18:15, kimtopley at gmail.com wrote:
> That doesn't seem right to me. If I want to take one action on single click (eg select a row) and another on double click (eg open the row content in another editor), I will be forced to implement one of those actions when processing mouse released and the other in mouse clicked, whereas today that code would all be in the same place. For this use case, shouldn't it be possible to opt out of this behavior?
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Alexander Kouznetsov<alexander.kouznetsov at oracle.com>
> Date: Fri, 27 Apr 2012 20:09:09
> To: Jeff Martin<jeff at reportmill.com>
> Cc:<kimtopley at gmail.com>; Pavel Safrata<pavel.safrata at oracle.com>;<openjfx-dev-bounces at openjdk.java.net>; openjfx-dev at openjdk.java.net<openjfx-dev at openjdk.java.net>; VIENOT, SIMON<simon.vienot at oracle.com>; Richard Bair<Richard.Bair at oracle.com>
> Subject: Re: Multiple-click events
>
> This code is something we want to avoid.
>
> If people want to handle first click without any delays that can just
> handle mouseReleased event.
>
> Best regards,
> Alexander Kouznetsov
>
>
> On 27.04.2012 19:51, Jeff Martin wrote:
>> It seems a little dangerous to arbitrarily delay all initial mouse clicks. Does Swing do anything like this? I've never run into a problem with processing both single and double clicks, but if it was an issue, isn't there some kind of event peek that could easily be done:
>>
>> 	if(mouseEvent.getClickCount()==1) {
>> 		Thread.sleep(200);
>> 		if(EventDispatcher.peek(MouseEvent.MOUSE_CLICKED!=null) return;
>> 		<   … handle single click normally …>
>> 	}
>>
>> If that isn't there, could that be added instead?
>>
>> jeff
>>
>>
>> On Apr 27, 2012, at 10:23 AM, kimtopley at gmail.com wrote:
>>
>>> Would it be possible to make this configurable, maybe at the Scene level? In some cases, a single click is all that's required and the delay waiting for a second click that means nothing more to the application is unnecessary.
>>>
>>>
>>> Sent from my Verizon Wireless BlackBerry
>>>
>>> -----Original Message-----
>>> From: Pavel Safrata<pavel.safrata at oracle.com>
>>> Sender: openjfx-dev-bounces at openjdk.java.net
>>> Date: Fri, 27 Apr 2012 17:17:10
>>> To: openjfx-dev at openjdk.java.net<openjfx-dev at openjdk.java.net>
>>> Cc: VIENOT, SIMON<simon.vienot at oracle.com>; Alexander Kouznetsov<alexander.kouznetsov at oracle.com>; Richard Bair<Richard.Bair at oracle.com>
>>> Subject: Multiple-click events
>>>
>>> Hello,
>>> currently we deliver MOUSE_CLICKED event any time a node was pressed and
>>> released by mouse; if the next press happens fast enough and near
>>> enough, we increase the clickCount number for the events. There are
>>> requests to make a standalone single-click distinguishable from a first
>>> click of a double-click (and so on).
>>>
>>> After some discussion we concluded that the cleanest approach would be
>>> somewhat backward incompatible - we propose to generate the click event
>>> only when we are sure that there is no next click. In other words, the
>>> partial clicks would not be delivered at all, the final click would be a
>>> bit delayed. The pressed/released events would of course be still
>>> delivered normally, with the correct clickCount value.
>>>
>>> Any objections?
>>>
>>> Thanks,
>>> Pavel
>>>