Community
Participate
Working Groups
Hello, I'm working on an SWT reported bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=573150) that I believe can't be fixed at the SWT level. From reproducing this myself and running it through the debugger, I have found that JFace miscalculates the position of the hover frame because it chooses the wrong monitor in getClosestMonitor. Offsets in the monitors position or differences in resolution are not taken into account. The root of the problem is that getMonitors return monitors + their offsets relative to the primary monitor. So if one screen is 1920x1080, the secondary monitor has a x = 1920, y = 0, and it's resolution. However, the position reported to place the hover text is relative to the shell/Display, aka does not take into account which monitor it is on. This has only been reported for Linux, and unfortunately I can't test if this a bug on other platforms. If it is a Linux only problem, I will see how either Mac or Windows reports the monitor's attributes so that Linux can do the same.
I have experimented with the changing AbstractInformationControlManager, and have been successful in fixing the problem. However, I fixed it in a hacky/local way, as I don't know how my changes will affect other functions that use getClosestMonitor. Summary of my patch: - Instead of getting the closest monitor through distance calculation, just use the SWT control's getMonitor function to get to the monitor the fSubjectControl is on. - Remove the offset that is present in the return value of getMonitor, aka the x & y values should be set to 0 for the monitor's client area. If the x & y values are set, this messes with the intersect/contain functions since the point we check is relative to the Shell and not the whole physical display setup.
