from:"Alexander Zvegintsev"

On Fri, 23 Jul 2021 12:56:32 GMT, Alexander Zvegintsev  
wrote:

>> This test can fail pretty consistently on some slow systems. Increased delay 
>> fixes the issue. 
>> We do have similar fix in #260
>
> Alexander Zvegintsev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   finally dispose

CI job run is green.

-

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v4]

> This test can fail pretty consistently on some slow systems. Increased delay 
> fixes the issue. 
> We do have similar fix in #260

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  finally dispose

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/cbe6f219..df2a2aa3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=272=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=272=02-03

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/272/head:pull/272

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v3]

On Fri, 23 Jul 2021 11:53:48 GMT, Prasanta Sadhukhan  
wrote:

> Looks good. BTW, normally in swing we also do dispose of the frame after test 
> is over in finally block...Not sure in awt Frame...It may not be required if 
> you are running standalone but in a group of CI run, it might prove 
> effective..

looks like jtreg handles this, but this might be helpful specially for 
standalone run.

-

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v3]

> This test can fail pretty consistently on some slow systems. Increased delay 
> fixes the issue. 
> We do have similar fix in #260

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  increased delay

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/10ca677e..cbe6f219

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=272=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=272=01-02

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/272/head:pull/272

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

2021-07-22 Thread Alexander Zvegintsev

On Thu, 22 Jul 2021 20:20:48 GMT, Alexander Zuev  wrote:

> I am not sure if we supposed to bump up the copyright year or it is supposed 
> to be done with some script later, but i usually do it myself just to be sure.

updated

-

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: [jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu [v2]

2021-07-22 Thread Alexander Zvegintsev

> This test can fail pretty consistently on some slow systems. Increased delay 
> fixes the issue. 
> We do have similar fix in #260

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  year bump

-

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/272/files
  - new: https://git.openjdk.java.net/jdk17/pull/272/files/d64dd52d..10ca677e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17=272=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=272=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/272/head:pull/272

PR: https://git.openjdk.java.net/jdk17/pull/272

[jdk17] RFR: 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu

2021-07-22 Thread Alexander Zvegintsev

This test can fail pretty consistently on some slow systems. Increased delay 
fixes the issue. 
We do have similar fix in #260

-

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk17/pull/272/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=272=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8015886
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/272/head:pull/272

PR: https://git.openjdk.java.net/jdk17/pull/272

Re: Call for Discussion : New Project to support the Wayland display server on Linux

2021-07-07 Thread Alexander Zvegintsev

(adding awt-dev)

Let me add a few comments.

already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
sure others too.
It is the default, but not in every case. Wayland may be turned off
deliberately if you are using a Nvidia graphics card, so you need to
take extra steps to get it working
.

I faced this issue on Ubuntu 21.04.

However things getting better
with
Nvidia 470 drivers, its beta released
on
2021.6.22. So probably it won't be a problem in the near future.

Consequently we expect quite shortly to propose an OpenJDK project
that will consider the goals of
- a short to medium term solution for JDK running on Wayland in X11
compatibility mode
- a medium to long term solution for JDK running as a native Wayland
client.

Both goals having a common task: we will need to implement
java.awt.Robot functionality for Wayland(at least).

So it makes sense to make XToolkit's java.awt.Robot work under Wayland
first, and then reuse this code for native Wayland client.

I see two major tasks here: taking screenshots and mouse/keyboard
control. As far as I know there is no standard way to implement they
across all display servers yet.

Possible ways to implement this:

* taking screenshot:
o open issue against Wayland, may be resolved
someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32

o
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot

o via DBUS interface(display server dependent),

e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43

* generating key/mouse events:
o
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop

o generating new virtual input device, uinput, superuser
privileges required, looks too flaky

https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse

This still need more investigation, butxdg-desktop-portal
looks more preferable way
for now.

Please see below some caveats for OpenJDK native Wayland client:

You can't control a position for a top-level window.

This will also affect a splashscreen windows. It is still possible to
control position under XWayland though.

Looks like we will just accept it.

Top-level window decorations.

Initially Wayland had only client-side decorations(you have to draw it
by yourself).

As of now server-side decorations are available by XDG-Decoration
protocol .

However server-side window decorations are not mandatory and not all
compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).

Gnome Shell is the default on Ubuntu, so we will need to provide window
decorations somehow. One of possible solutions is to use Gtk to create a
window for us.

--
Thanks,
Alexander.

On 7/7/21 6:24 AM, Philip Race wrote:

For a number of years the Linux community has been working on a
complete replacement for the 1980's era X11 desktop display server
protocol
with new protocols and libraries that support client-side rendering
and a compositing desktop windowing system.
This work is being done under the auspices of the Wayland project [1]
and there is a reference

implementation of a Wayland compositor called "Weston".

A new client written for the Wayland desktop has no dependency at all
on X11, but Wayland also provides a compatibility
mode where the X.org X11 server runs along side Wayland, so that
thousands of X11 applications can continue to run.

Presently all distros that ship the Wayland server, also still ship
the pure X11 server and the user can select
which one to use on the login screen. However there will come a time
when Wayland is the only choice and
already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am
sure others too.

At that time Java for Linux will "mostly" run via the X11
compatibility layer, but would not pass the JCK,
since some important APIs, notably

Integrated: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

2021-06-26 Thread Alexander Zvegintsev

On Mon, 29 Mar 2021 18:57:55 GMT, Alexander Zvegintsev  
wrote:

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

This pull request has now been integrated.

Changeset: 51a1299b
Author:Alexander Zvegintsev 
URL:   
https://git.openjdk.java.net/jdk/commit/51a1299b68fb3a2e58de20209745c89f1d5f9ed3
Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8264125: Specification of Taskbar::getIconImage doesn't mention that the 
returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac 
OS)

Reviewed-by: kizune, prr

-

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]

