Introduce simple API to take a screenshot #2104
Conversation
Test Results 539 files ±0 539 suites ±0 30m 3s ⏱️ -45s For more details on these failures, see this check. Results for commit 15c78c2. ± Comparison against base commit d1859ce. |
|
What about a class |
|
Wouldn't it make more sense to have this be a property of the Control, rather than moving this to the SWT class? Eventually, this functionality should probably also be supported for Widgets in general and not just Controls, which doesn't really work with a static method. |
| Image image = new Image(display, bounds); | ||
| GC gc = new GC(source); | ||
| try { | ||
| gc.copyArea(image, 0, 0); |
There was a problem hiding this comment.
If the source is invisible, this will capture the area underneath the widget. This should then either return null or a blank image.
As mentioned one can not take a screenshot of a Control, this is only used to make a screendump of the area where the control is currently located. To capture a control one can create a GC and "draw" the control then there. |
But in that case I don't really see the benefit for the user. Keeping an internal |
As written in my initial message, I appreciate any suggestion where this new functionality is discoverable and flexibly usable. So if it makes sense to have various configuration options a new
I see that there is also a method Can you tell if that behaves differently and e.g. allows to record the surface of that Control even if it's not visible respectively not supported to capture the entire display?
That's kind of funny, Windows offers a 'feature' where it take screenshots automatically all the time (https://support.microsoft.com/de-de/windows/mit-recall-ihre-schritte-zur%C3%BCckverfolgen-aa03f8a0-a78b-4b3e-b0a1-2eb8ac48701c, article is in Germany, I didn't found the English version quickly). But even if it's not supported at all respectively impossible on some OS/WS combinations an API could still help users, if it's stated that it's an optional operation and if it fails cleanly with an exception if one is really in that situation. Then clients would at least not use some random snippets that don't work all the time and not fail cleanly, but just produce unexpected result. As this topic doesn't seem to be that easy (thank you for all that input), I think it's even more important to help users and provide the 'best', most robust solutions possible. |
Screen capture is explicitly unsupported in Wayland for the sake of "security": "By design, Wayland is a lot more secure than X11 and does not allow one application to capture the content of other applications' windows" Or in short: This has been pushed down to the DE. So you can still take screenshots with Wayland, but now there's a Gnome way to do it, a KDE way to do it and so on... Not really something that can be integrated in SWT. I think the "official" way is via the xdg-desktop-portal but I've never worked with it and you'd be yet again at the mercy of the DE to support this portal... With GTK4, the GdkWindow has been made internal, so the required API is no longer available. See You have the GtkSnapshot as replacement but which only works for widgets. To summarize: Screen capture in Linux sucks.
Which in the end would make (parts of) SWT no longer cross-platform compatible... |
|
To add to my previous comment: It might still be possible to capture the SWT widgets in GTK4/Wayland, which I believe is exactly what |
|
Have you evaluated whether |
Currently it's quite cumbersome to take a screenshot from a
Controlor aDisplay. This proposes a convenience API to simplify this task.When fully used within SWT it significantly reduces the calls to the to be deprecated Image constructor:
Together with #2103, it becomes very simple to take and save a screenshot.
I'm not yet sure where such a method is added best. Currently it's a new static method in the general
SWTclass. Alternativly it could be a static 'factory' like method in theImage/ImageDataclass or it could be in a new utility class or somewhere else?