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

Submitted by Jan-Marek Glogowski on July 7, 2019, 1:38 p.m.

Details

Message ID 20190707133824.1675-2-glogow@fbihome.de
State Superseded
Headers show
Series "xdg-shell: use case to change the app ID at runtime" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Jan-Marek Glogowski July 7, 2019, 1:38 p.m.
LibreOffice is one big binary with explicit brandings for different
application modules. This is represented by different WM_CLASS
settings for a window on X11, based on the loaded document. As a
result LibreOfiice already offers multiple desktop files with
different icons and StartupWMClass entries.

This amendment of the set_app_id request just explicitly specifies
this use case to change a windows app_id on runtime to change icon
and grouping of a window as used by LibreOffice.
---
 stable/xdg-shell/xdg-shell.xml | 5 +++++
 1 file changed, 5 insertions(+)

Patch hide | download patch | download mbox

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 2e420c6..fd3670f 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -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. 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.
+
 	See the desktop-entry specification [0] for more details on
 	application identifiers and how they relate to well-known D-Bus
 	names and .desktop files.

Comments

> LibreOffice is one big binary with explicit brandings for different
> application modules. This is represented by different WM_CLASS
> settings for a window on X11, based on the loaded document. As a
> result LibreOfiice already offers multiple desktop files with
> different icons and StartupWMClass entries.
>
> This amendment of the set_app_id request just explicitly specifies
> this use case to change a windows app_id on runtime to change icon
> and grouping of a window as used by LibreOffice.
> ---
>  stable/xdg-shell/xdg-shell.xml | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index 2e420c6..fd3670f 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -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.

> 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.

>  	See the desktop-entry specification [0] for more details on
>  	application identifiers and how they relate to well-known D-Bus
>  	names and .desktop files.
> --
> 2.20.1
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
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".
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.


Jonas

> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Friday, July 12, 2019 6:27 PM, Jonas Ã…dahl <jadahl@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.