Hi Semyon,
The fix looks good to me.
Thanks,
Alexander.
On 07/13/2016 01:28 PM, Semyon Sadetsky wrote:
Please review an updated version of the fix:
http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.02/
The solution was completely changed. The frame insets correction
algorithm is revised for Unity WM since it is defers from other WMs.
It seems the safest way to fix this issue and to avoid compatibility
issues.
--Semyon
On 3/24/2016 6:28 PM, Alexander Scherbatiy wrote:
On 18/02/16 14:26, Semyon Sadetsky wrote:
I have found the way to avoid iterative queries for frame insets.
The updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.01/
- 269 if (wm_set_insets != null && !isNull(wm_set_insets))
isNull(Insets i) function checks the given argument to null. It seems
that the first check is unnecessary in this case.
- Could not null insets with zero values be valid insets?
- 396 if (!isNull(correction)) {
Could this construction be changed to "if (isNull(correction)) {
return; }" ?
- if (!insets_corrected && getDecorations() !=
XWindowAttributesData.AWT_DECOR_NONE) {
+ if (getDecorations() != XWindowAttributesData.AWT_DECOR_NONE) {
handleReparentNotifyEvent() calls XWM.getWM().getInsets(this,
xe.get_window(), xe.get_parent())
in case correctWM is null but handleConfigureNotifyEvent() is updated
to do it even insets has been corrected.
What is the reason to handle these two cases differently?
- Could you run JCK with the provided fix to check that there are no
regressions?
Thanks,
Alexandr.
--Semyon
On 10/29/2015 12:20 AM, Sergey Bylokhov wrote:
On 06.10.15 9:15, Semyon Sadetsky wrote:
Sorry. I meant it is not guaranteed to be sent by every WM.
But fetch the data of 100 times also doesn't guarantee that we
will get the necessary data. It will be better at least to try to
check the specified atom for this(it seems it is supported by all
our platfrom). For example on osx insets can be changed on the fly
w/o notification, because of this we fetch the insets on each
reshapeEvent and posts the necessary message up to hierarchy.
On 10/6/2015 9:03 AM, Semyon Sadetsky wrote:
In is extended event. In does not guaranteed to be sent by any WM.
On 10/5/2015 6:12 PM, Sergey Bylokhov wrote:
Why we cannot treat such a XA_NET_FRAME_EXTENTS as a
ConfigureNotify
in which only insets are changed, and the window bounds/insets
should
be revalidated?
On 05.10.15 14:56, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8036915
webrev: http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.00/
The test scenario attached to the jira contains potential errors
because
Componet.getLocation() won't return the location at any moment
of time.
Anyway a window location issue exists in Unity. The root cause
is that
the real insets sent with the XA_NET_FRAME_EXTENTS event can be
overridden by the "guessed" insets which are zero on Unity. So the
returned location is increased by real insets while the real
window
location is correct.
Yet another issue I found in Unity is a window size issue which
is also
caused by the frame insets detection. The Unity WM doesn't
provide the
frame insets immediately and XA_NET_FRAME_EXTENTS event may
come after
the ConfigureNotify event for the frame.
The solution proposes an adaptation of the existing frame insets
request
algorithm to the Unity WM so that makes it more stable.
--Semyon
