[PATCH] xdg-shell: remove constraints for fullscreen
daniel at fooishbar.org
Mon Jun 24 10:33:04 UTC 2019
On Mon, 24 Jun 2019 at 09:00, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> > To be clear, the patch does break backwards compatibility with compositor
> > behavior -- it only weakens a guarantee by saying that transparent
> > fullscreen content is undefined. Existing compositor behavior is still
> > allowed.
> To weaken the guarantees previously defined is breaking backward
> compatibility. Clients that implemented its functionality given the
> promises defined by the specification would have to change according to
> the new promises.
Yeah. I don't want to go down the road of removing promises we've made
to clients: if we absolutely must do this, then it would have to be
accompanied by a version bump so clients can opt in to the new
behaviour. But doing it without a bump means that no-one would be able
to rely on guarantees we make in protocol.
That being said ...
> > That said, adding a new request does not seem like a good solution to me --
> > if the user presses a compositor key shortcut, should the app be in
> > transparent or opaque fullscreen mode? It might make sense to have a
> > special "set_fullscreen_blend_mode" that clients can use to configure their
> > fullscreen appearance in all cases. I do not imagine this will change
> > often, so it likely does not need to be a state.
> Setting a fullscreen blend mode as part of configuring the fullscreen
> state seems more sane than a separate fullscreen request indeed.
> Probably want to enforce the configured size for non-opaque blend modes
> too, to not have to let the region outside the surface be undefined.
Scott wrote up a surface-blend-mode proposal a while back:
I wonder if we could simply specify that an explicit request for
surface blending will result in the fullscreen surface not being
pillarboxed/letterboxed with black around it?
More information about the wayland-devel