[v2] xdg-shell: use case to change the app ID at runtime

Submitted by Jan-Marek Glogowski on July 12, 2019, 4:36 p.m.

Details

Message ID 20190712163630.14298-1-glogow@fbihome.de
State Superseded
Headers show

Not browsing as part of any series.

Commit Message

Jan-Marek Glogowski July 12, 2019, 4:36 p.m.
From: Jan-Marek Glogowski <glogow@fbihome.de>

LibreOffice is one big binary with explicit brandings for different
application modules. This is represented in X11 by a different
WM_CLASS setting for a window. The WM_CLASS is changed based on the
loaded document at runtime. As a result LibreOfiice already offers
multiple desktop files with different icons, StartupWMClass
entries and application names.

This amendment of the set_app_id request just explicitly specifies
the use case to change a surfaces' app ID at runtime, so a compositor
implementor is made aware of it. Just as the WM_CLASS, a change of
the app ID should result in an update of the propertes of a surface
depending on the app ID, like the window icon specified in the
desktop file or a re-grouping of the surfaces in a task manager.
---
 stable/xdg-shell/xdg-shell.xml | 4 ++++
 1 file changed, 4 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..145b39e 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -604,6 +604,10 @@ 
 	For example, "org.freedesktop.FooViewer" where the .desktop file is
 	"org.freedesktop.FooViewer.desktop".
 
+	The request can be used to change the app ID of a surface at runtime,
+	which should be handled by a compositor by updating the grouping and
+	other properties depending on the 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.

Comments

I'd just go with something among the lines of:

    Like other properties, an app_id request can be sent after the
    toplevel has been mapped to update the property.
Am 12.07.19 um 20:31 schrieb Simon Ser:
> I'd just go with something among the lines of:
> 
>     Like other properties, an app_id request can be sent after the
>     toplevel has been mapped to update the property.

s/an app_id/a set_app_id/
s/toplevel/xdg_toplevel/

Or is toplevel implicit xdg_toplevel?

For X11 there are some properties, which would just be effective after unmap +
map. For example Qt requires to hide and show a window, if you change the
modality of a dialog. I would like to have something like "should be handled" as
wording, but I don't know if this is considered too strict (it's should not
must, but I'm not used to writing specs this way).