eclipse
Embed tracker for dragging flyout palette composite into control
The tracker for dragging the flyout palette is currently instantiated on the display rather than the control itself. This leads to offsets with monitor-specific scaling on Windows, as the display is lacking the monitor-specific zoom context.
This change adapts the tracker to operate on the flyout palette control rather than the display. It simplifies the implementation as the control/display coordinate conversions can be removed.
Fixes https://github.com/eclipse-gef/gef-classic/issues/868
Before
After
My only concern is that I wonder why the implementation used the (more complex) logic via the display at all and did not just embed it into the view.
Very seldom I see that palette is drawn over the tracker border
which then may also leave behind an artifact of the border aftwards
which will just disappear when any redraw is triggered (e.g., by hovering over it).
Maybe that was a reason or maybe the implementation even goes back to a time where trackers did not work (well) on controls.
My only concern is that I wonder why the implementation used the (more complex) logic via the display at all and did not just embed it into the view.
Originally, that's how the tracker was used, but this was later changed with 2c1baba3d9ddda6bb9eb63724182e5edd41e4ad7.
Apparently as part of a fix for Bug 66201 - Palette state is not maintained when switching from the view to the flyout
The order in which notification is fired has changed. Earlier, the workbench used to fire perspectiveChanged first and dispose the page later. Now, it disposes the page before firing perspectiveChanged notification. As a result, the palette state from the view is not transferred to the palette (although it works the other way around).
But this is about the palette view. I'm not sure how or why this has anything to do with the drag & drop feedback.
Thank you for the additional information.
I further investigated the issue and found that the SWT Tracker implementation does not correctly convert the event values. I have a preliminary solution for that which, with a minor change to the FlyoutPaletteComposite would also solve the issue while keeping the Tracker instantiated on the display: https://github.com/eclipse-platform/eclipse.platform.swt/pull/2799
But I consider that change too risky to still merge for the upcoming release, as for Platform we are already beyond RC1. So we could either accept the issue in GEF for now (as mentioned in https://github.com/eclipse-gef/gef-classic/issues/868, it has been there since multiple Eclipse releases when monitor-specific scaling is enabled) or we could go with this PR (not fully knowing about potential side effects).
Given that the issue already existed in the previous release, I would like to postpone this to the M1.