search

eclipse-sprotty / sprotty

A diagramming framework for the web
https://sprotty.org/
Eclipse Public License 2.0
723 stars 83 forks source link

SelectAction is issued too early in some cases #80

Open NiklasRentzCAU opened 5 years ago

NiklasRentzCAU commented 5 years ago

This line of code is executed on any selectable element on mouseDown: https://github.com/eclipse/sprotty/blob/8b297c58f19ce6f6f1c5ccfa2d49fbff8cf24ce8/src/features/select/select.ts#L211

This causes a SelectAction to be issued. I think this is too early and the SelectAction should be issued on mouseUp if the mouse has not moved after its last mouseDown.

Imagine the following case: We have non-draggable but selectable diagram elements represented by a textual file in an xtext grammar (Similar to some parts of the yangster example). Clicking on the diagram ist mostly used to just drag the entire diagram canvas around to browse within the diagram. We do not want the element that the mouse happens to be clicking while dragging to be selected because that causes the text file to select the corresponding code via tracing and other more specific behavior that happens when an element is selected. The editor switching its cursor is really unwanted in that case.

At least in such a case the SelectAction really should only be sent on mouseUp, but I know from your other examples (such as theia-xtext-sprotty-example) that the selection is important to be happening during mouseDown already so that moving around the selected elements works.

An idea I have is to maybe separate the mouseDown and the mouseUp selections or introduce some other action that can be listened to to differentiate between these two usages.

spoenemann commented 5 years ago

We should revisit the mouse listeners altogether and aim at better decoupling the various interactions. Maybe the new IToolManager API can help?