The fix looks good to me.
Thanks,
Alexandr.
On 7/14/2016 2:47 PM, Alexander Zvegintsev wrote:
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/we
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
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 com
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
I have found the way to avoid iterative queries for frame insets.
The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.01/
--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 eve
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
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
Looks good to me.
Thanks,
Alexander.
On 10/06/2015 09:15 AM, Semyon Sadetsky wrote:
Sorry. I meant it is not guaranteed to be sent by every WM.
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 Bylokh
Sorry. I meant it is not guaranteed to be sent by every WM.
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
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
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
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 t
12 matches
Mail list logo
