For example, I’m using Debian, and I think we could learn a thing or two from Mint about how to make it “friendlier” for new users. I often see Mint recommended to new users, but rarely Debian, which has a goal to be “the universal operating system”.
I also think we could learn website design from… looks at notes …everyone else.
All distros, or none: flatpak has to improve in regards to launching an app from terminal. Following is a joke:
flatpak run com.github.iwalton3.jellyfin-media-player
https://github.com/boredsquirrel/flatalias
Or my PR for that, that makes aliases on every login. I just have to fix it to work with user flatpaks as well: https://github.com/bjoern-tantau/flatalias/tree/patch-1
Why can’t the installation create aliases like
flatpak run jellyfin-media-player ? And then highlight conflicts during?
Ask the devs. I haven’t bothered asking so far. There’s fp https://github.com/DLopezJr/fp but I don’t like workaround if it’s easily fixed upstream and it’s not like they wouldn’t know that it’s bullshit. Maybe they can’t decide upon a solution. Or are waiting for another important and relevant update.
It would also be nice if it could alias to the normal command, for example, LibreOffice with CLI commands like lowriter or localc.
Did you know you can evoke LibreOffice from the terminal to convert one file format to another? It can do what Pandoc does, but also works on old .doc files. Flatpak’s weird CLI behavior makes it difficult to use though.
flatpak run com.github.iwalton3.jellyfin-media-player
You can use /var/lib/flatpak/exports/bin/com.github.iwalton3.jellyfin-media-player instead.
and then create aliases or symlinks (for example in ~/bin/) for that.
@lemmyreader @barbara it’s a bit annoying but I kinda like that I have to manually link it a bit. So I create sh scripts in the usr/local/bin that just execute the flatpak run command
This is extremely simple to fix with scripts that can be automatically created on install time. Here is a quick script I just wrote. It will search for first matching app and run it. Just save the script as flatrun, give it executable bit and put it into $PATH. Run it as like this: flatrun freetube
#!/usr/bin/env bash
# flatrun e
# flatrun freetube
if [ "${#}" -eq 0 ]; then
flatpak list --app --columns=name,application
else
app="$(
flatpak list --app --columns=name,application |
grep -i -F "${@}" |
awk -F'\t' '{print $2}'
)"
if [ -z "${app}" ]; then
flatpak list --app --columns=name,application
elif [[ "$(echo "${app}" | wc -l)" -gt 1 ]]; then
echo "${app}"
else
flatpak run "${app}"
fi
fi
Edit: Just updated the script to output the list of matching apps, if it matches more than one.
Yes and I did a similar script but “just create a script” is a really bad solution.
Apps should need to declare a shortname and flatpak should have a shortcut for those with a separated command like flatrun.
I personally don’t think that creating a script is a bad solution. The entire Linux eco system is based around composable components (especially when we talk about terminal commands). Most of the Flatpak applications are available through GUI menus (.desktop files) and that’s the focus of Flatpak. And I think it’s a design decision not to expose every application as a separate program in the $PATH by default. This way there is less of a chance to collide with anything random on the system, if they have the same name.
Having said this, I still agree it would be beneficial for most users if there was a way to automatically create scripts in a special bin folder, that is available in the $PATH. The problem is, what application name should it have? What about different versions of the same program? The entire Flatpak concept was not designed for this, so creating a script for your personal use is not a bad solution.
I think a good solution would to just have that script autogenerated by the flatpak, honestly.
It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.
However in the same way, compromised flatpak app can also put a malicious .desktop file in ~/.share/applications, which also allows execution of arbitrary command, even outside of the flatpak sandbox.
User home permission is just incredibly dangerous on linux, I think we need special permission to explicitly allow access to these folders in home. Fortunately more and more app starts to support portal, which makes them much more secure.
Although, I do wish portal would have a access per session vs access forever option. For now if you open a folder through portal, the app was granted r/w permission to that folder forever.
