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

Routing Point can not be moved #657

Closed
rsoika opened this issue May 22, 2022 · 3 comments
Closed

Routing Point can not be moved #657

rsoika opened this issue May 22, 2022 · 3 comments
Assignees
Labels
bug Something isn't working
Projects

Comments

@rsoika
Copy link

rsoika commented May 22, 2022

I observer some kind of Bug regarding the Routing points in an Edge. I am not sure if this is related to Sprotty, if so, I will move this issue. Also maybe the bug is already known and I am using only an old glsp client version - 0.10.0-next.385713d.170 ?

Problem description:

If you place an edge between to nodes in line and than select the edge, you will see 3 routing points.

  • the start point
  • the end point
  • and a virtual routing point in the middle.

You can't move the virtual routing point in the middle. And in deed the edge did not have any routing point. The collection is empty in such a situation.

If you than move one element the routing changes and now you can see 5 Routing Points

  • the start point
  • the end point
  • one real existing Routing Point which is relevant for the model
  • and two virtual routing points in the middle of each section

From now on everything works like expected. You can move all 3 routing points and the ChangeRoutingPointsOperation event is send correctly providing 1(!) new routing Point.

If you move the element now back in line and move the routing points so that you have again a direct connection the problem occurs again - now the edge has again no more routing point (which is correct) but you can not grap the virtual routing point with the mouse.

Peek 2022-05-22 10-07

@rsoika rsoika added the bug Something isn't working label May 22, 2022
@tortmayr
Copy link
Contributor

Thanks for reporting this. It looks to me like this is a bug in GLSP when using manhattan routing. Everything works as expected for polyline routing but with manhattan I can reproduce the issue:
Peek 2022-05-23 16-28

@martin-fleck-at
Copy link
Contributor

Turns out this is actually a bug in Sprotty itself. I opened a bug there: eclipse-sprotty/sprotty#310

@martin-fleck-at
Copy link
Contributor

@rsoika I close this issue as the original problem is solved if that is fine with you. If we need a better user experience, please feel free to open another issue.

GLSP kanban automation moved this from Backlog to Done Dec 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
GLSP kanban
  
Done
Development

No branches or pull requests

3 participants