[Wayland-bugs] [Bug 75382] Implement wl_probe, or something similar

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75382

--- Comment #8 from x414e54 at linux.com ---
> 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.

This is irrelevant to the point that configure events could be used inplace of
a wl_probe. 
The Compositor would suggest the new size based on the hints.

Also this is not how the (current) wording of xdg_shell.xml implies configure
events:

        "The surface is maximized. The window geometry specified in the
configure
        event must be obeyed by the client."
        "The surface is fullscreen. The window geometry specified in the
configure
        event must be obeyed by the client."
        "The surface is being resized. The window geometry specified in the
        configure event is a maximum; the client cannot resize beyond it.
        Clients that have aspect ratio or cell sizing configuration can use
        a smaller size, however."

"Obey" and "Maximum" are certainly not "suggest".

> 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.

Yes but it is not just about moving the parent window.
It *could* mean other events like hotswapping monitors/display mode change will
have to dismiss all grabs and close all popups.

Some toolkits and applications do want grab-free "popups" that are either child
windows or subsurfaces. 

They may still want to be notified when the subsurface is clipping the display
without having to poll wl_probe.

Even the parent surface may want to know when it will clip a display. 
Some kind of accordion style UI.

Chrome when dragging/moving tabs currently forces them to be constrained to the
display area.

> 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.

Okay maybe not fullscreen but two monitors with the same window in different
positions.

One at the bottom of the screen and one at the top.

The compositor will be able to work where to put the popup on based on seat and
serial.
But wl_probe would be a worse case and have to return the minimum size always.

> 
> 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.

This would not work if there was only one display or they were not stitched
together.
But it is a fair point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150328/5fc9935b/attachment-0001.html>