Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SelectAction is issued too early in some cases #80

Open
NiklasRentzCAU opened this issue Apr 3, 2019 · 1 comment
Open

SelectAction is issued too early in some cases #80

NiklasRentzCAU opened this issue Apr 3, 2019 · 1 comment

Comments

@NiklasRentzCAU
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants