<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#c2">Comment # 2</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>Hi, you may need to split and reorganize the ideas and concepts somewhat. For instance, selecting a window in a client program would require not just exposing window handles, but also augmenting the input interfaces to be able to talk in the window handle terms, and make the compositor allow to grab e.g. the pointer so that the client program can get input outside its own windows (which might be none, which currently disallows grabbing altogether). These are each one a fairly awkward feature to design and justify. 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: "ask the user to select a window and give me the screenshot of it". This would also allow the compositor not just use the pointer as we have done on X11 for decades, but e.g. display a list of windows, including those you cannot currently reach with the pointer. Exposing surface positions is also not a trivial thing. 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? You can of course choose to limit the protocol extension to the usual cases, but then you might make it hard to implement for some compositors. The reason we have worked very hard to avoid any global position information in Wayland core set of protocols is that having it will exclude some inventive, funny, strange, or awesome use cases. Rather than blindly copying concepts from the way we have always done things, it does pay off to first think what the user really wants to do and how best to achieve that instead of starting from how it has been implemented before. One might find much better ways, or whole new use cases become possible. Or, one might that the old way really is the way, in which case one needs to figure out how to integrate it in the new world order. And some things might actually be better left out. Your listed use cases are far from easy to design for, but I wouldn't call them impossible or unacceptable. I would encourage you to work on them. The success of your proposals will be measured in how many compositor projects implement your proposal. Making your extensions optional is key, because no-one can force compositor projects to accept this kind of features, and we probably would not have it in Wayland core set of protocols. What the latter means is that you should not add window handle methods in wl_pointer or wl_surface interfaces for instance.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>