K. K. Subramaniam wrote:
> On Sunday 02 Aug 2009 7:52:57 am Juan Vuletich wrote:
>   
>>> Nice feature. But a hold (tap and wait) is different from a click.
>>> Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting
>>> time can be checked?
>>>       
>> It could, I guess. What's the problem with how I did it (in
>> ##waitForSimulatedYellow:event:)?
>>     
> I couldn't reset the cursor position using a click on the selection (imagine 
> the whole text is selected. How do I cancel it?). I couldn't reselect a 
> subtext within selection using a drag. If the word "thisisalongword" is 
> selected and you try dragging "long", the selection shortens to "thisisalong". 
> I traced this annoyance to TextEditor>>mouseDown:
> 	(oldInterval includes: b stringIndex) ifTrue: [ ^self ].
>   

That line of code has this comment above:
"If click is inside the selection, do not modify it.
    This is so the 'tap and wait' gesture (used to bring pop-up menu
    on pen devices) does not affect selection, allowing to do copy / paste
    of selection with menu on pen devices."

If you remove that line, then when opening the menu, to do, for example, 
'copy', you always lose the selection first.

> If the gesture is detected at mouseUp time, then there is no ambiguity between 
> quick click, long click and double-click.
>   

The problem is that click and drag, to select, is done in #mouseMove:, 
i.e. before #mouseUp:. So the decision on wether to keep the selection 
unchanged (because a menu request could follow) and allow the user to 
modify the selection, needs to be done in #mouseDown: / #mouseMove:

Play a bit with the code. If you come up with something that works 
better, I'd be really happy.

> Press-to-popup menu violates principle of least astonishment. If the mouse is 
> moved slightly during a slow click, the menu popups, an item gets picked and 
> the popup disappears in flash leaving no time to see which item got picked.
>   

I agree. But I don't know a better way to do it, and pen computers do it 
like that.

The only solution I see is to add a preference to enable press-to-menu 
only if you want it.

> BTW, when you eliminated scroll bars for fully visible lists and texts, you 
> also eliminated the context menu button at the top :-(.
>   

That's what the press-to-menu gesture is for, right? They are not hard 
to add back. But I think it makes no sense to have a scrollbar that has 
nothing to scroll.

> Subbu

Cheers,
Juan Vuletich