101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

486
active users

#appimage

0 posts0 participants0 posts today
Replied to Roni Laukkarinen

@rolle the #OpenPandora has it's own image format like #AppImage called PND. For the successor there is DBP... nevertheless PND works like a charm; download an image to one of the default application folders and it gets automatically integrated in the menu, to the desktop... I wish someone would adopt this workflow to other platforms.

Some stuff to read about PND and how it works: pandorawiki.org/Introduction_t

pandorawiki.orgIntroduction to PNDs - Pandora Wiki

AppImage is a frustrating invention for Linux. It should work like macOS's .app, but it falls short. Getting an app to run and dock always involves tinkering and manually deploying a .desktop item, among other hassles.

I wish I had known about Gear Lever for Gnome earlier. omgubuntu.co.uk/2024/07/gear-l

Gear Lever makes updating AppImage apps much easier. I prefer .deb packages, but too many apps don't offer them.

Source code: github.com/mijorus/gearlever

Oh boy ...

I switched @novelwriter to Qt6 on the recent 2.7 release, and that has caused sooo many problems with the AppImage.

I spent 7-8 hours yesterday trying to fix things, but AppImages are horrible to work with when you can't just use one of the standard tools that does everything for you.

... and now I hate AppImages.

#Coding#Python#Qt
Replied in thread

@forteller #AppImage support is still done on a per-distro basis, and it really isn't much more than setting permission and executing certain environment variables... I think.

But mayhaps this is a job for ... #FREEDESKTOP

Hello. I'm free desktop... gief money,
We craves it, WE NEEDS IT!!

But yeah, maybe xdg-open should handle that problem. Then distros wouldn't need to do anything to get first rate AppImage support by removing those annoyances.

One can only hope.

When it comes to #Linux and packages for the user, #Flatpak for when you need shared dependencies and #AppImage for when you need a portable app. Basically we've already solved both the "app store" and "downloadable executable" problems.

Snaps could compete, if it supported third party repos OOB and wasn't a vendor lock-in situation, but if and buts were candies and nuts...

Flatpaks, Snaps, & AppImages: "Do we really need these Universal App For...
youtube.com/watch?v=so_f6OtRWR

youtube.com- YouTubeEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

It seems AppImage has been gaining traction as the (sometimes only) distribution format of choice. I use multiple AppImages so to avoid having to manually run them, I set up `appimaged` that handles integration of the packages into the desktop automatically (creating app icons for them etc).
I noticed though that it fires a network request looking for registered app updates every two minutes as part of an auto-update functionality which I don't really need.

Another thing is that it monitors multiple directories for AppImages (so it can do its thing setting them up), but it also watches `~/Downloads` and `~/Desktop` which feels like overkill - an app can get registered even before I put it into its final location, plus the content in both of these locations could be numerous and frequently change, which doesn't seem ideal from a performance perspective when monitoring.

To address these, I forked the repository and applied a few changes to `appimaged`:
- Added an in-source flag to disable AppImage update checks, with the nice side effect of reducing the size of the resulting binary.
- Implemented another flag so that a reduced directory set is watched by default for AppImages, removing Downloads and Desktop (and also system-level directories like `/opt`, which might not be for everyone). It's easy to change though. Also de-duplicated this directory list because all the $PATH items are added to it too.

If you're interested in running this version, I set the main branch of my repo to the one containing these changes. Building is straightforward: `scripts/build.sh appimaged`. It only needs Go, the rest is handled via the container-style build script, cleaning up after itself.

github.com/shiide/go-appimage

GitHubGitHub - shiide/go-appimage: Go implementation of AppImage toolsGo implementation of AppImage tools. Contribute to shiide/go-appimage development by creating an account on GitHub.
Replied in thread

@lunkki #Tuta-tili on nyt luotu. Uutta sähköpostia en tosin olisi tarvinnut, oma osoitteeni on ollut jo parikymmentä vuotta webhotellissa (joka on pariin kertaan vaihtunut).

Tuta tarjoaa sovelluksen #Android'iin ja jonkinlaisen (#AppImage'na pyörivän) myös #Linux'iin. Jälkimmäinen arveluttaa, mutta kokeillaan. Kytkemisestä käytössä oleviin ohjelmiin (#KMail, #Kontact tai vaikka #Vivaldi) ei ilmeisesti kannata uneksia.