Avoid redundancies in the app menu caused by synchronized flatpak apps

[nastaziya]

The problem you're addressing (if any)

I'm currently working on a post install script(such as the dnf hook) that would synchronize the app menu with newly installed flatpak apps and eventually mention the app source "(Flatpak)" in the app name, whenever a Flatpak app is added.

However, having the same app installed twice, either through flatpak only (per-user and system-wide) or with flatpak and from any other source, can cause apps to be redundant in the app menu after synchronization. It would be better to avoid this confusion by specifying the app source.

Describe the solution you'd like

One solution would be to append "(Flatpak)" to the app name in desktop files every time a flatpak app is installed. Eventually, I admit that appending (Flatpak user)/(Flatpak system) is a foolproof solution to distinguish all apps having the same name.

Where is the value to a user, and who might that user be? Better end-user experience.

Describe alternatives you've considered

Appending « Flatpak sys/user » only if there is the same application from any other source already installed.

However, it’s a solution that would involve a template based app vm to be supervised while being in the TemplateVm, giving to this one the awareness of all newly installed apps and vice versa. Only this way, the post install script could add/remove “Flatpak” specification to/from the concerned app name. But, as long as this alternative requires an eventual Vm's interaction, almost unacceptable in Qubes OS, i'd rather be against.

[marmarek]

I think the place for such processing is in qubes.GetAppmenus script. Right now the desktop file processing is an awk script looking at one desktop file at the time only, but it's ok to make it more elaborate, including changing awk to something else and check whether there are duplicates at this level.

On the other hand, I think there should be only one instance of given application in the final menu, even if multiple instances are available (VM settings - applications tab). This means it's more important to distinguish applications in that settings window than in the final menu. This allows to use also other fields of desktop file (comment, genericname etc) and perhaps adding them as a tooltip to the application selection dialog (which is a good idea anyway).

Please also remember that .desktop files needs to be unique, even if they are in different directories. If you have same named desktop file in different directories, it will be visible as one (AFAIR the one listed later by qubes.GetAppmenus prevails). I think this is ok, as long as it is really the same application - which is the case for system and user installed flatpak.

[fepitre]

@marmarta : do you think that would something you could parse easily? For example, we think about adding (Flatpak/System) or (Flatpak/User) at the end of the Comment field. Else, there is a possibility of using Keywords field.

[marmarta]

Sounds fine; I think I'm just going to add to qvm-appmenus an option to list selected fields from the .desktop files, and then show as tooltip the contents of the Comment field.

[marmarek]

For the record: here is specification of the file format, with list of available fields: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys

[marmarta]

Okay, I added it (pull requests pending ofc); I think just adding it to the 'Comment' field and displaying that in Settings is best - I think it's important mostly in the Settings, once the user sets their Apps like they want it doesn't matter where are they from.

[nastaziya]

@marmarta Thanks for working on this issue. At this point, my flatpak sync service works well, except after a dnf update/install/remove that refreshes the app menu excluding flatpak apps. It seeams to happen because of the XDG_DATA_DIRS that has None value in the dnf hook and takes default "/usr/local/share:/usr/share" in the qubes.GetAppmenus script, omitting flatpak paths. So @marmarek , @fepitre , @marmarta , i wonder if there is an appropriate way to add flatpak paths to XDG_DATA_DIRS and change this behavior?

[marmarek]

One idea would be to source /etc/profile.d/qubes-session.sh in qubes.GetAppmenus, which will include environment from user session. Loading relevant flatpak file from /etc/profile.d or even the whole /etc/profile may not be enough, as it could look for "user" flatpaks of root, not user.

[nastaziya]

@marmarek @fepitre Actually, my service is designed to monitor and sync from system flatpak path in TemplateVm and user path in AppVm. So, the best case scenario is to sync apps in TemplateVm only from sys path /var/lib/flatpak . Sourcing /etc/profile.d/qubes-session.sh would be a good idea, but causes user flatpak apps sync in TemplateVM, if somehow there's an app installed in user path(action to be avoided). In consequence, the AppVm appmenu will be populated with "ghost" icons. For the moment, i think, we can source /etc/profile.d/qubes-session.sh and explain how flatpak is supposed to be used in the "flatpak-helper" package readme.