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

Jan-Marek Glogowski glogow at fbihome.de
Sun Jul 7 14:27:54 UTC 2019


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


More information about the wayland-devel mailing list