[REQUEST] Indicator for flatpak, AppImage, Regular (pkgmgr) apps

[erdnuesse]

Before opening a feature request

• I checked the next branch to see if the feature has already been implemented
• I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

First, I have no idea how to check other branches. I am no sw-dev, don't want to become one, but regularly post issues, FRs, etc. If you want me to do so, tell me how.

for drun:
Indicate what app-type is a specific entry. like a if grep flatpak in a folder tree results in true, display a flatpak indicator, be it a string or an icon.
If you have installed via package manager and flatpak, maybe to test, maybe with separate accounts in each app version, you almost always want to know which version to launch, when they otherwise look exactly the same in the app list.

How do you know that this problem exists today? Why is this important?

I have / had multiple instances of chromium, firefox, even discord for testing, but they all look the same in the menu, never knowing which entry is the flatpak.

Who will benefit from it?

Everyone, using the same app more than once ie. as flatpak + from their repos on the same system, for whatever reason.

Rofi version (rofi -v)

Version: 1.7.5+wayland3-51-g0a0cc5f6

Configuration

https://gist.github.com/erdnuesse/8dd9e2dc18f852a7664c360827d85573

Additional information

No response

[DaveDavenport]

Is there a way to detect this?

[erdnuesse]

where the launcher would look for .desktop files should be configured somewhere right?

1. all apps in
   /var/lib/flatpak/exports/share/applications/
   should be flatpaks, no?
   so you could regex the path of the .desktop file for ^.flatpak.$, but that could be too broad, if a user has a homedir, where an appimage or any binary is, and the user could be named flatpak, for whatever reason, so maybe
   ^\/var\/lib/flatpak\/.*$
   for the path could be more precise.

2. the .desktop files in /var/lib/flatpak/exports/share/applications/... that drun (I expect?) use to show the available apps contain the exec command for launch:
   Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=com.yourapp.YourappIsHere
   hence i.e. a regex filter based on
   ^(?i)exec=.*\/usr\/bin\/flatpak.*$
   would be a flatpak app.

however, different systems, and flatpak environments (user installation, system wide installation) may be too complex for approach 1, because too many variables to check for.
if the exec attribute inside the desktop runner would run a flatpak binary in /usr/bin, this could be good enough to scan for.

an AppImage should be named "AppXYZ.AppImage" IIRC, so, there would be a unique identifier for an appimage as well.

[DaveDavenport]

So the system (via XDG) tells rofi what directories to scan for desktop files. I did not see a 'standardized' way to check this.
Parsing the exec string feels a bit like a hack, I wonder if there is a better system to do this? Is there an extra flag set in the desktop file by flatpack/appimage?

I see flatpack (installed an app to test) has a X-Flatpak= entry we could check. Is this debian only? or on every system?

[erdnuesse]

So the system (via XDG) tells rofi what directories to scan for desktop files.

Maybe depending on the locations XDG tells rofi to categorize them?

Parsing the exec string feels a bit like a hack, I wonder if there is a better system to do this?

I understand, I'd feel the same way. Wait until you see my workaround though...
However, how does rofi get the icons then? Maybe a similar approach is worth exploring?

Is there an extra flag set in the desktop file by flatpack/appimage?

They don't specify a current standard in their docs
Or upstream

I see flatpack (installed an app to test) has a X-Flatpak= entry we could check. Is this debian only? or on every system?

I would strongly discourage from using that. The .desktop entry will still function when I delete those optional entries. However, currently, I have those entries as well (arch-derivative, btw).
The only entry inside the desktop file that makes it 100% certain, is if the flatpak binary gets called.

For now, I have dealt with it like so:

#!/bin/bash
for file in /var/lib/flatpak/exports/share/applications/*.desktop; do
  while IFS= read -r line; do
    if [[ $line =~ ^Name=.*flatpak ]]; then
      # First Line occurence with "Name=" contains "flatpak", skip to next file
      break
    fi
    if [[ $line =~ ^Name= ]]; then
      # Line starts with "Name=", append "(flatpak)"
      sed -i "s/^$line/$line (flatpak)/" "$file"
      break
    fi
  done < "$file"
done

(Reasoning: I trust the location of those files to be flatpak launchers only. You should not assume clean systems for everyone. A user comes about the idea to move all application launchers in that folder? Your identification system should still work; I could modify the script to check for the Exec=flatpak bin first, but why bother, not my use case; to any other user; feel free to modify the script to encompass that. ... or just see below, I guess)
YMMV, use foreign code with caution.

(solves it for me with both rofi and fzf, so, I just need to rund this after each flatpak update... well, here goes my flatpak install and upgrade script I guess)

I guess that's all I could help you with for now, it's pretty much a design decision / which paradigms to follow, and I can't contribute anything more than this.
Best,
K

Well, exec-safe modification of your .desktop files for renaming the App name to App (flatpak); sponsored by AI, not (just) me:

#!/bin/bash
for file in /var/lib/flatpak/exports/share/applications/*.desktop; do
  flatpak_found=false
  name_line=""
  while IFS= read -r line; do
    if [[ $line =~ ^Exec=\/usr\/bin\/flatpak ]]; then
      flatpak_found=true
      break
    fi
    if [[ $line =~ ^Name= ]]; then
      name_line="$line"
      break  # Break after finding the first Name= line
    fi
  done < "$file"
  if $flatpak_found; then
    sed -i "s/^$name_line/$name_line (flatpak)/" "$file"
  fi
done

Plus: unintentional - but welcome - side-effect:
typing "flatpak" gives me all flatpak apps quickly without needing to use CLI, as I do not have / use a graphical software installer, so it has a nice quick display for me : )

[DaveDavenport]

What might be 'nicer for your script' is to create the 'updated' flatpack desktop into ~/.local/share/applications/ this has higher priority then the system ones, so those should show.. this way you can run this as user, not root and you do not modify system files.

[erdnuesse]

I appreciate the idea. [Edits for removing redundancies and readability]
However, I would argue that that would greatly depend on how you install your flatpaks (user vs system installation). If you want to go that far OT - Regardless which of the two ways you want to approach it; I would also advise again, not mixing up the two.

I don't want to be a contrarian here, but in my view the holistic approach for your flatpak strategy should dictate how you want to implement a "fix".

User-only
If you want to edit the .desktop files for your user only, you should install your flatpaks for your current user only, aka user-based flatpak app-installations, and in that case you already know which files you want to edit, most likely the ones in the folder you listed.

System-wide
If you work in multi-user scenarios on your machine, and system-wide flatpak installations, you probably want to propagate the change across users, then you probably want to use the .desktop files in the folder I used.