On 23.09.16 20:40, Semyon Sadetsky wrote:
Screen in our specification is a our own term. We have GraphicsDevice
per screen. We have s special notion about "combined virtual screen"
which "share the same coordinate system". Our methods and
specification are not depends from the native WM implementation. In
the current discussion toolkit should return the bounds of the primary
screen which is default GraphicsDevice. So in the current fix the code
related to popup menu should be updated. The new bug should be filed
against toolkit.
Sorry, i didn't get what do you think should be updated in the current
fix? This is a regression fix. I just reverted part of the previous
patch to fix the problem. And in all places I changed the whole desktop
size should be used, not a primary monitor screen size. And
Toolkit.getScreenSize() has been always returning the whole desktop.
If you think that Toolkit.getScreenSize() should be changed to return
the monitor-1 size, I don't mind to file a separate bug. I'm sure it
will require to revise a lot of usages of the method including those
you've mentioned. Probably, it will cause compatibility issues and will
not be approved then. So, how is that related to the current fix?
The current bug in popup menu is that it relied on the incorrect
behavior of the toolkit method, which right now returns the size of the
virtual screen(and returns something strange in case of HiDPI+nonHiDPi
screens).
--
Best regards, Sergey.
