Embed tracker for dragging flyout palette composite into control

[HeikoKlare]

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 #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.

[ptziegler]

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 2c1baba.

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.

[HeikoKlare]

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: eclipse-platform/eclipse.platform.swt#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 #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).

[ptziegler]

Given that the issue already existed in the previous release, I would like to postpone this to the M1.