Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8165619
webrev: http://cr.openjdk.java.net/~ssadetsky/8165619/webrev.00/
If frame is created in maximized the window extent property notification
is not send by WM. So, ConfigureNotify event is skipped and the ta
On 01.09.16 16:41, Semyon Sadetsky wrote:
On 31.08.2016 21:18, Sergey Bylokhov wrote:
On 31.08.16 17:18, Semyon Sadetsky wrote:
Toolkit.getDefaultToolkit().getScreenSize()
was replaced by
graphicsConfig.getBounds();
that returns a particular screen area which is not the same as the joint
s
On 23.09.2016 16:51, Sergey Bylokhov wrote:
On 01.09.16 16:41, Semyon Sadetsky wrote:
On 31.08.2016 21:18, Sergey Bylokhov wrote:
On 31.08.16 17:18, Semyon Sadetsky wrote:
Toolkit.getDefaultToolkit().getScreenSize()
was replaced by
graphicsConfig.getBounds();
that returns a particular s
On 23.09.16 17:00, Semyon Sadetsky wrote:
On 31.08.16 17:18, Semyon Sadetsky wrote:
Toolkit.getDefaultToolkit().getScreenSize()
was replaced by
graphicsConfig.getBounds();
that returns a particular screen area which is not the same as the
joint
screen area in case of Xinerama multi-monitor co
On 23.09.2016 17:31, Sergey Bylokhov wrote:
On 23.09.16 17:00, Semyon Sadetsky wrote:
On 31.08.16 17:18, Semyon Sadetsky wrote:
Toolkit.getDefaultToolkit().getScreenSize()
was replaced by
graphicsConfig.getBounds();
that returns a particular screen area which is not the same as the
joint
s
On 23.09.16 17:35, Semyon Sadetsky wrote:
that returns a particular screen area which is not the same as the
joint
screen area in case of Xinerama multi-monitor configuration.
Can you please clarify what is the difference between two methods in
this bug? Toolkit.getScreenSize() is related to th
On 23.09.2016 17:49, Sergey Bylokhov wrote:
On 23.09.16 17:35, Semyon Sadetsky wrote:
that returns a particular screen area which is not the same as the
joint
screen area in case of Xinerama multi-monitor configuration.
Can you please clarify what is the difference between two
methods in
t
On 21.09.16 16:01, Manajit Halder wrote:
Access to "instance" is not broken. The problem is with the dictionary
variable "javaToMacKeyMap" within the "instance" reference.
The dictionary is not getting initialised for the second time when
singleton method is called for the second time. The dictio
On 23.09.16 18:46, Semyon Sadetsky wrote:
I do not get it. Toolkit.getScreenSize() should return the size of
the
primary screen which is default screen device in terms of
GraphicsEnvironment.
No, it is a whole desktop size (joint virtual screen in case of
multi-monitor). It has been working that
On 23.09.2016 19:03, Sergey Bylokhov wrote:
On 23.09.16 18:46, Semyon Sadetsky wrote:
I do not get it. Toolkit.getScreenSize() should return the size of
the
primary screen which is default screen device in terms of
GraphicsEnvironment.
No, it is a whole desktop size (joint virtual screen in ca
On 23.09.16 19:22, Semyon Sadetsky wrote:
Because it should return the bounds of the primary screen, not
"combined virtual screen". Also its spec should be updated to mention
units instead of real pixels which differs in HiDPI.
Screen is a platform dependent term. In case Xinerama is on there is
On 21.09.16 16:01, Manajit Halder wrote:
Hi Sergey,
Thanks for the comment.
Access to "instance" is not broken. The problem is with the dictionary
variable "javaToMacKeyMap" within the "instance" reference.
The dictionary is not getting initialised for the second time when
singleton method is c
On 23.09.2016 19:31, Sergey Bylokhov wrote:
On 23.09.16 19:22, Semyon Sadetsky wrote:
Because it should return the bounds of the primary screen, not
"combined virtual screen". Also its spec should be updated to mention
units instead of real pixels which differs in HiDPI.
Screen is a platform
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 implement
On 23.09.2016 20:52, Sergey Bylokhov wrote:
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
specificati
On 23.09.16 21:07, Semyon Sadetsky wrote:
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).
It is not clear yet that behavior of
On 23.09.2016 21:26, Sergey Bylokhov wrote:
On 23.09.16 21:07, Semyon Sadetsky wrote:
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
Looks good to me.
--
Thanks,
Alexander.
On 23.09.2016 16:15, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8165619
webrev: http://cr.openjdk.java.net/~ssadetsky/8165619/webrev.00/
If frame is created in maximized the window extent pr
Looks good to me.
--
Thanks,
Alexander.
On 26.04.2016 16:14, Semyon Sadetsky wrote:
On 4/26/2016 3:49 PM, Philip Race wrote:
> In applications one may need to know the reason why focus is requested
I do not mean why should apps want to *know* the cause.
I am asking why apps should be able
19 matches
Mail list logo
