Our helpful SQE engineer has verified that this works as well as previously.
And I've done some basic testing myself on Ubuntu 16.04, so "+1"
(meaning approved).
-phil.
On 09/27/2016 08:41 AM, Alan Burlison wrote:
On 26/09/2016 23:42, Philip Race wrote:
So that looks like it should work al
Looks good.
Erik
On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
This is request to deprecate the obsolete flags inside InputEvent. This
constants were marked as obsolete in jdk1.4 and were replaced by the new one.
In jdk1.4 the documentation wer
Hi Sergey,
I'm not a reviewer, but after reading the deprecation messages in Event.java
* @deprecated It is recommended that {@code AWTEvent} class and its
> subclasses
> * be used instead.
I get the impression they would read better without the redundant "class"
in the middle, like
Also, I can't understand what DELTA_THRESHOLD means?
It increases a pause before scrolling, which is not comfortable for me.
>>>
>>> Yes. I is just a barrier before which the wheel rotation event is not
>>> counted.
>>
>> The default 0.5 from Math.round is more comfortable.
>>
>> Could yo
On 30/09/16 19:48, Alexander Scherbatiy wrote:
On 30/09/16 19:33, Sergey Malenkov wrote:
I'm not sure. It can be a "false" scrolling when you accidentally
touched a Magic Mouse.
I think we should use threshold on the phase end, to ignore
accumulatedDelta less than 0.1
Could you review the upda
The jconsole change looks fine. I’m including serviceability-dev and bcc
core-libs-dev as serviceability-dev is the right mailing list for jconsole
change.
Mandy
> On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov
> wrote:
>
> Hello.
>
> Please review the fix for jdk9.
>
> This is request to d
>> I'm not sure. It can be a "false" scrolling when you accidentally
>> touched a Magic Mouse.
>
> The same "false" can occur at the "end" stage, also?
Yes, but at the "end" we can use a threshold. See below:
>> I think we should use threshold on the phase end, to ignore
>> accumulatedDelta less
On 30/09/16 19:43, Sergey Malenkov wrote:
+ (jint) scrollStateWithEvent: (NSEvent*) event {
scrollPhaseFromEvent sounds more clear for me
if ([event type] != NSScrollWheel) {
return 0;
}
We have no corresponding SCROLL_PHASE_ constant.
This value is not processed and is proc
On 30.09.16 18:33, Sergey Malenkov wrote:
I'm not sure. It can be a "false" scrolling when you accidentally
touched a Magic Mouse.
The same "false" can occur at the "end" stage, also?
I think we should use threshold on the phase end, to ignore
accumulatedDelta less than 0.1
On Fri, Sep 30,
On 30/09/16 19:33, Sergey Malenkov wrote:
I'm not sure. It can be a "false" scrolling when you accidentally
touched a Magic Mouse.
I think we should use threshold on the phase end, to ignore
accumulatedDelta less than 0.1
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8
final int roundDelta = isShift && roundDeltaY != 0.0 ? roundDeltaY :
roundDeltaX;
roundDeltaY is integer and should be compared with 0
On Fri, Sep 30, 2016 at 6:43 PM, Sergey Malenkov wrote:
> + (jint) scrollStateWithEvent: (NSEvent*) event {
>
> scrollPhaseFromEvent sounds more clear for me
>
>
Hello.
Please review the fix for jdk9.
This is request to deprecate the obsolete flags inside InputEvent. This
constants were marked as obsolete in jdk1.4 and were replaced by the new
one. In jdk1.4 the documentation were update with notion that the new
constants should be used. And this bug
+ (jint) scrollStateWithEvent: (NSEvent*) event {
scrollPhaseFromEvent sounds more clear for me
if ([event type] != NSScrollWheel) {
return 0;
}
We have no corresponding SCROLL_PHASE_ constant.
This value is not processed and is processed like S_P_CONTINUED in our code.
On F
I'm not sure. It can be a "false" scrolling when you accidentally
touched a Magic Mouse.
I think we should use threshold on the phase end, to ignore
accumulatedDelta less than 0.1
On Fri, Sep 30, 2016 at 6:18 PM, Sergey Bylokhov
wrote:
> What will be the difference if we will scroll by one line
What will be the difference if we will scroll by one line at the "begin
phase"? probably it will be better if the the scroll will start
immediately on first touch?
On 30.09.16 17:59, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/81
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
- The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
a scroll event when delta or round delta is not equal to zero
- The native scrollStateWithPhase: method is updated to have NS
On 29.09.16 18:33, Semyon Sadetsky wrote:
Looks fine. Please file separate issue that syncNativeQueue() should
check that dnd callbacks are started/completed, because
"(newEventNumber - eventNumber) > 2" check is useless if we are in the
DND. And if some callbacks are in progress syncNativeQueue(
The fix looks good.
Do you know why JDialog maximize button doesn't work? When I click on it
the maximize button the dialog disappears.
--Semyon
On 9/6/2016 5:32 PM, Alexander Zvegintsev wrote:
Hello,
please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
for the is
In the CPlatformResponder:
phase3 0 ~ 0.0 // mayBegan
phase2 0 ~ 0.0 // began
phase3 0 ~ 0.0222015380859375
phase3 0 ~ 0.0234222412109375
phase3 0 ~ 0.023956298828125
phase3 0 ~ 0.0242919921875
phase3 0 ~ 0.02447509765625
phase3 0 ~ 0.0246124267578125
phase3 0 ~ 0.024658203125
phase3 0 ~ 0.0222015
Looks fine.
On 30.09.16 14:38, Ajit Ghaisas wrote:
Looking at the issue(JDK-6401700) where this test was introduced, it is clear
that this test should run on linux and solaris.
I have updated the test with appropriate @requires tag.
http://cr.openjdk.java.net/~aghaisas/8058950/webrev.01/
Reque
Looking at the issue(JDK-6401700) where this test was introduced, it is clear
that this test should run on linux and solaris.
I have updated the test with appropriate @requires tag.
http://cr.openjdk.java.net/~aghaisas/8058950/webrev.01/
Request you to review.
Regards,
Ajit
-Original Messa
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
The momentumPhase is used to detect the trackpad events.
Thanks,
Alexandr.
On 30/09/16 14:58, Sergey Malenkov wrote:
# C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
The app is c
> # C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
>
> The app is crashed as soon as I start scrolling. Investigating...
> May be it is my fault during backporting.
Sorry, It was may fault.
> LWCToolkit.m:
> +// SCROLL EVENT MASK
> +#define SCROLL_PHASE_UNSUPPORTED 1
> ...
>
> re
On 9/30/2016 1:31 PM, Sergey Malenkov wrote:
# C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
The app is crashed as soon as I start scrolling. Investigating...
May be it is my fault during backporting.
Sorry, it was my fault. Now it works.
Consider how it works for one short
> # C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
>
> The app is crashed as soon as I start scrolling. Investigating...
> May be it is my fault during backporting.
Sorry, it was my fault. Now it works.
Consider how it works for one short gesture:
phase3 0 ~ 0.0 // unexpected PHA
# C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
The app is crashed as soon as I start scrolling. Investigating...
May be it is my fault during backporting.
LWCToolkit.m:
+// SCROLL EVENT MASK
+#define SCROLL_PHASE_UNSUPPORTED 1
...
replace the comment with the following one:
26 matches
Mail list logo
