Fix click and drag functionality overlap in path tool in extended select

[singhutsav5502]

Resolves https://discord.com/channels/731730685944922173/881073965047636018/1347408498211815434

Send Path_tool FSM to Dragging state on MouseDown if clicking an already selected point.

[Keavon]

!build

[github-actions]

📦 Build Complete for 773ce48
https://a76df4e9.graphite.pages.dev

[0HyperCube]

This removes the functionality of removing a point from the selection by shift clicking on it.

[0HyperCube]

Thanks for the fix @singhutsav5502. However now you can't shift select points in the first place (they are selected on mouse down and deselected on mouse up).

shift_select_issue.mp4

[singhutsav5502]

Hi, it seemed to be working on my local build at first but broke when i tried it on a new document. I have pushed some changes and tried running it on a new document, seems to be working fine now. @0HyperCube
Though the storing of previously selected points could negatively affect performance, do tell me if there's anything i overlooked.

[Keavon]

My intuition is that this issue doesn't need to involve storing any new state such as the list of originally selected points just to filter out a Shift-click-and-drag, but do you agree @0HyperCube?

[singhutsav5502]

Honestly i feel the same, will give it a try. This can be treated as a temporary solution at best.

[singhutsav5502]

Hi, @Keavon @0HyperCube latest code push uses a boolean value instead of storing a state snapshot of the previous state selections.

[0HyperCube]

My intuition is that this issue doesn't need to involve storing any new state such as the list of originally selected points just to filter out a Shift-click-and-drag, but do you agree @0HyperCube?

In the current main branch, the shift click to deselect happens on pointer down. At this point we obviously don't know if the user is going to drag or not.

I would probably just move the deselect behaviour to the mouse up and only run it if there was no dragging. However there are many possible ways to solve the problem.

[singhutsav5502]

I would probably just move the deselect behaviour to the mouse up and only run it if there was no dragging. However there are many possible ways to solve the problem.

That's similar to what i have done in the last code push, while there doesn't seem to be a mouse_up, there is a DragStop event, that's where i have decided to put the logic of deselect when drag didn't occur. ( though i did end up using a boolean variable to make sure we didn't end up deselecting the points that was just selected ).

[Keavon]

I would probably just move the deselect behaviour to the mouse up and only run it if there was no dragging.

I suggest going with this. Thanks both of you!

[Keavon]

Checking in on the status.

[singhutsav5502]

Hi, @Keavon i was planning to hold of on any new commits until i am done coming up with a decent GSOC proposal. ( I do plan to make some draft PRs related to the areas of the proposals to get an idea of the expected code implementations. )
Same for #2423

[singhutsav5502]

I would probably just move the deselect behaviour to the mouse up and only run it if there was no dragging. However there are many possible ways to solve the problem.

Also, regarding this @Keavon @0HyperCube ,
The current implementation i have pushed is logically the same as this.
The only difference is that i had to include a boolean value since otherwise it would be impossible to differentiate between a node that was Shift Clicked for selection ( drag didn't occur ) and an Unselected node that was Clicked-> got selected on mouseDown -> Not Dragged -> Hence Unselected on Mouse Up.
This would create a situation where Newly selected nodes will get immediately Unselected if they are not dragged.
This is why i have used the boolean last_clicked_point_was_selected to make sure that the last clicked point was already selected Prior to the Mouse Down and hence needs to be unselected if a drag didn't occur on Mouse up ( in extended select mode )