Should this test start on OSX? I think we can tweak the platforms via
@req tag.
On 21.09.16 21:04, Ajit Ghaisas wrote:
Hi,
Bug :
https://bugs.openjdk.java.net/browse/JDK-8058950
Issue :
Minimized test frame cannot be restored.
Fix :
1. The test fix is quite simple - to introduce
The signature of the NSEvent constructor is changed.
It is called from AWTView.m (fixed) and CTrayIcon.m (!not fixed!)
Could you please support not only the phase start, but the phase end too?
It will be useful, when we decide to support precise scrolling in JScrollPane,
because we will be able to
Thanks, I will wait a bit before pushing in case awt-dev folks have any
input. -Pete
On 9/28/16 12:22 PM, Alexander Scherbatiy wrote:
> The fix looks good to me.
>
> I have also added awt-dev alias because fix changes the native part.
>
> Thanks,
> Alexandr.
>
> On 26/09/16 16:22, Anton Tarasov w
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8166591/webrev.03
- NSEvent constructor call is updated in the CTrayIcon.m
- The SCROLL_MASK_PHASE_CANCELLED and SCROLL_MASK_PHASE_ENDED scroll
masks are added.
Thanks,
Alexandr.
On 29/09/16 17:29, Sergey Malenk
On 9/27/2016 7:09 PM, Sergey Bylokhov wrote:
On 04.08.15 14:54, Semyon Sadetsky wrote:
On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
Hi, Semyon
Did you try to change dwMilliseconds from INFINITE to the timeout(10
seconds by default?) which is passed to the method? It does not help?
Because even
On 27/09/2016 16:41, Alan Burlison wrote:
Done, new webrev at http://cr.openjdk.java.net/~alanbur/JDK-8165232.v2/
Does this look OK?
--
Alan Burlison
--
It is OK for me. Thanks!
The fix is tested. The patch for 8u is attached.
It slightly differs because of changed codebase.
Could you please read comments about "deazone" in the following issue:
https://youtrack.jetbrains.com/issue/IDEA-158500
Is DELTA_THRESHOLD introduced to solve such a deadzone?
> Could you please read comments about "deazone" in the following issue:
> https://youtrack.jetbrains.com/issue/IDEA-158500
> Is DELTA_THRESHOLD introduced to solve such a deadzone?
If your scroll gesture on a trackpad is very slow,
a list will be scrolled by a single line after unexpected delay:
Hi Alexander,
The fix looks good.
I guess the second callback parameter was added by mistake initially.
Also I noticed after menu items added/removed a number of times GTK
prints messages:
(java:20921): GLib-CRITICAL **: g_hash_table_insert_internal: assertion
'hash_table != NULL' failed
On 29.09.16 9:54, Semyon Sadetsky wrote:
We have two bugs:
- This bug is about menu related code, it should care about bounds of
gc where these popup will be shown, it should not use the method which
return the bounds of the primary screen. In current fix the location
will be incorrect if Xinera
> - The SCROLL_MASK_PHASE_CANCELLED and SCROLL_MASK_PHASE_ENDED scroll masks
> are added.
Could you please use these masks in your fix?
Look at the following scenario:
- Perform slow and short scroll gesture
- Accumulator is less than threshold
- All wheel events during this gesture has wheelRota
On 29.09.2016 21:22, Sergey Bylokhov wrote:
On 29.09.16 9:54, Semyon Sadetsky wrote:
We have two bugs:
- This bug is about menu related code, it should care about
bounds of
gc where these popup will be shown, it should not use the method
which
return the bounds of the primary screen. In cu
On 29.09.16 21:30, Sergey Malenkov wrote:
- The SCROLL_MASK_PHASE_CANCELLED and SCROLL_MASK_PHASE_ENDED scroll masks
are added.
Could you please use these masks in your fix?
Look at the following scenario:
- Perform slow and short scroll gesture
- Accumulator is less than threshold
- All wheel
On 29.09.16 21:35, Semyon Sadetsky wrote:
This is a part of HiDPI support. The popup code should use the bounds
of the screen where it is located. It should not depend from the
method which:
- Support data for the main screen only.
- Even for this screen it returns incorrect data.
I did not ge
> - The SCROLL_MASK_PHASE_CANCELLED and SCROLL_MASK_PHASE_ENDED scroll masks
> are added.
Now we use the scrollMask value and the following constants:
static final int SCROLL_MASK_WHEEL = 1;
static final int SCROLL_MASK_TRACKPAD = 1 << 1;
static final int SCROLL_MASK_PHASE_BEGAN = 1 << 2;
static
>> Look at the following scenario:
>> - Perform slow and short scroll gesture
>> - Accumulator is less than threshold
>> - All wheel events during this gesture has wheelRotation=0
>> - Nothing is scrolled actually.
>> - Repeat several such gestures - nothing is scrolled
>
> Just to clarify, if you
On 29.09.2016 21:55, Sergey Bylokhov wrote:
On 29.09.16 21:35, Semyon Sadetsky wrote:
This is a part of HiDPI support. The popup code should use the bounds
of the screen where it is located. It should not depend from the
method which:
- Support data for the main screen only.
- Even for this
On 29.09.16 22:08, Sergey Malenkov wrote:
Just to clarify, if you perform slow scroll gesture and the accumulator will
be less than threshold means that you should not scroll, no? Because the sum
of overall scroll events are less than one line. The fact that you need to
"move a certain minimum di
On 29.09.16 22:14, Semyon Sadetsky wrote:
The previous way "to get screen bounds" is incorrect, and we will get
the same bug when toolkit method will be changed.
May be it is incorrect but it is working. It is better than correct and
not working. It seems we have returned to the beginning of the
> It depends from the application, just checked on the list of emails in the
> Thunderbird which have small "deadzone". I think we should not do any magic
> in this files. only get native event and post it to upper level(the int
> value should be accumulated) And this is responsibility of upper lev
value should be accumulated) And this is responsibility of upper level to do
some work depending from the MouseWheelEvent.
But we already did some magic to support mouse event.
On the top level I have no access to the phase values.
But how this values helps you? If we roundup the accumulator o
>> But we already did some magic to support mouse event.
>> On the top level I have no access to the phase values.
>
> But how this values helps you? If we roundup the accumulator on the "end
> phase" the scroll will be slow in the middle phase, no?
I want to support short gestures like we support
On 29.09.2016 22:35, Sergey Bylokhov wrote:
On 29.09.16 22:14, Semyon Sadetsky wrote:
The previous way "to get screen bounds" is incorrect, and we will get
the same bug when toolkit method will be changed.
May be it is incorrect but it is working. It is better than correct and
not working. It
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8166591/webrev.04
The fix uses the proposed changes below and sets a wheel rotation to +1
or -1 when the scroll phase is ended and the accumulates delta value is
small than the threshold.
Thanks,
Alexandr.
On 29
Alexander, please ignore my comment about glib error messages. I cannot
reproduce them anymore. It seems I got them before your fix.
--Semyon
On 29.09.2016 21:11, Semyon Sadetsky wrote:
Hi Alexander,
The fix looks good.
I guess the second callback parameter was added by mistake initially.
A
25 matches
Mail list logo
