<div dir="auto"><div dir="auto">Thanks for great input.</div><div dir="auto"><br></div><div>I agree with everything and I am also not really sure about common use cases. Indeed, if there is a need for touchTime it would be possible to attach a TouchSensor in addition to a drag sensor to an UI element.</div><div dir="auto"><br></div><div dir="auto">Here is the other side. It may be more constructive to ask if there is any inherent, fatal conflict which requires preventing a touchtime event. In 2d, html allows for essentially any element to emit an onclick event, suggesting there may be no potential conflicts.</div><div dir="auto"><br></div><div dir="auto">It is always up to the scene author to ensure a good UI experience. So the question may really be if the author should be given an option which may be misused but could be useful in some cases given that similar, but not identical options are already available.</div><div dir="auto"><br></div><div dir="auto">Going through this argument, I am leaning towards just allowing touchtime events for all mouse sensors since it requires less code and does not impact performance.</div><div dir="auto"><br></div><div dir="auto">-Andreas<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Oct 25, 2017 7:19 PM, "Michalis Kamburelis" <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">2017-10-25 18:05 GMT+02:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>>:<br>
> touchTime is very similar to isActive except that the mouse still has<br>
> to be over the shape when the mouse button is released. Since isOver<br>
> and isActive are already fields for drag sensors, perhaps touchTime<br>
> should be as well.<br>
><br>
> touchTime is often used to get a startTime for an TimeSensor to<br>
> trigger an animation. So an example application would be have a drag<br>
> sensor which also acts as a start button; a bit contrived but not very<br>
> much so.<br>
><br>
> It is true that most of the times the mouse ends up outside of the<br>
> shape after dragging. So touchTime would not be useful as a trigger to<br>
> do something after dragging ends.<br>
><br>
> But I am looking more for examples where it would lead to some,<br>
> unintended conflict if touchTime were used on a drag sensor.<br>
><br>
<br>
</div>It is technically possible to implement touchTime on all<br>
pointing-device sensors, indeed. But I'm not sure is there a good<br>
use-case for it.<br>
<br>
touchTime is like an "OnClick" event of numerous UI libraries.<br>
<br>
If a drag sensor reacts to clicks (in addition to reacting to<br>
dragging)... it feels a bit surprising (from the user's point of<br>
view). When you drag something, you don't usually care where is the<br>
pointer at the end, the only thing that matters is how far you<br>
dragged. As you write, "most of the times the mouse ends up outside of<br>
the shape after dragging". It could be surprising that some behavior<br>
(generation of touchTime) is different depending on whether the mouse<br>
was inside or outside the shape at the end.<br>
<br>
Drag sensor is like a scrollbar in a traditional 2D UI, while<br>
TouchSensor is like a button. Handling "clicks" on a drag sensor is a<br>
bit like combining scrollbar with a button functionality. Traditional<br>
UIs don't do it --- if you click on a scrollbar, without moving your<br>
mouse, nothing happens.<br>
<br>
None of this is a strong argument against adding touchTime to other<br>
pointing-device sensors, so I may definitely be wrong :) I'm mostly<br>
following my intuitions from 2D UI here.<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div><br></div></div></div>