Daniel Stone wrote:
I also think all of wl_shell should be a core requirement.
Not all compositors are user sessions. Think about nested compositors
for browsers, or capture, or also very stripped-down usecases where
they really don't want to have to deal with this kind of thing.
For simple displays like one that is a single full-screen window always,
the api "works" in that raises determine which window is visible, and
attempts to resize or turn off full-screen are ignored.
Though nested compositors are an interesting idea, it is clear from how
the subsurfaces are being designed that it is not felt that nested
compositors are not really useful. The biggest problem I see is that the
nested compositor probably loses any high-speed optimizations that only
the real compositor can do. I really suspect the only use of a nested
compositor will be to test a wayland server inside a window on another one.
I don't think it's an unreasonable requirement, and really like the
design it has at the moment, where attaching the scaler object
suppresses the resize-on-attach behaviour, and destroying it reverts
to previous. It's pretty elegant, and totally in the vein of
wl_shell_surface stacking on top of wl_surface. I don't see how
inventing more elaborate extension mechanisms on top of our existing
extension mechanism helps anything.
No what I propose is to figure out how to document it so that the
wayland api documentation is easier to follow. Make the rules for these
sub-api objects match. Then I would expect to see the set-scaling listed
under the wl_surface api. There would be a small indication that this
api is through the wl_scaler subapi and the rest of the details would be
defined in a single section of the wayland documentation.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