On Thu, 17 Jun 2021 20:31:07 GMT, Phil Race  wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   header fix
>
> src/java.desktop/share/classes/java/awt/Taskbar.java line 341:
> 
>> 339: /**
>> 340:  * Obtains an image of this application's icon.
>> 341:  * 
> 
> As discussed off-line, preface this with "@apiNote"

updated

-

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v5]

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  @apiNote added, Suggests -> Requests

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/312abff4..4e5273e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  header fix

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/b5432e78..312abff4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v3]

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  update

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/a265fc99..b5432e78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8268620: InfiniteLoopException test may fail on x86 platforms

2021-06-15 Thread Alexander Zvegintsev

On Mon, 14 Jun 2021 17:18:15 GMT, Sergey Bylokhov  wrote:

> Small test update.
> 
> This test posts lots of events to EDT from the different threads, and it 
> checks that the robot.waitForIdle() on the main thread will not hang or throw 
> an exception. And this test fails on x86. The post of events are implemented 
> via wait/notifyAll, and the robot.waitForIdle() is also implemented via 
> wait/notifyAll on the same monitor, and on x86 platform, the wait() in the 
> robot.waitForIdle() is never interrupted/notified by the notifyAll(), and it 
> hangs forever.
> 
> I do not think this bug is specific to the x86(I tested 8u), it is just 
> accidentally working fine on the mainline.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4488

Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode!

2021-06-07 Thread Alexander Zvegintsev

On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race  wrote:

> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote 
> VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current 
> mode.
> A program that simply enumerates the reported modes and tries to set them, if 
> it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as 
> now being illegal.
> It does not appear to be as simple as a user's permission level since it 
> occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared 
> desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested 
> display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is 
> allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test 
> so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the 
> built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be 
> discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if 
> the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or 
> not.
> 
> Since we've had code since at least 2013 that added the default mode I 
> suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no 
> longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches 
> the original display mode in order to restore it, it presents a bigger 
> problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the 
> initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m line 266:

> 264: /*
> 265:  * Class: sun_awt_CGraphicsDevice
> 266:  * Method:nativeSetDisplayMode

`nativeResetDisplayMode`?

-

PR: https://git.openjdk.java.net/jdk/pull/4373

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title [v2]

2021-06-04 Thread Alexander Zvegintsev

On Fri, 4 Jun 2021 08:44:22 GMT, Maxim Kartashev 
 wrote:

>> This commit introduces a new client property xawt.mwm_decor_title 
>> implementing JDK-8267307. The property can be set prior to showing a window 
>> or after the window has been displayed, in which case the window will have 
>> to be hidden/shown (re-mapped) for the property to take effect.
>> 
>> The general idea is to provide control over the "decorations" part of the 
>> X11 window property called _MOTIF_WM_HINTS. Those "decoration" bits are set 
>> to 1 (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
>> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
>> decorate with anything, even borders or resize handles. With 
>> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
>> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
>> take as "decorate with only a border", thus effectively removing the 
>> window's title bar, but still leaving the resize capability.
>> 
>> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
>> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
>> where it did not have any effect; these two WMs have limited respected for 
>> the "decorations" bits of the _MOTIF_WM_HINTS window property.
>
> Maxim Kartashev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Changed the check for the XFramePeer target being 
> javax.swing.RootPaneContainer in
>   order to avoid unnecessary class loading if it isn't.
>   
>   Also updated the test such that robot.createScreenCapture() is not
>   executed on EDT.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4113

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Alexander Zvegintsev

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev 
 wrote:

> This commit introduces a new client property xawt.mwm_decor_title 
> implementing JDK-8267307. The property can be set prior to showing a window 
> or after the window has been displayed, in which case the window will have to 
> be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 
> window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 
> (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
> decorate with anything, even borders or resize handles. With 
> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
> take as "decorate with only a border", thus effectively removing the window's 
> title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
> where it did not have any effect; these two WMs have limited respected for 
> the "decorations" bits of the _MOTIF_WM_HINTS window property.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4113

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Alexander Zvegintsev

On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev 
 wrote:

> This commit introduces a new client property xawt.mwm_decor_title 
> implementing JDK-8267307. The property can be set prior to showing a window 
> or after the window has been displayed, in which case the window will have to 
> be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 
> window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 
> (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
> decorate with anything, even borders or resize handles. With 
> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
> take as "decorate with only a border", thus effectively removing the window's 
> title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
> where it did not have any effect; these two WMs have limited respected for 
> the "decorations" bits of the _MOTIF_WM_HINTS window property.

This fix most likely will require a CSR

test/jdk/java/awt/Window/WindowTitleVisibleTest/WindowTitleVisibleTestLinuxGnome.java
 line 111:

> 109: private void captureTitleBarNotVisible() {
> 110: runSwing( () -> {
> 111: titleBarImageNotVisible = 
> robot.createScreenCapture(titleBarBounds);

`createScreenCapture` does not require to be called on EDT.

-

PR: https://git.openjdk.java.net/jdk/pull/4113

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v2]

2021-05-27 Thread Alexander Zvegintsev

On Wed, 26 May 2021 17:51:55 GMT, Alexander Zvegintsev  
wrote:

>> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
>> object different from passed to `Taskbar::setIconImage`.
>> 
>> Actually it is always returns a different object on macOS(the only OS which 
>> supports this feature), but I want to save some options if we decide to 
>> rework this.
>
> Alexander Zvegintsev has updated the pull request with a new target base due 
> to a merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains three additional 
> commits since the last revision:
> 
>  - update
>  - Merge branch 'openjdk:master' into Taskbar_getIconImageSpec_8264125
>  - initial

@mrserb @dbessono please review

-

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v2]

2021-05-26 Thread Alexander Zvegintsev

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

Alexander Zvegintsev has updated the pull request with a new target base due to 
a merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains three additional 
commits since the last revision:

 - update
 - Merge branch 'openjdk:master' into Taskbar_getIconImageSpec_8264125
 - initial

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3250/files
  - new: https://git.openjdk.java.net/jdk/pull/3250/files/74bccd43..a265fc99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=00-01

  Stats: 695093 lines in 8625 files changed: 120831 ins; 548167 del; 26095 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8266949: Check possibility to disable OperationTimedOut on Unix [v2]

2021-05-18 Thread Alexander Zvegintsev

On Sun, 16 May 2021 01:29:59 GMT, Sergey Bylokhov  wrote:

>> Our implementation of realSync on Unix is not straightforward, we try to 
>> move the awt root window and catch the ConfigureNotify. The problem is that 
>> the request to move the awt root window can be ignored, and it is possible 
>> that the notification will not come. In this case, we throw non-specified 
>> OperationTimedOut and it crashes the random tests here and there.
>> 
>> I have applied the same logic as on Windows and Linux we will wait till 
>> timeout(10 seconds) and then exit from the realsync.
>
> Sergey Bylokhov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update SunToolkit.java

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4038

Re: RFR: 8182043: Access to Windows Large Icons [v8]

2021-05-17 Thread Alexander Zvegintsev

On Mon, 17 May 2021 05:13:06 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Example in JavaDoc fixed

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2875

Re: RFR: 8182043: Access to Windows Large Icons [v7]

2021-05-16 Thread Alexander Zvegintsev

On Fri, 14 May 2021 19:46:03 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Slight change of wording in javadoc
>   Fixed Win32ShellFolder2.getSystemIcon scaling issue

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 
271:

> 269: * Example: 
> 270: * FileSystemView fsv = FileSystemView.getFileSystemView();
> 271: * Icon icon = fsv.getSystemIcon("application.exe", 64);

Shouldn't the first parameter be a File instance instead of String?
`Icon icon = fsv.getSystemIcon(new File("application.exe"), 64);`

-

PR: https://git.openjdk.java.net/jdk/pull/2875

Re: RFR: 8047218: [TEST_BUG] java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java fails with exception

2021-05-10 Thread Alexander Zvegintsev

On Mon, 10 May 2021 21:38:37 GMT, Sergey Bylokhov  wrote:

> An exception occurs when the main thread disposes of the frame while the 
> other thread still renders to it. The fix joins the main thread to other 
> threads, so we will dispose of the frame at the end only.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3957

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

2021-05-08 Thread Alexander Zvegintsev

On Fri, 7 May 2021 19:57:02 GMT, Phil Race  wrote:

> Leaving aside specification. what does an app really want this to return ?
> Should we start from there ?

We are returning current dock icon image from system.

> Do we definitely not want to just hang on to whatever an application set so 
> we can return it without modification ?
> What are the problems with that ?

It might be a good solution, but I see some difficulties here.
If we just save passed image instance, its content might be modified by user 
between `setIconImage()` and `getIconImage()` calls.

`setIconImage()` internally converts passed image, so it does not follow its 
changes.
Thus we will get a discrepancy between result from `getIconImage()` and actual 
dock icon image on macOS side.
(Probably we can mitigate this by modifying the javadoc with some vague wording 
though.)

Ideally we should make a copy of an icon passed to `setIconImage()` method to 
prevent modification of its content.
`setIconImage()`/`getIconImage()` works with too wide type `java.awt.Image`, 
and I am not aware of any reliable way to clone every possible subtype of it.

-

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

2021-04-30 Thread Alexander Zvegintsev

On Mon, 29 Mar 2021 18:57:55 GMT, Alexander Zvegintsev  
wrote:

> This fix is to explicitly specify that `Taskbar::getIconImage` may return an 
> object different from passed to `Taskbar::setIconImage`.
> 
> Actually it is always returns a different object on macOS(the only OS which 
> supports this feature), but I want to save some options if we decide to 
> rework this.

CSR added.

-

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264786: [macos] All Swing/AWT apps cause Allow Notifications prompt to appear when app is launched

2021-04-28 Thread Alexander Zvegintsev

On Tue, 27 Apr 2021 01:09:44 GMT, Sergey Bylokhov  wrote:

> The fix for the JDK-8187639 reimplemented the tray icon messages using the 
> standard notification center, it worked fine on macOS 10.9. But on the new 
> macOS, the usage of that API requests permission from the user. Since the 
> code was added to the NSApplicationAWT this request is always shown even if 
> the app does not use tray icons. This fix moves the code to the tray icon 
> itself. I have tested this on macOS 11.2. It will be good if someone can 
> check macOS 10.14 or macOS 10.15.

I've checked it on `10.15.7`.
before the fix - permission request appears immediately.
after the fix - permission request appears after using `TrayIcon`.

-

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3707

Re: RFR: 8197821: Test java/awt/font/TextLayout/LigatureCaretTest.java fails on Windows

2021-04-28 Thread Alexander Zvegintsev

On Wed, 28 Apr 2021 12:46:56 GMT, Prasanta Sadhukhan  
wrote:

> 2 tests java/awt/font/TextLayout/LigatureCaretTest.java and 
> java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java used to 
> fail on windows in CI testing citing "wrong text location" and " right hit 
> failed within layout " which is due to some layout  issue. 
> We have made harfbuzz upgrades after that and these tests are not failing 
> neither locally nor in CI testing.
> 
> Several iterations of these tests in all platforms are working fine, so we 
> can remove from problemlist.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3760

Re: RFR: 8168408: Test java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java fails intermittentently on windows

2021-04-21 Thread Alexander Zvegintsev

On Wed, 21 Apr 2021 11:15:49 GMT, Prasanta Sadhukhan  
wrote:

> This test was seen to be failing in windows and mac PIT run due to samevm 
> mode issue. It is now passing in default othervm mode. 
> Several iterations of this test running in all platforms is working fine, 
> link in JBS.
> We can remove the test from ProblemList, similar to what we have done for 
> JDK-8254976.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3602

Re: RFR: 8198422: Test java/awt/font/StyledMetrics/BoldSpace.java is unstable

2021-04-21 Thread Alexander Zvegintsev

On Wed, 21 Apr 2021 11:08:40 GMT, Prasanta Sadhukhan  
wrote:

> This test was marked as unstable in CI run due to samevm mode issue. It is 
> now passing in default othervm mode.
> Several iterations of this test running in all platforms is working fine, 
> link in JBS.
> We can remove the test from ProblemList.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3601

Integrated: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

2021-04-13 Thread Alexander Zvegintsev

On Mon, 12 Apr 2021 18:48:06 GMT, Alexander Zvegintsev  
wrote:

> This fix simply removes tests mentioned in the bug with for unsupported 
> scenarios(applets in browser).

This pull request has now been integrated.

Changeset: 26186ec3
Author:Alexander Zvegintsev 
URL:   https://git.openjdk.java.net/jdk/commit/26186ec3
Stats: 592 lines in 9 files changed: 0 ins; 592 del; 0 mod

8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences 
and the TestApplet.html is blocked.

Reviewed-by: serb, pbansal, aivanov, kizune

-

PR: https://git.openjdk.java.net/jdk/pull/3441

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]

On Tue, 13 Apr 2021 01:03:49 GMT, Sergey Bylokhov  wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   TestApplet.java removed
>
> test/jdk/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java
>  line 1:
> 
>> 1: /*
> 
> The "TestApplet.java" near this file is part of the test and can be removed 
> as well.

Fixed.

-

PR: https://git.openjdk.java.net/jdk/pull/3441

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]

> This fix simply removes tests mentioned in the bug with for unsupported 
> scenarios(applets in browser).

Alexander Zvegintsev has updated the pull request incrementally with one 
additional commit since the last revision:

  TestApplet.java removed

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3441/files
  - new: https://git.openjdk.java.net/jdk/pull/3441/files/8f39e2f8..133f0806

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3441=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3441=00-01

  Stats: 67 lines in 1 file changed: 0 ins; 67 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3441.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3441/head:pull/3441

PR: https://git.openjdk.java.net/jdk/pull/3441

Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

On Mon, 12 Apr 2021 20:23:39 GMT, Sergey Bylokhov  wrote:

> Please confirm that none of them are in the problem list.

I do confirm that.

-

PR: https://git.openjdk.java.net/jdk/pull/3441

RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.

This fix simply removes tests mentioned in the bug with for unsupported 
scenarios(applets in browser).

-

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/3441/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3441=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8039261
  Stats: 525 lines in 8 files changed: 0 ins; 525 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3441.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3441/head:pull/3441

PR: https://git.openjdk.java.net/jdk/pull/3441

Re: RFR: 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos

On Mon, 12 Apr 2021 04:37:31 GMT, Prasanta Sadhukhan  
wrote:

> This test was problemlisted during nightly testing of jdk on macos which 
> seems to be caused by the fact that proper waiting was not done to make sure 
> frame is visible before commencing the test, which can be problematic in some 
> of the slower CI macos system.
> Modified the wait-till-frame-is-visible code to make it more in sync with 
> what other similar test use.
> Several iterations of the test works fine in all platforms after this 
> modification.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3430

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4]

2021-04-08 Thread Alexander Zvegintsev

On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov 
 wrote:

>> There are few possible cleanups in java.desktop related to legacy 
>> StringBuffer usages:
>> 1. In few places StringBuffer can be replaced with plain String 
>> concatenation.
>> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better 
>> performance as it is not thread-safe.
>> 3. There are few places where result of string concatenation is passed to 
>> StringBuffer.append method. Using separate `.append` calls is more clear.
>> 4. In few places primitives are unnecessary converted to String before 
>> `.append` call. They can be replaced with specialized methods (like 
>> `.append(int)` calls.
>
> Andrey Turbanov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8264484: Replace uses of StringBuffer with StringBuilder in 
> jdk.hotspot.agent
>   
>   place each 'append' call on its own line

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3251

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]

2021-04-07 Thread Alexander Zvegintsev

On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov 
 wrote:

>> There are few possible cleanups in java.desktop related to legacy 
>> StringBuffer usages:
>> 1. In few places StringBuffer can be replaced with plain String 
>> concatenation.
>> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better 
>> performance as it is not thread-safe.
>> 3. There are few places where result of string concatenation is passed to 
>> StringBuffer.append method. Using separate `.append` calls is more clear.
>> 4. In few places primitives are unnecessary converted to String before 
>> `.append` call. They can be replaced with specialized methods (like 
>> `.append(int)` calls.
>
> Andrey Turbanov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>   
>   fix copyright year

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3251

Re: RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v2]

2021-04-06 Thread Alexander Zvegintsev

On Tue, 30 Mar 2021 19:05:37 GMT, Andrey Turbanov 
 wrote:

>> There are few possible cleanups in java.desktop related to legacy 
>> StringBuffer usages:
>> 1. In few places StringBuffer can be replaced with plain String 
>> concatenation.
>> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better 
>> performance as it is not thread-safe.
>> 3. There are few places where result of string concatenation is passed to 
>> StringBuffer.append method. Using separate `.append` calls is more clear.
>> 4. In few places primitives are unnecessary converted to String before 
>> `.append` call. They can be replaced with specialized methods (like 
>> `.append(int)` calls.
>
> Andrey Turbanov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop

src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139:

> 137: @Override
> 138: public String toString() {
> 139: StringBuilder buf = new StringBuilder(super.toString());

Looks like this is the only file where copyright year is not updated.

-

PR: https://git.openjdk.java.net/jdk/pull/3251

Re: RFR: 8264680: Use the blessed modifier order in java.desktop [v2]

2021-04-06 Thread Alexander Zvegintsev

On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt 
 wrote:

>> 8264680: Use the blessed modifier order in java.desktop
>
> Alex Blewitt has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Additionally remove detritus from PNGImageDecoder.java

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights 
> reserved.

Copyright year in other files might be updated as well.

-

PR: https://git.openjdk.java.net/jdk/pull/3337

RFR: JDK-8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS)

2021-03-29 Thread Alexander Zvegintsev

JDK-8264125: Specification of Taskbar::getIconImage doesn't mention that the 
returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac 
OS)

-

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/3250/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3250=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264125
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250

PR: https://git.openjdk.java.net/jdk/pull/3250

Re: RFR: 8264344: Outdated links in JavaComponentAccessibility.m

2021-03-29 Thread Alexander Zvegintsev

On Mon, 29 Mar 2021 08:31:48 GMT, Alexander Zuev  wrote:

> 8264344: Outdated links in JavaComponentAccessibility.m

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3240

Re: RFR: 8260619: Add final modifier to several DataFlavor static fields

2021-03-23 Thread Alexander Zvegintsev

On Mon, 22 Mar 2021 22:03:15 GMT, Sergey Bylokhov  wrote:

> This request proposes changing the state of a few static constants in the 
> DataFlavor class.
> 
> The fields selectionHtmlFlavor/fragmentHtmlFlavor/allHtmlFlavor added to the 
> java.awt.datatransfer.DataFlavor class in JDK8 were not marked as final as 
> are other similar constants in this class.
> 
> See more information in CSR: https://bugs.openjdk.java.net/browse/JDK-8260620

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/3134

Re: RFR: 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X

2021-03-19 Thread Alexander Zvegintsev

On Fri, 19 Mar 2021 23:10:46 GMT, Alexander Zuev  wrote:

> 8263846: Bad JNI lookup getFocusOwner in accessibility code on Mac OS X

Since there is no test, I assume that the JBS issue should have `noreg-hard` 
label.

-

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3099

Integrated: 8194129: Regression automated Test '/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java' fails

2021-03-12 Thread Alexander Zvegintsev

On Fri, 12 Mar 2021 00:25:39 GMT, Alexander Zvegintsev  
wrote:

> First steps of the test are:
> 
> - display undecorated background window
> - click on it
> - check if the window has received that click
> - ... continue with test ...
> 
> Unfortunately on Linux the test makes click before the window is shown.
> 
> Testing is green in over 100 runs.

This pull request has now been integrated.

Changeset: 0ea48d9d
Author:Alexander Zvegintsev 
URL:   https://git.openjdk.java.net/jdk/commit/0ea48d9d
Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod

8194129: Regression automated Test 
'/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java'
 fails

Reviewed-by: serb, psadhukhan

-

PR: https://git.openjdk.java.net/jdk/pull/2953

RFR: 8194129: Regression automated Test '/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java' fails

2021-03-11 Thread Alexander Zvegintsev

First steps of the test are:

- display undecorated background window
- click on it
- check if the window has received that click
- ... continue with test ...

Unfortunately on Linux the test makes click before the window is shown.

-

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/2953/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2953=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8194129
  Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2953.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2953/head:pull/2953

PR: https://git.openjdk.java.net/jdk/pull/2953

Integrated: 8250804: Can't set the application icon image for Unity WM on Linux.

2021-03-06 Thread Alexander Zvegintsev

On Fri, 5 Mar 2021 00:55:04 GMT, Alexander Zvegintsev  
wrote:

> As of now we can have two icons: on the side dock and on the top bar.
> But this test was written for an old time Unity with an icon in the side dock 
> only. 
> 
> Icon at the top by default is displayed as grayscale(the actual reason of 
> submitting bug report).
> BTW it may not be presented depending on Gnome Shell settings.
> 
> `setIconImage()` seems to be working as expected in this case, but we need to 
> clarify the test's instruction.
> 
> Besides that the test has another issue: it does not fail on pressing "Fail" 
> button. It is also fixed.

This pull request has now been integrated.

Changeset: 2afbd5da
Author:Alexander Zvegintsev 
URL:   https://git.openjdk.java.net/jdk/commit/2afbd5da
Stats: 22 lines in 2 files changed: 9 ins; 5 del; 8 mod

8250804: Can't set the application icon image for Unity WM on Linux.

Reviewed-by: serb, pbansal, kizune

-

PR: https://git.openjdk.java.net/jdk/pull/2838

Re: RFR: 8250804: Can't set the application icon image for Unity WM on Linux.

2021-03-05 Thread Alexander Zvegintsev

On Fri, 5 Mar 2021 01:18:26 GMT, Sergey Bylokhov  wrote:

>> test/jdk/ProblemList.txt line 855:
>> 
>>> 853: 
>>> java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java 
>>> 8162380 generic-all
>>> 854: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java 
>>> 8163086 macosx-all
>>> 855: java/awt/image/multiresolution/MultiResolutionIcon/IconTest.java 
>>> 8250804 macosx-all,linux-all
>> 
>> Does this test work fine on the macOS? Looks like it was reported here:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8250804?focusedCommentId=14379402=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14379402
>
> O, I see that you made it Linux only.

Yes, it does not work on macOS.
For changing dock icon on macOS you should use `java.awt.Taskbar#setIconImage` 
or assign it with application bundle.

-

PR: https://git.openjdk.java.net/jdk/pull/2838

RFR: 8250804: Can't set the application icon image for Unity WM on Linux.

2021-03-04 Thread Alexander Zvegintsev

As of now we can have two icons: on the side dock and on the top bar.
But this test was written for an old time Unity with an icon in the side dock 
only. 

Icon at the top by default is displayed as grayscale(the actual reason of 
submitting bug report).
BTW it may not be presented depending on Gnome Shell settings.

`setIconImage()` seems to be working as expected in this case, but we need to 
clarify the test's instruction.

Besides that the test has another issue: it does not fail on pressing "Fail" 
button. It is also fixed.

-

Commit messages:
 - ProblemList
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/2838/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2838=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250804
  Stats: 22 lines in 2 files changed: 9 ins; 5 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2838.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2838/head:pull/2838

PR: https://git.openjdk.java.net/jdk/pull/2838

Re: RFR: JDK-8262461: handle wcstombsdmp return value correctly in unix awt_InputMethod.c

2021-02-26 Thread Alexander Zvegintsev

On Fri, 26 Feb 2021 14:19:03 GMT, Matthias Baesken  wrote:

> The function wcstombsdmp is called at a few places in awt_InputMethod.c.
> This function needs checking of a NULL return value and freeing of the memory 
> allocated by this function. However this is missing at one place in the file.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2747

Re: RFR: JDK-8262420: typo: @implnote in java.desktop module

2021-02-25 Thread Alexander Zvegintsev

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons  wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by 
> doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following 
> paragraph, (beginning _See the ..._) which was originally part of the main 
> description, and does not appear that it should be part of the implementation 
> note.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2735

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-11-07 Thread Alexander Zvegintsev


HI Semyon,

Please see my answer to Dmitry


Hi Dmitry,

 From my understanding JavaFX stage can't be easily integrated in JDK to 
support orderWindow() approach,

addChildWindow() is a native(and the simplest) way to maintain one window above 
other one, should be called only once.

IIUC the main concert of JDK-8080729 that child windows jumping to parent's 
display upon focus receiving, this is not an issue with current fix,

because addChildWindow() will be called only upon dialog creation in case of 
JavaFX-Swing interop.

Jump may happen if user want to create a child swing dialog on display other 
than JavaFX stage's one,

but such rare scenario can be easily workarounded on a user side by calling 
setLocation() right after setVisible() call.

So I would prefer to use addChildWindow() to make this fix as simple as 
possible.


Thanks,
Alexander.

On 08/11/2017 02:45, Semyon Sadetsky wrote:


Hi Alexander,

In CPlatformWindow.java change you used addChildWindow(), but we get 
rig of addChildWindow() in 8080729 and start to manage windows order 
on java side. Can you test that this change doesn't cause any ordering 
issues with modal and non-modal child and sibling windows on mac?


--Semyon

On 11/07/2017 10:11 AM, Alexander Zvegintsev wrote:


Hi Sergey,

I am not able to crash it on several platforms, except one case:

if we are terminating JavaFX application while EDT processing some 
long task. But it is unrelated to the fix and reproducible on current 
builds.


I've filed a separate bug JDK-8190329 
<https://bugs.openjdk.java.net/browse/JDK-8190329>.


Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows? 
It will not, Windows already fixed by JDK-8088395 
<https://bugs.openjdk.java.net/browse/JDK-8088395>



Test added:
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/
Thanks,
Alexander.
On 13/10/2017 01:14, Sergey Bylokhov wrote:

Looks fine.
I am not sure but it looks like the fix has an assumption that the 
CPlatformWindow.setVisible() code will be executed on EDT/Appkit but 
it is not the case. This code can be executed on any 
thread(intentionally for crash), and it will be good to check that 
it works as expected by some stress test which will try to force the 
possible crash: 4 threads:

 - show/dispose Swing Node
 - show/dispose Dialog1/2/3 using different timeouts

Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows?


On 10/10/2017 13:54, Kevin Rushforth wrote:

Note that there is now a 04 version.

It looks good to me, although someone more familiar with AWT should 
also check the AWT changes.


We will need a test program for this (as a follow-on issue if not 
now).


-- Kevin


Alexander Zvegintsev wrote:

Please review the updated version

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only after 
we ensure that native window pointer is valid on Swing side.


Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed 
while we use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
<<<<< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
<<<<< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK 
counterpart of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev 
should be included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the 
bug below is confidential.



I agree with what Kevin pointed out off-line that as in the 
dialog case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-11-07 Thread Alexander Zvegintsev


Hi Sergey,

I am not able to crash it on several platforms, except one case:

if we are terminating JavaFX application while EDT processing some long 
task. But it is unrelated to the fix and reproducible on current builds.


I've filed a separate bug JDK-8190329 
<https://bugs.openjdk.java.net/browse/JDK-8190329>.


Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows? 
It will not, Windows already fixed by JDK-8088395 
<https://bugs.openjdk.java.net/browse/JDK-8088395>



Test added:
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/

Thanks,
Alexander.

On 13/10/2017 01:14, Sergey Bylokhov wrote:

Looks fine.
I am not sure but it looks like the fix has an assumption that the 
CPlatformWindow.setVisible() code will be executed on EDT/Appkit but 
it is not the case. This code can be executed on any 
thread(intentionally for crash), and it will be good to check that it 
works as expected by some stress test which will try to force the 
possible crash: 4 threads:

 - show/dispose Swing Node
 - show/dispose Dialog1/2/3 using different timeouts

Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows?


On 10/10/2017 13:54, Kevin Rushforth wrote:

Note that there is now a 04 version.

It looks good to me, although someone more familiar with AWT should 
also check the AWT changes.


We will need a test program for this (as a follow-on issue if not now).

-- Kevin


Alexander Zvegintsev wrote:

Please review the updated version

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only after 
we ensure that native window pointer is valid on Swing side.


Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while 
we use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
<<<<< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
<<<<< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK 
counterpart of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should 
be included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the 
dialog case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

2017-10-31 Thread Alexander Zvegintsev


Hi Semyon,

the fix looks good to me,  but the test link is broken in this webrev.

Thanks,
Alexander.

On 30/10/2017 20:37, Semyon Sadetsky wrote:


Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8190230

webrev: http://cr.openjdk.java.net/~ssadetsky/8190230/webrev.00/

After the 8169589 fix siblings of the same parent are overlapped in 
the order they appear in  the array of child windows. But this order 
do not preserve the previous overlapping order in which the sibling 
windows have been shown before the order update. That is the cause of 
unexpected reorder.


In the fix each platform window is attributed with a timestamp of the 
moment when it was show in front last time. Then this timestamp is 
used to sort the sibling windows array before putting them into an 
order to each other.


--Semyon

Re: [10] Review request for JDK-8163265: [macosx] numpad 0 instead of VK_0

2017-10-17 Thread Alexander Zvegintsev


+1

Thanks,
Alexander.

On 17/10/2017 03:12, Sergey Bylokhov wrote:

Looks fine.
Please update the @bugid in the test before the push.

On 16/10/2017 06:38, Manajit Halder wrote:

Hi All,

Kindly review the fix for JDK10.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8163265

Webrev:
http://cr.openjdk.java.net/~mhalder/8163265/webrev.00/

Issue:
Wrong event code received for numbers 0 to 9 in case if any of the 
arrow keys (left, right, up and down) are pressed before pressing any 
of the number keys (0 to 9). Instead of number key event codes, 
NUMPAD number key event are received and the test fails. But if the 
arrow keys are not pressed before pressing the number keys  0 to 9 
then correct key codes are received for the numbers and the test passes.


Cause:
NSNumericPadKeyMask is used in the code to find out whether the 
number key pressed is number or NUMPAD number. But 
NSNumericPadKeyMask is also set if any of the arrow keys are pressed 
(NSUpArrowFunctionKey, NSDownArrowFunctionKey, 
NSLeftArrowFunctionKey, and NSRightArrowFunctionKey).


Fix:
To distinguish between the number and NUMPAD keys the key values are 
also checked because the key values are different for numbers and 
NUMPAD numbers.


Regards,
Manajit

Re: [10] Review request for 8182638: [macosx] Active modal dialog is hidden by another non-active one

2017-10-08 Thread Alexander Zvegintsev


Looks good to me,

BTW in the test DialogListener can be replaced with WindowAdapter

Thanks,
Alexander.

On 07/10/2017 01:17, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK10:

bug: https://bugs.openjdk.java.net/browse/JDK-8182638

webrev: http://cr.openjdk.java.net/~ssadetsky/8182638/webrev.00/

Since 8169589 sibling windows are ordered above the parent. It 
requires for the new active child windows to be raised above  its 
siblings not only above its parent window.


--Semyon

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

2017-10-08 Thread Alexander Zvegintsev


Looks fine

Thanks,
Alexander.

On 27/09/2017 22:37, Sergey Bylokhov wrote:


Hello,
Please review the fix for jdk10.

Bug: https://bugs.openjdk.java.net/browse/JDK-8187639
Webrev can be found at: 
http://cr.openjdk.java.net/~serb/8187639/webrev.01


Since macOS 10.9(or even early) the main menubar is shown on all 
screens(not only on the main screen), which means that on both screens 
the trayIcons are visible.
Our code is not ready for this situation, because we create a custom 
notification window and tries to place it near the trayicon on the 
main screen.


Instead of updating the logic of showing the window, I migrated the 
code to the standard notification mechanism which is used in macOS.


Examples:
The old message: http://cr.openjdk.java.net/~serb/8187639/images/Old.png
The new(java -jar): 
http://cr.openjdk.java.net/~serb/8187639/images/Command%20line.png
The new(bundles application): 
http://cr.openjdk.java.net/~serb/8187639/images/Bundled%20applicateion.png

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-10-08 Thread Alexander Zvegintsev


Please review the updated version

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only after we 
ensure that native window pointer is valid on Swing side.


Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we 
use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
<<<<< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
<<<<< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart 
of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

2017-09-25 Thread Alexander Zvegintsev


+1

Thanks,
Alexander.

On 22/09/2017 06:09, Anton Litvinov wrote:

Hello Sergey,

Thank you very much for review of this fix. The second version of the 
fix with minor changes in 3 places which address your remarks is 
created. The new fix version applied to the today's version of the 
consolidated repository "jdk10/client" was verified in my local 
environment successfully. Could you please look at the new version of 
the fix.


Webrev (the 2nd version): 
http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01


The 2nd version of the fix contains the next changes:
1.  "SunToolkit.java" file - Now "true" is used as the default value 
for the system property "awt.touchKeyboardAutoShowIsEnable".
2.  The 1st version of the fix was not thread-safe, only in case, when 
more than 1 EDT could exist in the process, in 2 places: 
"WToolkit.java" file (access to the fields "compOnTouchDownEvent", 
"compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the 
method "ShowTouchKeyboard()").
    - "WToolkit.java" - The modifier "volatile" was added to the 
fields "compOnTouchDownEvent", "compOnMousePressedEvent".
    - "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
"m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
substituted for the code which outputs into the trace message in case, 
if launching the touch keyboard system application fails.


Could you please answer my question.
- Should CCC request be filed for the new system property 
"awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
"true" by default, if it is not specified by the user explicitly while 
launching a Java application?


Thank you,
Anton

On 05/09/2017 18:15, Sergey Bylokhov wrote:

Hi, Anton.
The fix looks good.
 - But can you please recheck that is is not necessary to use 
additional synchronization in showOrHideTouchKeyboard() if a few EDT 
will be used.
 - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
true as default value, we will have more coverage and feedback in 
this case. This property will be used as a workaround if some bugs 
will be found.


On 8/30/17 11:51, Anton Litvinov wrote:

Hello dear reviewers,

Could anybody please look at this review request?

Thank you,
Anton

On 17/08/2017 13:20, Anton Litvinov wrote:

Hello,

Could you please review the following fix for the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00

The bug is the fact that, when a user touches any Swing or AWT text 
component, for example "JTextField", "JTextArea", "TextField", 
"TextArea", by means of a touch screen on a host with MS Windows 
10/8.1/8 OS, the system touch keyboard is not shown automatically. 
Please find a detailed description of the bug, screenshots 
depicting the touch keyboard and a compilable test case with 
Swing/AWT text components in JBS bug record. Also a summary of the 
done research of the issue with a description of identified 
approaches for its resolution are reported in my last comment in 
the bug record.


THE FIX:
On a very abstract level the fix functioning can be presented by 
the next 3 stages:


Stage 1.
The fix adds support of "WM_TOUCH" system window messages to AWT 
native peer windows through C++ class "AwtComponent". It 
"processes" "WM_TOUCH" message and marks 
"java.awt.event.MouseEvent", which is created as a result of 
handling of the further coming "WM_LBUTTONDOWN", "WM_LBUTTONUP" 
messages sent by the system in substitution for this "WM_TOUCH" 
message, by the new private field flag 
"MouseEvent.causedByTouchEvent".


Stage 2.
Then on Java level the fix handles "MouseEvent", "FocusEvent" 
received only by the instances of "java.awt.TextComponent", 
"javax.swing.text.TextComponent" in 
"WToolkit.showOrHideTouchKeyboard()" called from 
"Component.dispatchEventImpl()" and shows or hides the touch 
keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
events by calling corresponding native methods of "WToolkit" class.


Stage 3.
Showing of the touch keyboard is implemented in C++ class 
"AwtToolkit" and is done by launching the system application 
"TabTip.exe" which implements the system touch keyboard. This 
approach is described in the bug record.


FEATURES OF THE FIX:
1. By default all native and Java parts of the fix do not function 
at all - the fix is disabled. To enable the fix the application 
should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
option. Handling of this new property is implemented in 
"sun.awt.SunToolkit" class.


2. Native parts of the fix functions only on MS Window 8 or later.

3. The fix implements automatic showing of the touch keyboard for 
the following 2 use cases:

    a.  The user touches the text components using the touch screen.
    b.  The user does mouse clicks on the text components, while no 
any keyboard is attached to the host.

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-09-25 Thread Alexander Zvegintsev


Hi Sergey,

Thanks for catching this, this is an issue which should be addressed.

Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we 
use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
<<<<< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
<<<<< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart 
of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-09-21 Thread Alexander Zvegintsev


Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
<https://bugs.openjdk.java.net/browse/JDK-8187803> as JDK counterpart of 
this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug below 
is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless non-functional 
no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review Request: 8186474 WColor class is superseded by the SystemColor and should be removed

2017-08-22 Thread Alexander Zvegintsev


Looks fine

Thanks,
Alexander.

On 19/08/2017 07:34, Sergey Bylokhov wrote:

Hello,
Please review the simple cleanup for jdk10.

Long time ago AWT used WColor class to access the native colors, but since then 
we integrated a public API via SystemColor class.
So WColor class became obsolete and can be removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8186474
Webrev can be found at: http://cr.openjdk.java.net/~serb/8186474/webrev.01

Re: [10] Review request for 8178448: MenuBar item handler fired twice

2017-08-03 Thread Alexander Zvegintsev


Hi Sergey,

http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/01/

I've updated the test.

The JFrame needs to be iconified because it is stealing the keyboard 
focus, so accelerators for menu items will not be triggered.



Thanks,
Alexander.

On 02/08/2017 21:12, Sergey Bylokhov wrote:

Hi, Alex.
Is it possible to create a test for this issue? It will be similar to 
ActionListenerCalledTwiceTest


On 01.08.2017 22:34, Alexander Zvegintsev wrote:

Hi all,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8178448

This Mac specific issue happens if setDefaultMenuBar() is called 
after setJMenuBar() with same instance of JMenuBar.


JFrame.setJMenuBar(mb);
Desktop.getDesktop().setDefaultMenuBar(mb);

--
Thanks,
Alexander.

[10] Review request for 8178448: MenuBar item handler fired twice

2017-08-01 Thread Alexander Zvegintsev


Hi all,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8178448/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8178448

This Mac specific issue happens if setDefaultMenuBar() is called after 
setJMenuBar() with same instance of JMenuBar.


JFrame.setJMenuBar(mb);
Desktop.getDesktop().setDefaultMenuBar(mb);

--
Thanks,
Alexander.

Re: [10] Review request for 8139050 -[AWTView draggingEnded:]: unrecognized selector message during drag and drop

2017-07-27 Thread Alexander Zvegintsev


Looks good to me.

Thanks,
Alexander.

On 21/07/2017 04:02, Sergey Bylokhov wrote:

Hello.
We got a response from the previous maintainer of this code, that it 
was implemented long time ago, and works probably because of a 
different class hierarchy. Currently the code works in this way:


[super respondsToSelector:@selector(draggingEntered:)]
"It goes to the superclass, gets the implementation of 
respondsToSelector: there, and then runs it on the current object, 
which will return YES. But when we call [super draggingEntered] it 
will crash because there are no such methods in NSView".


Since the code does not work I suggest to drop it.

Bug: https://bugs.openjdk.java.net/browse/JDK-8139050
Webrev can be found at: 
http://cr.openjdk.java.net/~serb/8139050/webrev.01


The new test was added(it is modified version of test submitted by the 
users of Swing).


Note that both tests still fails because of another bug:
https://bugs.openjdk.java.net/browse/JDK-8153871
I just reopened it and will start to work on it after this one.

On 10.11.2015 4:53, Alexander Scherbatiy wrote:
The following changes have been contributed during JDK Mac OS X port 
developing:

http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9023fa7e47c9

src/macosx/native/sun/awt/AWTView.m
-
+if (dropTarget != nil)
+dragOp = [dropTarget draggingEntered:sender];
+else if ([super respondsToSelector:@selector(draggingEntered:)])
+dragOp = [super draggingEntered:sender];
-

May be you could know why it was necessary to check dragging* 
selectors in super class when the super class is NSView which does 
not define them.

Re: [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly

2017-06-07 Thread Alexander Zvegintsev

Thanks for clarification, looks good to me.

Thanks,
Alexander.

On 07/06/2017 23:22, Sergey Bylokhov wrote:

Hi, Alexander.
These closing tags are optional in html5 standard [1]. On the link to
the SO there are three the example which work differently but
according standards[2][3][4].

[1] https://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

[2] http://jsfiddle.net/robertc/rNv93/1/
[3] http://jsfiddle.net/UqzEp/2/
[4] http://jsfiddle.net/UqzEp/3/

- alexander.zvegint...@oracle.com wrote:
>

Hi Sergey,
>

Why do we omitting closing th tag?
>

e.g.
>

+ * Metal's system color mapping
+ *
+ *
+ * Key
+ * Value
+ *

I know that HTML parsers are usually forgiving such things. But
sometimes it may make thing worse:

https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378

Thanks,
Alexander.
> On 05/06/2017 06:23, Sergey Bylokhov wrote:
>

If there are no objections I'll change the target ws from dev to client, to
minimize the merges between some other javadoc fixes.

-sergey.bylok...@oracle.com wrote:

Hello.
Here is an updated version where most of the caption are visible.
Bug:https://bugs.openjdk.java.net/browse/JDK-8180326
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8180326/webrev.02/
Specdiff:

http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html

You can use search to check the changes in some specific class:
Old docs:

http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
New docs:
http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html

-jonathan.gibb...@oracle.com wrote:

Phil,

I have no evidence one way or the other whether screen readers pay
attention
to undisplayed or invisible captions. It seemed safest to assume

that

they would
read a visible caption, and that we should head in that general
direction.

-- Jon

On 05/17/2017 11:58 AM, Phil Race wrote:

And PS I was not saying anything to contradict

tables should not have a summary attribute and should have a

caption.

However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all

clear

this

is the point of caption. I'm sure they can read it, but I don't

get

how making
it visible matters to them so how it making it visible relates
to

accessibility
requirements is not an obvious connection to me. So why do we

have

to make it visible for ATs ?

-phil.

On 05/17/2017 11:54 AM, Phil Race wrote:

I will leave the decision on whether to do that now up to
Sergey

although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but
they
seem to have been all fixed.

I'd want to see what the new HTML looks like with a visible

title

course ..

-phil.

On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:

Phil,

The bottom line is that in the JDK docs, tables should
not have

summary attribute and should have a caption. This comes
down to

accessibility requirements, where we are slowly raising
the bar

our docs, to be in accordance with Oracle's guidelines.

Hiding the caption (style="display:none") is an interim
measure

have been using during the HTML 5 updates, especially
in cases

where

the person doing the markup changes did not know enough
to

create

appropriate caption that should be displayed. In time,
we should

locate and update all table captions (in our standard
docs

bundle)

that are not being displayed such that the text is both

appropriate

and visible. If you guys want to do that as part of this

update,

ahead. FWIW, that is what we did for the java.xml
module in the

jaxp

repo ... pretty much all tables there now have a
reasonable,

visible

caption.

Re: [9] Review Request: 8180889 Cleanup of javadoc in java.datatransfer module

2017-06-06 Thread Alexander Zvegintsev

Looks good to me.

Thanks,
Alexander.

On 25/05/2017 06:54, Sergey Bylokhov wrote:

Hi, Phil.
Thank you for a review, the fix is updated:
Webrev can be found at: http://cr.openjdk.java.net/~serb/8180889/webrev.01
Specdiff: 
http://cr.openjdk.java.net/~serb/8180889/specdiff.01/java/awt/datatransfer/package-summary.html

Note that I have updated the text about Oracle's implementation and 
moved it to @implNote tag:

http://cr.openjdk.java.net/~serb/8180889/specdiff.01/java/awt/datatransfer/DataFlavor-report.html#method:getTextPlainUnicodeFlavor()
So I'll file a ccc after the technical review.

- philip.r...@oracle.com wrote:
>
I don't know why it was necessary to update the non-API classes here, 
and I also see some lines reformatted without any actual changes, even 
white space fixes but apart from adding to noise in the change they 
are OK. also this is not strictly doc since you cleaned up (not just 
reordered) some import statements so I added noreg-cleanup to the bug 
labels. A few nits : DataFlavor.java 104 * to Use Drag and Drop and 
Data Transfer, section in

105 * Java Tutorial. in Java Tutorial -> in the Java Tutorial
483 * successfully loaded, then an {@code ClassNotFoundException} is 
an -> a
594 * Sun's implementation for Microsoft Windows uses the encoding 595 
* {@code utf-16le}. 596 * Sun's implementation for Solaris and Linux 
uses the encoding Sun -> Oracle ?? And what about MacOS ?
1249 * @return {@code true} if the {@code DataFlavor} specified 
represents a 1250 * List of File objects 1250 should perhaps be : 
{@code java.util.List} of {@code java.io.File} objects -phil.

> On 05/23/2017 07:19 PM, Sergey Bylokhov wrote:
>

Hello,
Please review the fix for jdk9.

Bug:https://bugs.openjdk.java.net/browse/JDK-8180889
Webrev can be found at:http://cr.openjdk.java.net/~serb/8180889/webrev.00

Specdiff:http://cr.openjdk.java.net/~serb/8180889/specdiff.00/java/awt/datatransfer/package-summary.html

In jdk9 a lots of specifications and javadocs were updated, but it seems 
that java.datatransfer module was missed, because the client team cleanup only 
the java.desktop module.

In this fix the only javadoc is updated and the next rules were applied:
  -  should be replaced by {@tag }
  - @deprecated tag should have some text
  - 80 column limit
  - description of the class/method/field should be followed by dot
  - @param, @return should not end with a dot, except a case when more than 
one sentences are used
  - empty line after description/before the first tag was added
  - unnecessary empty lines were removed
  - sets of spaces in the middle of text were deleted
  - @param, @throws, @return should be aligned, to be more readable
  - unnecessary imports should be removed
  - the "null"/"true"/"false"/"this" should be wrapped in {@code } when 
necessary
  - the order of different tags were unified across the package

The specdiff is provided and the most visible changes are:

http://cr.openjdk.java.net/~serb/8180889/specdiff.00/java/awt/datatransfer/DataFlavor-report.html#method:normalizeMimeTypeParameter(java.lang.String,%20java.lang.String)

http://cr.openjdk.java.net/~serb/8180889/specdiff.00/java/awt/datatransfer/DataFlavor-report.html#method:normalizeMimeType(java.lang.String)
where the text about deprecation was moved to the @deprecated tag.

>

Re: [9] Review Request: 8180326 Update the tables in java.desktop to be HTML-5 friendly

2017-06-06 Thread Alexander Zvegintsev

Hi Sergey,

Why do we omitting closing th tag?

e.g.

+ * Metal's system color mapping
+ *
+ *
+ * Key
+ * Value
+ *

I know that HTML parsers are usually forgiving such things. But
sometimes it may make thing worse:

https://stackoverflow.com/questions/7125354/what-are-the-actual-problems-of-not-closing-tags-and-attributes-in-html/7135378#7135378

Thanks,
Alexander.

On 05/06/2017 06:23, Sergey Bylokhov wrote:

If there are no objections I'll change the target ws from dev to client, to
minimize the merges between some other javadoc fixes.

- sergey.bylok...@oracle.com wrote:

Hello.
Here is an updated version where most of the caption are visible.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8180326/webrev.02/
Specdiff:
http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html

You can use search to check the changes in some specific class:
Old docs:
http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
New docs:
http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html

- jonathan.gibb...@oracle.com wrote:

Phil,

I have no evidence one way or the other whether screen readers pay
attention
to undisplayed or invisible captions. It seemed safest to assume

that

they would
read a visible caption, and that we should head in that general
direction.

-- Jon

On 05/17/2017 11:58 AM, Phil Race wrote:

And PS I was not saying anything to contradict

tables should not have a summary attribute and should have a

caption.

However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all

clear

this

is the point of caption. I'm sure they can read it, but I don't

get

how making
it visible matters to them so how it making it visible relates to
accessibility
requirements is not an obvious connection to me. So why do we

have

to make it visible for ATs ?

-phil.

On 05/17/2017 11:54 AM, Phil Race wrote:

I will leave the decision on whether to do that now up to Sergey
although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but they
seem to have been all fixed.

I'd want to see what the new HTML looks like with a visible

title

course ..

-phil.

On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:

Phil,

The bottom line is that in the JDK docs, tables should not have

summary attribute and should have a caption. This comes down to
accessibility requirements, where we are slowly raising the bar

our docs, to be in accordance with Oracle's guidelines.

Hiding the caption (style="display:none") is an interim measure

have been using during the HTML 5 updates, especially in cases

where

the person doing the markup changes did not know enough to

create

appropriate caption that should be displayed. In time, we should
locate and update all table captions (in our standard docs

bundle)

that are not being displayed such that the text is both

appropriate

and visible. If you guys want to do that as part of this

update,

ahead. FWIW, that is what we did for the java.xml module in the

jaxp

repo ... pretty much all tables there now have a reasonable,

visible

caption.

-- Jon

On 05/17/2017 11:19 AM, Phil Race wrote:

I am not sure we are using the summary in a way that makes it
worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive

value

of the contents of the table. A caption is more like a

title"

The values I see are more like a title and as you say that is

not

the idea. See the example here

https://www.w3.org/TR/WCAG20-TECHS/H73.html

Caption sounds like a title so it might actually be more
appropriate than summary
for the text we have except that its not clear why we'd want

be visible when we were fine without.

But being there and invisible may be pointless unless screen
readers look for it even if invisible.

But if its not doing any harm I guess we can leave it as

proposed

I still need to look at the rest of the changes.

-phil.

On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:

Sergey,

FWIW, the invisible caption should be regarded as a temporary
solution, until content authors can review/update the text of

the

caption and make it visible.

The general guideline in this conversion work has been to

avoid

changing the visible text of the specification, and captions

fall

into a grey area of whether the text is significant/normative

not. Hence the temporary step to make them not displayed for

now.

-- Jon

On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:

The "summary" is unsupported by the HTML5 and we replace it

invisible caption.
These new styles are located in the stylesheet.css in the

root

the JavaDoc api folder, so I assume these styles should be

used

by others as well.
They were added by this fix:

[9] Review request for 8178996 [macos] JComboBox doesn't display popup in mixed JavaFX Swing Application on 8u131 and Mac OS 10.12

2017-05-11 Thread Alexander Zvegintsev


Hi all,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8178996/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8178996


Popup doesn't show up due to owner is lightweight frame and doesn't have 
a native pointer,


thus we do not invoke owner.execute() code block, while 
nativeCreateNSWindow should be called with null ownerPtr.



--
Thanks,
Alexander.

[9] Review request for 8177919: java.awt.Desktop.setDefaultMenuBar() should be specified to throw IllegalStateException

2017-04-11 Thread Alexander Zvegintsev


Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8177919

This fix removes throwing of ISE, this allows to use default menu bar 
with LaF's other than Aqua (with apple.laf.useScreenMenuBar set to true).


This became possible after JDK-8166683[0] fix.

Current documentation of Desktop.setDefaultMenuBar() has implnotes:

 * @implNote Aqua Look and Feel should be active to support this on 
Mac OS.


I leave it unchanged, since I don't want to advertise the 
apple.laf.useScreenMenuBar property.


[0] https://bugs.openjdk.java.net/browse/JDK-8166683


--
Thanks,
Alexander.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

2017-03-15 Thread Alexander Zvegintsev


How about that version?

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/04/

Thanks,
Alexander.

On 15/03/2017 20:18, Philip Race wrote:


Even if all we can add (to what is already proposed) is
"whether an icon for a window is displayable in the task bar is
dependent on all of window type, platform, and implementation"
then I think that clearer than the current words which could be
misinterpreted as meaning something like addressing that
if you call hide() then of course it disappears ..

-phil.

On 3/15/17, 10:02 AM, Sergey Bylokhov wrote:

It is not necessary, if the frame has utility type.


So can we say this with that qualification ?


This is also implementation detail, that such windows are not 
visible in taskbar. This is not specified anywhere and can be 
changed in the future.


If this is consistent in our current implementation on all platforms 
then
there is no problem making this part of the spec and changing the 
spec in

the future if that changes.


It was not implemented on systems other than windows, so if we change 
the signature we will not be able implement/change this on linux/osx.




We have to say something. I can't agree the current words are enough.


What is wrong in the current wording? If the element is not visible 
in taskbar we cannot show something on top of it. We never specified 
when something is visible/non-visible in taskbar.
We can update the words, but it will be good to use current methods 
signatures.




-phil.








- Dialogs are always visible if they have no owner


This is implementation details on windows. I am not sure why it 
was implemented this way, is it really intended behavior or not.


So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.


Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not 
visible in the task area.» is enough because it also covered the 
case when the window is invisible.





- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window 
(including

  Window itself) are never visible ?



What about the last point ?


It depends from the implementation.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

2017-03-15 Thread Alexander Zvegintsev

It turned out that if Dialog has no owner(e.g. new Dialog((Frame) null)) 
it is visible in the taskbar.


So I am reverting API change.

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/03/

Thanks,
Alexander.

On 14/03/2017 23:43, Alexander Zvegintsev wrote:
It has no representation on windows, but I assume it can have such on 
other platforms like OSX/Unity?
OSX/Unity functionality doesn't have per window concept, they have per 
application. For these operating system you should use 
setProgressValue() instead of setWindowProgressValue()(and so on).



We also exclude JWindow.

It doesn't show up in the taskbar too like java.awt.Window.

--
Thanks,
Alexander.

On 14.03.2017 20:44, Sergey Bylokhov wrote:
It has no representation on windows, but I assume it can have such on 
other platforms like OSX/Unity?


It is fine too, because Dialog has no representation in the taskbar 
too.

We also exclude JWindow.


--
Thanks,
Alexander.

On 14.03.2017 15:56, Philip Race wrote:

Hi,

I realise I need to clarify one thing that may be important.
Previously with Window this could apply to a Dialog.
Now it cannot. Are we disabling an important case with this change ?

-phil

On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:

There is no precedents here:

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/

Thanks,
Alexander.

On 14/03/2017 15:40, Philip Race wrote:
with this change maybe we should be renaming the parameters and 
update the doc

ie
279  * @param w window
could be
@param f frame
?

Or is there precedent for what you have right now ?

-phil.

On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
So they already know the window isn't visible and are asking 
for an explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".
Actually java.awt.Window is not visible in taskbar because of 
its window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it 
has nothing to do with decorations.


I've replaced parameter type with Frame instead if Window to 
avoid such misunderstanding. Frame still can be removed from 
taskbar by f.setType(Window.Type.UTILITY) call.



I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

This part of API is supported for Windows only.


http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:

The JCK comments in the bug are :

This may be a specification issue.
Window progress is not displayed in taskbar as specified.
The spec states that progress is displayed in a 
platform-dependent way.
I>f progress is not in fact displayed under some circumstances, 
that should be specified.


So they already know the window isn't visible and are asking 
for an explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for 
its window in the taskbar, thus we can't show progress for 
this window there.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar


It has no representation on windows, but I assume it can have such on other 
platforms like OSX/Unity?
OSX/Unity functionality doesn't have per window concept, they have per 
application. For these operating system you should use 
setProgressValue() instead of setWindowProgressValue()(and so on).



We also exclude JWindow.

It doesn't show up in the taskbar too like java.awt.Window.

--
Thanks,
Alexander.

On 14.03.2017 20:44, Sergey Bylokhov wrote:

It has no representation on windows, but I assume it can have such on other 
platforms like OSX/Unity?


It is fine too, because Dialog has no representation in the taskbar too.

We also exclude JWindow.


--
Thanks,
Alexander.

On 14.03.2017 15:56, Philip Race wrote:

Hi,

I realise I need to clarify one thing that may be important.
Previously with Window this could apply to a Dialog.
Now it cannot. Are we disabling an important case with this change ?

-phil

On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:

There is no precedents here:

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/

Thanks,
Alexander.

On 14/03/2017 15:40, Philip Race wrote:

with this change maybe we should be renaming the parameters and update the doc
ie
279  * @param w window
could be
@param f frame
?

Or is there precedent for what you have right now ?

-phil.

On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:

So they already know the window isn't visible and are asking for an explanation
of the circumstances for this so I don't think this update will satisfy them 
without
more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

Actually java.awt.Window is not visible in taskbar because of its window style 
flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has nothing to do with 
decorations.

I've replaced parameter type with Frame instead if Window to avoid such 
misunderstanding. Frame still can be removed from taskbar by 
f.setType(Window.Type.UTILITY) call.


I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

This part of API is supported for Windows only.


http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:

The JCK comments in the bug are :

This may be a specification issue.
Window progress is not displayed in taskbar as specified.
The spec states that progress is displayed in a platform-dependent way.

I>f progress is not in fact displayed under some circumstances, that should be 
specified.

So they already know the window isn't visible and are asking for an explanation
of the circumstances for this so I don't think this update will satisfy them 
without
more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for its window in the 
taskbar, thus we can't show progress for this window there.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

It is fine too, because Dialog has no representation in the taskbar too.

--
Thanks,
Alexander.

On 14.03.2017 15:56, Philip Race wrote:

Hi,

I realise I need to clarify one thing that may be important.
Previously with Window this could apply to a Dialog.
Now it cannot. Are we disabling an important case with this change ?

-phil

On 3/14/17, 5:54 AM, Alexander Zvegintsev wrote:

There is no precedents here:

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/

Thanks,
Alexander.

On 14/03/2017 15:40, Philip Race wrote:
with this change maybe we should be renaming the parameters and 
update the doc

ie
279  * @param w window
could be
 @param f frame
?

Or is there precedent for what you have right now ?

-phil.

On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
So they already know the window isn't visible and are asking for 
an explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible". 
Actually java.awt.Window is not visible in taskbar because of its 
window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has 
nothing to do with decorations.

I've replaced parameter type with Frame instead if Window to avoid 
such misunderstanding. Frame still can be removed from taskbar by 
f.setType(Window.Type.UTILITY) call.

I do not know if we can say something stronger than that ?
Is this the case on all platforms ? 

This part of API is supported for Windows only.

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:

The JCK comments in the bug are :
>This may be a specification issue.
>Window progress is not displayed in taskbar as specified.
>The spec states that progress is displayed in a 
platform-dependent way.
I>f progress is not in fact displayed under some circumstances, 
that should be specified.

So they already know the window isn't visible and are asking for 
an explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for its 
window in the taskbar, thus we can't show progress for this 
window there.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar

There is no precedents here:

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/02/

Thanks,
Alexander.

On 14/03/2017 15:40, Philip Race wrote:

with this change maybe we should be renaming the parameters and update the doc
ie
279  * @param w window
could be
 @param f frame
?

Or is there precedent for what you have right now ?

-phil.

On 3/14/17, 5:33 AM, Alexander Zvegintsev wrote:
So they already know the window isn't visible and are asking for an 
explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible". 
Actually java.awt.Window is not visible in taskbar because of its 
window style flags(WS_EX_NOACTIVATE, WS_EX_TOOLWINDOW), it has 
nothing to do with decorations.

I've replaced parameter type with Frame instead if Window to avoid 
such misunderstanding. Frame still can be removed from taskbar by 
f.setType(Window.Type.UTILITY) call.

I do not know if we can say something stronger than that ?
Is this the case on all platforms ? 

This part of API is supported for Windows only.

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/01/

--
Thanks,
Alexander.

On 14.03.2017 0:52, Phil Race wrote:

The JCK comments in the bug are :
>This may be a specification issue.
>Window progress is not displayed in taskbar as specified.
>The spec states that progress is displayed in a platform-dependent 
way.
I>f progress is not in fact displayed under some circumstances, that 
should be specified.

So they already know the window isn't visible and are asking for an 
explanation
of the circumstances for this so I don't think this update will 
satisfy them without

more explanation.

At the very least we need to add that
"Some {@code Window}s are not visible in the task bar.
For example undecorated Windows may not be visible".

I do not know if we can say something stronger than that ?
Is this the case on all platforms ?

-phil.

On 3/13/2017 2:04 PM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8176528/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8176528

The test uses java.awt.Window which doesn't have button for its 
window in the taskbar, thus we can't show progress for this window 
there.

Re: [9] Review request for 8176528: Progress state for window is not displayed in taskbar