<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#c4">Comment # 4</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:naelstrof@gmail.com" title="naelstrof@gmail.com">naelstrof@gmail.com</a> <pre>Thanks for the insightful comment, I should've taken my proposal from that perspective this whole time. Is there a name for it? Anyway I've done a bit of thinking and came to some conclusions. > What does the user really want to do? The user wants to share what he/she sees. Easy. Breaking down what needs to happen into steps: 1. The user must let the computer know he/she wants to share something. 2. What wants to be shared needs to be selected somehow. 3. The data must be encoded somewhere/somehow. 4. The encoded data must be uploaded somewhere. 5. The content URL/data should be available in a clipboard. There's obviously no one-size fits all implementation for any one of these steps. Some people might have tiny hands and struggle to press certain button combinations. Some people may not be able to access certain image sharing websites, or doesn't want to have their screenshots publicly available. Instead of a link to an image put into the clipboard, someone might prefer the actual pixel data to show up there for posting in mumble or the like. Some people prefer JPEG over PNG because their hard-disk space is low. etc. etc. My point is that every step of this process is very expressive, personal, and equally important. If any one of these steps suffers, so does the user trying to share their screen. As of right now, every step is perfectly customizable. Every step could easily be filled with its own application, and offer infinite customization options. Except for step 2: The user is currently forced to draw a rectangle around what he wants to share on Wayland. "Oh but you can capture the active window instead!" NO. That'd mean I would have to bind TWO screenshot buttons to serve the same purpose. (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. (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. 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>