[PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

There is already this paragraph added to xdg_toplevel:

+      Unmapping an xdg_toplevel means that the surface cannot be shown
+      by the compositor until it is explicitly mapped again.
+      All active operations (e.g., move, resize) are canceled and all
+      attributes (e.g. title, state, stacking, ...) are discarded for
+      an xdg_toplevel surface when it is unmapped.

Is that enough? We could probably add something about remapping should
be indistinguishable from destroying, creating then mapping, but the
above should mean the same thing.

FWIW, for popups we don't allow remapping.


Jonas

Oe Mon, Jul 17, 2017 at 03:09:14PM -0700, Jasper St. Pierre wrote:
> Then I'd like some stronger wording in this patch that dictates that
> unmapping and remapping a surface by either destroying the xdg_surface or
> attaching a NULL buffer should be indistinguishable. No "hidden state",
> either accessible or inaccessible to the app (such as stacking order,
> window position, or user-added hints or settings) should leak through an
> unmap/map cycle, if such wording hasn't been added already.
> 
> On Sun, Jul 16, 2017 at 11:32 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote:
> > > (Coming into this one late)
> > >
> > > When I first wrote xdg-shell, I maintained that attaching a NULL buffer
> > > should be illegal since it has no benefit compared to destroying the
> > > surface, but compositors might not reset all data attached to the
> > surface,
> > > making a weird exception where clients depend on bugs where state isn't
> > > always reset. And the "resetting of all data" might seem like strange
> > > behavior to clients.
> > >
> > > Has this rationale changed?
> >
> > Pretty much. It was never specified anywhere so implementations
> > differed (weston and mutter implemented it like that but not sure
> > anyone else did), it contradicted some wording in wayland.xml and it was
> > a behaviour disliked by some, thus a middle ground was reached that
> > clearly defines it as no state should be kept. I intend to try to make
> > sure at least libweston-desktop and mutter respects this fully.
> >
> >
> > Jonas
> >
> > >
> > > On Tue, Jul 11, 2017 at 8:11 PM, David Edmundson <davidedmundson at kde.org
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > >> The idea is that having unmapped by null-attach means the
> > > >> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
> > > >> had when first created, thus to map again, one would do what one would
> > > >> do the same as when mapping it for the first time: set up the state
> > > >> (set_title, (set_maximized?), set_app_id), commit, wait for configure,
> > > >> then attach a new buffer given the configure event data.
> > > >>
> > > >>
> > > >> Thanks, I'd totally forgotten the commit as I was only looking in this
> > > > interface.
> > > > It's clear now.
> > > >
> > > > David
> > > >
> > > > _______________________________________________
> > > > wayland-devel mailing list
> > > > wayland-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > >
> > > >
> > >
> > >
> > > --
> > >   Jasper
> >
> 
> 
> 
> -- 
>   Jasper