<AWT Dev> <Awt Dev> [9] Review Request for 8036915: setLocationRelativeTo stopped working in Ubuntu 13.10 (Unity)

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Thu Mar 24 15:28:03 UTC 2016

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 


> --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

More information about the awt-dev mailing list