[PATCH] xdg-shell: add use case to handle change of app_id

[Simon Ser]

On Friday, July 12, 2019 6:27 PM, Jonas Ådahl <jadahl at redhat.com> wrote:
> On Sun, Jul 07, 2019 at 04:27:54PM +0200, Jan-Marek Glogowski wrote:
>
> > Am 07.07.19 um 16:11 schrieb Simon Ser:
> >
> > > > @@ -604,6 +604,11 @@
> > > > For example, "org.freedesktop.FooViewer" where the .desktop file is
> > > > "org.freedesktop.FooViewer.desktop".
> > > >
> > > > -   This request can be used to change the icon of a window at runtime by
> > > > -   providing different desktop files and changing the app_id.
> > >
> > > I'm not sure this change is necessary. Nothing says this request can't be sent
> > > after the toplevel has been setup. Other requests don't explicitly specify they
> > > can be sent after setup.
> >
> > It's just that I was told by multiple people "app_id maps to WM_CLASS, so should
> > be considered static". And IMHO it's uncommon / unexpected to change the app_id,
> > so I wanted to mention this use case explicitly so Wayland implementors will be
> > aware of it.
> >
> > > > Windows of
> > > >
> > > > -   the same app_id will still be grouped together, as they are expected
> > > > -   to represent the same application from the users point of view.
> > >
> > > This should be left out, because this is compositor policy. Some compositors
> > > don't group by app_id.
> >
> > My intention was to express, that if you change the app_id to change the icon,
> > don't expect that the previous grouping will persist. This is obvious, and from
> > LO POV I want the document windows grouped by type, eventually, so I'm fine
> > skipping it. The compositor may do whatever it want based on the app_id, but LO
> > will be able to offer the correct grouping "hint".
>
> I think it's fine to mention that it may change, and elaborate more
> verbosely in the commit message about the LibreOffice use case, but I
> don't think it should mention anything about icons, grouping and what
> not since, as Simon said, that is compositor policy and not relevant
> here.

Maybe say that it may change "just like other xdg_toplevel properties"
so that people don't assume that only properties that explicitly
mention that they are mutable can change.