Multiple-click events

Fri May 11 02:44:44 PDT 2012

Hi Pavel,

Thank you for your efforts! "Bad UI design" seems to be a good reason 
for not allowing it. Let's see if there are any other cases.

Best regards,
Alexander Kouznetsov

On 09.05.2012 15:20, Pavel Safrata wrote:
> Hello,
> I tried to get approval for the new event and our architects raised 
> the same objections I've had: "I don't really think we should add this 
> API. It just doesn't seem like something any UI should be doing. It 
> seems in every case we could think of when a single, double, triple 
> click is associated with a single node (such as Text, etc), the double 
> click builds upon what the single click did, and the triple click 
> builds on what the double click did. It is never a case where the 
> double click is going to do something quite different from a single 
> click, and if such a situation comes up, it seems bad UI design." ... 
> "We think we ought not go down this road."
>
> I completely agree and won't add the functionality unless a really 
> compelling use-case is presented. Switching an application to 
> full-screen can definitely be solved other way (without introducing 
> unnecessary waiting for each slide). Shanliang, you claimed 
> SceneBuilder needs this, what is your use-case?
>
> Thanks,
> Pavel
>
> On 2.5.2012 17:49, Alexander Kouznetsov wrote:
>> Hi Pavel,
>>
>> I believe ClickSequenceFinished is an interesting event that may be 
>> useful.
>>
>> I have two usecase:
>>
>>  1. Presentation app
>>       * one click to proceed to next slide
>>       * double-click to enter fullscreen mode
>>  2. MediaPlayer
>>       * one click to pause
>>       * double-click to enter fullscreen mode
>>
>> Actually second example works without this event (by pausing on first 
>> click and playing again on second one). But the first one doesn't.
>>
>> Best regards,
>> Alexander Kouznetsov
>>
>> On 30.04.2012 16:33, Pavel Safrata wrote:
>>> Hello,
>>> we discussed the matter again, considering all the raised issues. We 
>>> agree that the delay really is a problem. We cannot find any common 
>>> use-case in the native environments that would do an action on 
>>> single-click that wouldn't be done as part of a double click. I 
>>> think this pattern should be strongly discouraged, because it will 
>>> make the UI feel pretty laggy (and thus FX seem slow). Default 
>>> timeout on Windows is over half a second and can be increased by 
>>> user to more than two and a half. Waiting any noticeable time for a 
>>> click to be recognized would bother almost everybody I think, even 
>>> the half-second is a multiple of the recommended reaction time.
>>>
>>> We're not happy this is requested for our internal tools. We can, 
>>> however, fulfill the request by a new event, something like 
>>> ClickSequenceFinished, but we don't want to promote this so there 
>>> would be no setOn* method. It would be possible for the special 
>>> cases to add a handler for this event to find out when user finished 
>>> clicking.
>>>
>>> Is that acceptable?
>>> Thanks,
>>> Pavel
>>>
>>> On 27.4.2012 18:33, kimtopley at gmail.com wrote:
>>>> Selection was only an example. The point is that there are cases 
>>>> where the single-click response will be required immediately, while 
>>>> a different double-click action is required as and when the double 
>>>> click occurs. For clarity, it would be better if both actions were 
>>>> triggered from the same event handler, as they are today. This 
>>>> change forces me to rewrite my code so that the single-click action 
>>>> can be called both on mouse released and on mouse clicked. Having 
>>>> an opt-in for the new behavior would also avoid breaking existing 
>>>> code.
>>>>
>>>> Sent from my Verizon Wireless BlackBerry
>>>>
>>>> -----Original Message-----
>>>> From: Alexander Kouznetsov<alexander.kouznetsov at oracle.com>
>>>> Date: Fri, 27 Apr 2012 20:25:35
>>>> To:<kimtopley at gmail.com>
>>>> Cc: Jeff Martin<jeff at reportmill.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
>>>>
>>>> Usually selection occurs on mousePressed or even on mouseEntered 
>>>> events.
>>>> mouseReleased and mouseClicked events may arrive much later because 
>>>> you
>>>> can hold the mouse button pressed.
>>>>
>>>> Best regards,
>>>> Alexander Kouznetsov
>>>>
>>>>
>>>> On 27.04.2012 20:21, kimtopley at gmail.com wrote:
>>>>> The user will be able to tell that I did that, because the first 
>>>>> click will be slower to arrive than it otherwise would have been, 
>>>>> in the case where the user just clicks once, right? So now there 
>>>>> is a "long" delay after the first click when the user sees nothing 
>>>>> happening at all.
>>>>>
>>>>> Sent from my Verizon Wireless BlackBerry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alexander Kouznetsov<alexander.kouznetsov at oracle.com>
>>>>> Date: Fri, 27 Apr 2012 20:17:43
>>>>> To:<kimtopley at gmail.com>
>>>>> Cc: Jeff Martin<jeff at reportmill.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
>>>>>
>>>>> I don't see any problem here. You can select it on first click or on
>>>>> second click - that is still the same place.
>>>>>
>>>>> Best regards,
>>>>> Alexander Kouznetsov
>>>>>
>>>>>
>>>>> On 27.04.2012 20: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
>>>>>>>>