[Wayland-bugs] [Bug 99635] It is impossible to screenshot a user selected window.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99635

--- Comment #10 from Pekka Paalanen <ppaalanen at gmail.com> ---
(In reply to naelstrof from comment #4)
> (In reply to Pekka Paalanen from comment #2)
> > ...If the only thing you wanted to do is to make a one-shot capture of one user selected window, it would be much easier to create e.g. a D-Bus command to do just that...
> NO. There's times where I need to select a window, and times where I need to
> crop it. Again I would have to bind TWO buttons to serve the same purpose.

Why should cropping further down to a window sub-region be part of capture?
Wouldn't that be done with, say, an image manipulation program, like one that
submits the image to a web service if one uses such?

The compositor should probably be concerned about cropping on the scale of: all
outputs, a specific output, a specific top-level window. To me that seems like
a nice trade-off between complexity of use vs. security (what is guaranteed to
not be captured). The same way one picks a specific window, there could be
options for a specific output or all outputs.

This kind of split between the compositor and client program responsibilities
would be natural: the compositor can keep working with complete buffers, while
the client program never needs to care about window positions or how they might
be warped on screen. If you capture a window, you get the 2D image the
application has drawn for the window. If you capture an output, you get what
has been sent to a monitor.

> (In reply to Pekka Paalanen from comment #2)
> > What if a surface has multiple positions? There are compositors that do that. What if the position is not on a linear 2D space, but in a 3D space? Maybe curved?
> Now that the purpose has been more clearly defined, I believe this becomes
> the root of the problem. How could one develop a selection
> protocol/extension that could cover these cases, not just the 2D rectangle
> ones. This makes it seem like selection should be up to the compositor,
> since with 2D rectangles the solution is really simple.

My first go would be something like:
1. A client program asks the compositor to pick something to be captured.
2. The compositor asks the user what he wants to pick.
3. The compositor passes back an abstract object referring to the picked
target.
4. The object delivers e.g. snapshots once or on-demand, continuous video,
notifies of the target disappearing, etc.

This leaves it completely unspecified how the compositor gets the selection
from the user, which is a good thing as it depends on how the compositor works.
One possibility could be an exposé kind of overview where each window is shown
clearly separate plus previews for each output and all outputs together. Or
maybe per virtual desktop views. Or something completely different, like
drawing a box for where to capture from.

If the capture target is or becomes off-screen, the compositor could make sure
it keeps updating as if it was on-screen as long as the object exists.

> Exposing surface positions is non-trivial and allowing applications to grab
> input is dumb and unnecessary. You've mentioned extensions, Pekka. Could you
> describe that a bit more? It's hard for me to imagine how to implement this
> currently.

Everything in Wayland is an extension. There are a bunch in:
https://cgit.freedesktop.org/wayland/wayland-protocols/
https://cgit.freedesktop.org/wayland/weston/tree/protocol

The major point there is that each extension does its thing without the need to
modify what is in wayland.xml file.

An extension is essentially a (at least one) global interface advertised
through wl_registry, which provides discovery of the feature and a binding
point, plus any further interfaces needed.

But depending on the case it does not need to be Wayland, it could be something
else like D-Bus.

The reason to use Wayland is when the application is already using Wayland
anyway and needs to address its own objects as part of the operation. If that
is not readily true, then one needs to think which communication mechanism is
the most appropriate. Could e.g. D-Bus be more suitable because of the features
it has that Wayland does not?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170202/b9c55708/attachment.html>