<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - It is impossible to screenshot a user selected window." href="https://bugs.freedesktop.org/show_bug.cgi?id=99635#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - It is impossible to screenshot a user selected window." href="https://bugs.freedesktop.org/show_bug.cgi?id=99635">bug 99635</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to naelstrof from <a href="show_bug.cgi?id=99635#c4">comment #4</a>) > (In reply to Pekka Paalanen from <a href="show_bug.cgi?id=99635#c2">comment #2</a>) > > ...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 <a href="show_bug.cgi?id=99635#c2">comment #2</a>) > > 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: <a href="https://cgit.freedesktop.org/wayland/wayland-protocols/">https://cgit.freedesktop.org/wayland/wayland-protocols/</a> <a href="https://cgit.freedesktop.org/wayland/weston/tree/protocol">https://cgit.freedesktop.org/wayland/weston/tree/protocol</a> 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>