#Problems with xquartz window size update
#Problems with xquartz window size full
#Problems with xquartz window size windows

This will need a Wayland protocol extension to add a role for an output-only, centered surface.

#Problems with xquartz window size windows

This is due to Wayland not allowing windows to position themselves. Problem: splash screens displays somewhere in top left Once permission is given, you can use it to completely control the keyboard and mouse. You can do most of this using the RemoteDesktop portal. However, its shipping time(even estimated) is not yet known. Solution: This will probably be implemented be libEI. JDK-8280988 X11 compatibility: Click on title to request focus test failures JDK-8280990 X11 compatibility: XTest emulated mouse click does not bring window to front. JDK-8280995 X11 compatibility: Robot.mouseMove does not visually move mouse cursor Implementing this via libEI will also fix some of the X11 compatibility issues: It mostly works for X11 compatibility mode (except when trying to reach outside XWayland and windows are not restacked on emulated mouse click). Problem: The class provides methods to emulate input keyPress(), keyRelease(), mousePress(), mouseRelease() JDK-8280983 emulating keyboard/mouse events In case of automated testing it may be a stopper. If some new display got or disconnected, new permission request from user is required. However we may want to implement both of approaches:

each display has its own stream, in case if requested screenshot area covers several displays resulting screenshot need to be combined from pieces.Įach solution is viable, but #2 seems to be more preferable.

no intermediate file, screenshot data can be obtained from memory.new permission required if display set is changed or rearranged, might be an issue in case of remote automated testing.Permission to make screenshots can be stored with restore_token (string), that needs to be stored safely somewhere.A user can deny the screenshot request too.implementation is more complicated comparing to Screenshot API.

This might be a bit of overkill, but it avoids several of the problems mentioned in the screenshot and color picker portals. It does not allow to take a pixel color at specified location, but interactively asks a user to pick a color with mouse cursor.įinally, another possibility is to use the Screencast portal. There is also #PickColor API which can't be used for Robot#getPixelColor needs.

There is no way to disable the 'screen flash' after screenshot.

Currently it is thrown only if readDisplayPixels permission is not granted(which is not suitable here).

#Problems with xquartz window size update

In this case as a possible solution we can throw a SecurityException for Robot#createScreenCapture (javadoc update required).

It saves a screenshot to disk, which must be read and deleted(may be slow depending on drive).

(note, this was fixed for GNOME 43, not yet delivered to most distros)

It asks a confirmation on each screenshot request, so it is unusable for automated testing.

It does not allow to take a specified screen area, only whole screen.

However, it has some drawbacks(at least on Gnome): Specifically, it provides #Screenshot which can be used to create a screenshot. Solution: Use xdg-desktop-portal, a cross-platform stable D-Bus API which works on GNOME, KDE and wlroots-based compositors. I see that there is an open bug against this issue. So, it would be great to get some standard API to get screenshot data in memory.

#Problems with xquartz window size full

For instance, just a sync DBUS call to take a 1000x1000 screenshot and save it to the shared memory object file is ~14 time slower(it is just saving, without decoding and extracting data) comparing to full X11 implementation. Using DBUS API in this case is really slow.It can be workarounded by using shared memory object though. You need to save it to some file(its filesystem can be slow). Screenshot is saved to png file, after that you have to read it, decode it. There is no direct access to the screenshot data.DBUS API (which will not work for KDE, it has another API) It can be done using some shell specific APIs, e.g. It is doable as of now, but not in a standard and convenient way. Problem: The class provides createScreenCapture() method which currently uses X11-specific APIs