<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <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#c5">Comment # 5</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:x414e54@linux.com" title="x414e54@linux.com">x414e54@linux.com</a> <pre>(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. 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. 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. > > 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. 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. > 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. 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>