[PATCH] Introduce set_size_hints xdg_surface request.
Jasper St. Pierre
jstpierre at mecheye.net
Wed Aug 6 17:38:07 PDT 2014
On Wed, Aug 6, 2014 at 8:28 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Never mind my previous response. I just tried a bunch of programs that
> implement tiling internally, and only one of them (a Mail program with very
> simple set of 3 tiles) made a tile taller as it got narrower. All others
> just introduce scroll bars. Since these are programs with complete control
> and knowledge of their contents, it appears that it is too hard to do the
> complex resizing I was suggesting, especially for unknown clients.
>
> So it seems ok to have the client send a minimum size to the compositor.
> The tiled compositor will figure out the layout based only on it's state
> and the minimum sizes of all the clients. No round trips.
>
Yeah, the complexities of height-for-width layout means that there is no
independent minimum width/height, only a minimum area, but that sort of
constraint system is difficult to express to a compositor, and most clients
should be able to come up with one minimum size, however large or small it
might be.
> It is still important that clients know the compositor may configure
> smaller than the minimum, and compositors to know that clients may resize
> the surface smaller too.
>
> If the compositor requests a size that is too small, the client is
> expected to add scrollbars. If the contents "reflow" then it will probably
> manage to add a scrollbar in only one direction (this is why the client
> must do the scrollbars, not the compositor). If the client makes the
> surface larger than requested, the tiled window manager can clip or scale
> it to fit.
>
For the maximized or fullscreen states, the client must always submit
window geometry that is the configured size. No exceptions.
> I am unsure if a maximum size is wanted. If a client actually has a
> maximum size it will just make the surface that size when a larger size is
> requested. The tiled window manager can then pad it with rectangles, this
> does not add any round trips. I could not find any program where the tiles
> act like there is a maximum size, and it is difficult to see what could be
> done with this information, for instance if a surface with no maximum size
> is in the same row/column. There is also the problem that you have to do
> something unintuitive to indicate there is no maximum size. So I would
> remove this, perhaps making it a different request in the future.
>
Yeah, we were debating on IRC about the utility of a max_size. I don't
think it's necessary, but I figured we would look around and see if any
other clients used it. The only case I could think of is an unresizable
client, in which case it would set the minimum and maximum sizes to be the
same. I think we should handle that with a separate system.
A tiled window manager also needs an api to tell the client to not draw
> "edges" and the shadow. This is also useful for maximized and fullscreen.
> Turning the titlebar on/off would be a different control, some tiled window
> managers may want to keep it.
>
One step at a time. We'll get there.
_______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140806/307e926a/attachment.html>
More information about the wayland-devel
mailing list