On windows is changed in awt_Window.cpp. WmMove
What I see there:
(env)->SetIntField(target, AwtComponent::xID, rect.left);
(env)->SetIntField(target, AwtComponent::yID, rect.top);
Are you talking about size or screen position?
The initial window size is preserved on Windows. On OSX it can be
different if notifyReshape() is called upon window create.
I don't see any extra issues related to the size currently.
--Semyon
In general window manager can set a different size/location than we
try to set, so we should take a correct values in the callback and
update the target component, and after that post event that the bounds
was changed.
- the utility method was introduced because decorated window can be
moved and it is utilized from several places. It is not the case for
undecorated window.
It can be moved by the window manager.
Not sure that container screen position makes any sense for its
content size event. Is it specified somewhere? Or can you provide an
example when it is necessary?
I am not sure. It needs to be checked.
--Semyon
On 7/31/2015 4:14 PM, Sergey Bylokhov wrote:
Hi, Semyon.
A few questions.
- Why only location is fixed, an update of size if not necessary(if
for some reason the size was changed by the system like location in
this case)?
- Note that we should update the target state before we post an
event that the size is changed(we post them in
XWindow.handleConfigureNotifyEvent). It seems that some of the peers
has utility methods for this(like XDecoratedPeer.handleMoved).
On 31.07.15 11:52, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8011616
webrev: http://cr.openjdk.java.net/~ssadetsky/8011616/webrev.00/
WM sends the real window position in the configuration event but
window peer does not set it to the target. Solution is: do set.
--Semyon
--
Best regards, Sergey.
--
Best regards, Sergey.
