I’ve started to play around with hyprland, a rather minimalistic window compositor. To launch apps the default way is with wofi, but I’ve opted for bemenu. Both run apps from the binary system path.
The problem is that some apps aren’t in the system path, for example Avidemux, Shotcut or Extreme Tuxracer. One way I’ve found to launch them in hyprland is via the gnome-software app: I navigate to their site and click on open. Rather cumbersome and slow, because it seems just navigating to their site involves downloading content from the internet.
Another way I’ve found is to launch them via flatpak run. Of course, this only works for apps installed via flatpak. Extreme Tuxracer for example is installed via dnf. It’s also rather cumbersome, because the app has to be named in some url like format, e.g.:
flatpak run org.avidemux.Avidemux
In gnome of course this is very convenient: the apps are all there behind the 9 dot button in the dock. My question is: can I run this 9 dot overlay when in a different window manager, not gnome?
Or alternatively, is their another standalone app launcher, that does not simply scan the binary path, but present me with all the entries in the gnome 9 dot overlay?
Not quite, it looks for an executable, not a package. To quote the man page:
DESCRIPTION
Which takes one or more arguments. For each of its arguments it prints
to stdout the full path of the executables that would have been executed
when this argument had been entered at the shell prompt. It does this by
searching for an executable or script in the directories listed in the
environment variable PATH using the same algorithm as bash(1).
For which to be useful, you need to know the name of the executable that you are looking for. And if you already know the name of the binary, you can directly type the binary name into wofi or bemenu and they should search for it in the PATH, no need for which.
You can get the list of all files in an RPM package with dnf repoquery and then deduce the name of the binary from that (look for the files in /usr/bin or the .desktop ones):
❯ dnf repoquery -l extremetuxracer
Updating and loading repositories:
Repositories loaded.
/usr/bin/etr # <- this is the binary we need
/usr/bin/etr-wrapper # <- or possibly this? Maybe check the .desktop file below
/usr/lib/.build-id
/usr/lib/.build-id/57
/usr/lib/.build-id/57/a89d29a420f47aef42618142f51e06b8c82a82
/usr/lib/.build-id/65
/usr/lib/.build-id/65/24222246ca17aaba52b73c2776aa13f83ddb3a
/usr/share/appdata/etr.appdata.xml
/usr/share/applications/etr.desktop # <- this should have the full executable path
/usr/share/applications/net.sourceforge.extremetuxracer.desktop
/usr/share/doc/extremetuxracer/TODO
[...]
IMO, the main issue the OP experienced is that the names of the binaries not necessarily correspond to the applications (‘Extreme Tux Racer’ → etr). DEs like Gnome or KDE solve this by searching through the .desktop files that most GUI applications install and then presenting a list of results to the user to select one and then running this. AFAIK this is also what ulauncher does. But without this convenience functionality, you need to launch applications by their executable name.