On Wed, Aug 6, 2014 at 8:28 PM, Bill Spitzak <spit...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel