<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body><a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> changed <a class="bz_bug_link bz_status_NEW " title="NEW - Implement wl_probe, or something similar" href="https://bugs.freedesktop.org/show_bug.cgi?id=75382">bug 75382</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">CC</td> <td> </td> <td>jadahl@gmail.com </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement wl_probe, or something similar" href="https://bugs.freedesktop.org/show_bug.cgi?id=75382#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement wl_probe, or something similar" href="https://bugs.freedesktop.org/show_bug.cgi?id=75382">bug 75382</a> from <a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to x414e54 from <a href="show_bug.cgi?id=75382#c5">comment #5</a>) > (In reply to Pekka Paalanen from <a href="show_bug.cgi?id=75382#c4">comment #4</a>) > > (In reply to x414e54 from <a href="show_bug.cgi?id=75382#c3">comment #3</a>) > > > I prefer just being able to give the compositor a hint of what it should do > > > if it does not fit. Something like flip-x, flip-y, resize-w, resize-h, > > > nothing, scale parent surface. > > > > > > Though I think compositors will already automatically do some of this > > > depending on if it is a popup or child/transient surface. > > > > > > Probing does not make sense as if your surface is full-screen on one output > > > and normal on another output you would have to place the sub-surface inside > > > the main surface on all outputs even if it would be fine in the correct > > > position on the non full-screen output. > > > > > > If you give the compositor a hint and let it take care of it then it can > > > place it differently on different outputs. > > > > Sorry, but I don't think any of that makes sense. > > > > Menus usually want to be aligned somehow to some widget (of which the > > compositor has no knowledge of at all) like a menu-bar "button". The > > compositor does not have the knowledge to reposition the surface to keep the > > GUI aligments that the application toolkit wants to have. I suppose you > > could remedy that by giving the compositor the rect around which the popup > > should be aligned, but that's getting comlicated and moves some of the popup > > placement policy into the compositor, away from the toolkit. > > > > Resize would be basically the same as probe, except you'd probably get > > visual flicker. Probing is simpler. Scaling wouldn't work at all, because it > > would mess up the GUI scale and visual appearance. > > > The popup placement should be up to the compositor. > Otherwise you have situations where the compositor resizes/moves the parent, > or popup or even the display is resized > and the popup has not moved/closed/changed, which looks really stupid. > You would have to constantly call these probe events in a loop and update > the popup position. The compositor cannot resize a clients surface, it can only suggest a new size. It is completely up to the client to attach a buffer and window geometry with appropriate size. A parent surface of a popup, be it a xdg_surface or another xdg_popup, cannot be removed/unmapped before the child popup. If a client tries to do that, it will be terminated with an error for breaking the protocol. A compositor is responsible for implementing the same semantics regarding map/unmap order of popups. If I understand your concerns correctly, you think that, while a popup is showing, moving the parent window might potentially make the popup end up partly or fully off screen. I'm not sure this can happen, since a move would take the grab and implicitly dismiss the previous grab i.e. unmap all the popups. If it is true that one may initiate an interactive move without unmapping the popups we'd have to decide whether it is more important to support reliable positioning of popups (so that client can draw UI which content in the popup and parent surface align), or that moving a surface with mapped popups attached should implicitly reposition them given whatever constraints the compositor wants. I'd say the first option which wl_probe allows is more desirable. > > > This is what the configure events are for. To tell you the compositor has > resized your > surface and to resize the content to fit. So scaling and aspect ratio would > not be an issue. A compositor may not resize a clients surface, it may only suggest that the client resizes its own surface. This is what the configure event is for. > > There would be no flicker because you would not have committed/swapped the > initial buffer > or set the opaque region. Until that point the popup would be transparent. > > > If you do not mind about the x, y placement (e.g. in the case of right click > style menu popups) > but want the width/height obeyed you can use something like the flip-x, > flip-y hints. > The compositor can then align to the bottom left instead of top left, etc. > > If you mind where the x,y placement is but do not mind the height (e.g. in > the case of combo box style popups) > you can use the resize-h hint and then you get a configure event and resize > the content before committing the buffer. > > > > You cannot have a wl_surface fullscreen on one output and normal on another > > output. A wl_surface can have just one xdg_surface, and so it cannot be > > fullscreen and normal at the same time, even if the visual appearance of the > > surface allowed both, which it usually doesn't. > > From the compositors point of view it can do whatever it wants with the > surface. > It has nothing to do with the application's interface to xdg_surface. > > Take "mirrored" desktops for example, the surface will appear on two or more > outputs with possibly with different dimensions. Neither of them is > "primary". > > Calling set_fullscreen can be passed an output. > > It is undefined what happens to the surface on the other output. > Does it fullscreen also? Does it stay non-fullscreen? Does it disappear? > It is up to the compositor's implementation of a "mirrored" desktop. The client will render the surface as if it would be fullscreen, probably with the same dimensions as the output it fullscreened on. Of course the compositor can render it however it wants, but the content would still be as if it was fullscreen, and a client should assume so is also the case. This seems completely unrelated to wl_prope or popups. > > > > > > If the compositor is showing the wl_surface in several places, it also knows > > what it is doing with those places, and will know how the probe needs to > > behave. The client will always assume the window is in one place, and I > > believe it also needs to know where the popup surface is wrt. the parent > > surface. > > It is not safe for a client to assume that a window is on one output at a > time. > > Probing will lead to a hack way for clients to attempt to guess the parent > window position > on an output. It can also expand its buffer size while keeping the same input region and buffer content making the expansion transparent, until it receives a "wl_surface.enter", and then calculate its position. That doesn't mean wl_surface.enter is the wrong thing to do. > > Also there is no way to know where the popup was actually placed in-relation > to the parent, > you just have to trust the compositor was not stupid. Which is why it is > better to give hints > about what to-do rather than to attempt to place it EXACTLY somewhere and > have it moved by the compositor. If we specify a protocol which, similar to subsurfaces, mandate the compositor to place popups relative to its parents in a reliable way, why wouldn't one know exactly where it is placed? > > > Menus are of type xdg_popup. Child or transient surface are not xdg_popups, > > because xdg_popup implies that the GUI needs a grab to operate as expected. > > If you don't want or need a grab, it's not a xdg_popup. Grabs can also be > > denied, so it's always possible the xdg_popup will be dismissed before it > > gets shown, but that just normal race avoidance. > > > > > > Also, nothing here is about sub-surfaces. They are a completely different > > thing. You do not implement menus as sub-surfaces, because you can't get the > > grab behaviour you need. > > No but there are plenty of other situations where you do not want a grab but > still want the > child surface positioned in the same way. Tooltips for example. Tooltips should be and mostly are (toytoolkit, GTK+) implemented using subsurfaces. > > Also some tool-kits (GTK) or browsers (Chrome) which currently do not have > (or is being deprecated) > a way to use an implicit grab for popups and use normal child/transient > surfaces instead.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>