foreign-toplevel: Send PID

[AdrianVovk]

The wrl-foreign-toplevel protocol does not give panel clients a PID, so it is really just a guess based on the app-id to decide if a window comes from a given application or not. The problem with this is that applications don't do the right thing™ and send really odd things.

For example: LibreOffice's paste dialog does not have the same app-id as the LibreOffice window itself (Writer's id: org.libreoffice, paste dialog id: soffice). They should, however, have the same PID, and my panel should be able to notice this and group them under one icon.

[ddevault]

Send patch?

[emersion]

The PID might not be enough, clients (like waypipe) can open completely unrelated windows from the same process. Also, in case of apps running in namespaces, the PID will be bogus.

Can you have a look and see how other compositors fix the issue? I believe the parent-child relationship is enough.

[AdrianVovk]

Hmm, these are all good points.

I looked into it closer. Here's how GNOME handles it: https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/src/shell-window-tracker.c#L365-453

On my OS, all of the misbehaving windows are Flatpaks, so I would just need support for get_app_from_sandboxed_app_id, and I'm not sure if there needs to be an extension to the protocol for this or if I can get @ammen99 to just send me the right data via the app_id property itself in Wayfire. The GNOME guys say that it is canonical, and that is certainly the case (apps lie; Flatpak doesn't).

The way flatpak app_ids work is by having the pid of the window and reading /proc/$PID/root/.flatpak-info. So, either this should be done in the compositor (and I just get the right app_id), or I can get the PID via this proto and do it myself in my panel.

[ammen99]

I would say this is rather a bug in the program (LibreOffice in this case). Isn't app-id supposed to be the same for all xdg-toplevels of a certain program?

[AdrianVovk]

@ammen99 Well there isn't much we can do about the proprietary programs, so the next best thing is to deal w/ the flatpak app id and parent/child relationship

These apps don't know they are running in a flatpak do they send what their app_id should have been.

Now that I'm thinking about this a bit more, I'd probably prefer to just get the PID so I can take care of Flatpak myself. I can probably apply the same method to org.freedesktop.Notifications to get the proper app_id there too (and get the sender PID from DBus), and duplicating code isn't necessary

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/57