In #4946 I've been confused by our handling of app_id.
The weirdest thing about this is that we hold the original app_id internally as application_id and "resolve" it everywhere the ID is sent, not just once in the place where it is set.
But it is also unclear what the existing logic is intended to achieve: one might expect it to "clean the input" and resolve to the basename of the application's .desktop file (see the protocol specification quoted below).
But, in many cases, the resolve logic returns a desktop file id NOT the basename of the application's desktop file. (The desktop file id is related to, but distinct from the basename.) In other cases it returns the basename, or the original app_id.
The reason we're doing this is that applications can use set_app_id for multiple things that may or may not correspond to the "recommendation" in the protocol definition:
Set an application identifier for the surface.
The app ID identifies the general class of applications to which
the surface belongs. The compositor can use this to group multiple
surfaces together, or to determine how to launch a new application.
For D-Bus activatable applications, the app ID is used as the D-Bus
service name.
The compositor shell will try to group application surfaces together
by their app ID. As a best practice, it is suggested to select app
ID's that match the basename of the application's .desktop file.
For example, "org.freedesktop.FooViewer" where the .desktop file is
"org.freedesktop.FooViewer.desktop".
Like other properties, a set_app_id request can be sent after the
xdg_toplevel has been mapped to update the property.
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.
[0] https://standards.freedesktop.org/desktop-entry-spec/
In #4946 I've been confused by our handling of app_id.
The weirdest thing about this is that we hold the original app_id internally as
application_idand "resolve" it everywhere the ID is sent, not just once in the place where it is set.But it is also unclear what the existing logic is intended to achieve: one might expect it to "clean the input" and resolve to the basename of the application's .desktop file (see the protocol specification quoted below).
But, in many cases, the resolve logic returns a desktop file id NOT the basename of the application's desktop file. (The desktop file id is related to, but distinct from the basename.) In other cases it returns the basename, or the original app_id.
The reason we're doing this is that applications can use
set_app_idfor multiple things that may or may not correspond to the "recommendation" in the protocol definition: