AppImage

Portable configuration data

I though the same thing and that’s why I created LinuxPA. If you go into setting and enable common.sh it will run before the program, so you can set things such as HOME (which the default common.sh does).

https://github.com/AppImage/AppImageKit/commit/d17fdefadcb98befa66c29137ce25731256f8f2a implements the following:

  • If there is a directory with the same name as the AppImage plus .home, then export $HOME.
  • If there is a directory with the same name as the AppImage plus .config, then export $XDG_CONFIG_HOME.

All new AppImages generated with the latest continuous build of appimagetool will have this functionality.

Depending on how well this works in practice, it may become part of the spec.

Example on how to use this.

Imagine you want to use the Leafpad text editor, but carry its settings around with the executable.

You can do the following:

# Download Leafpad AppImage and make it executable
wget -c "https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage" -O Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
chmod a+x Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage

# Create a directory with the same name as the AppImage plus the ".config" extension
# in the same directory as the AppImage
mkdir Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config

# Run Leafpad, change some setting (e.g., change the default font size)
# then close Leafpad
./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage

# Now, check where the settings were written:
linux@linux:~> find Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config
(...)
Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config/leafpad/leafpadrc

Note that the file leafpadrc was written in the directory we have created before.

Hello probono,

i have follow the same step for firefox appimage.
Created Firefox-54.0.glibc2.3.4-x86_64.AppImage.config directory for Firefox-54.0.glibc2.3.4-x86_64.AppImage .
Make changes to settings in the firefox.
close it.
i don’t see any new data been saved in Firefox-54.0.glibc2.3.4-x86_64.AppImage.config directory .

please enlighten me on where are the data been saved to?

How do i make sure my data are store along with appimage in the same directory?

This AppImage does not have this functionality yet. It was introduced in a later version of AppImageKit.

First quit all currently running instances of Firefox:

killall firefox

Then download the AppImage from https://bintray.com/probono/AppImages/Firefox/56.0.2.glibc2.3.4#files

mkdir Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home
./Firefox-56.0.2.glibc2.3.4-x86_64.AppImage

After running the AppImage, you can inspect the contents of Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home and you will see stuff has been saved there:

me@host:~/Downloads$ find Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/ | head -n 10
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/Desktop
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/fontconfig
(...)
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/fontconfig/CACHEDIR.TAG
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/mozilla
(...)

See this asciicinema for a live demo:

https://asciinema.org/a/SGKGaxZ99Gf3tOsdrlZICpDLz

probono: ok

thank you.

This use case should be shown in the README.md in GitHub.

Moreover, have you thought about extending this approach?
Think of the following use case, we have a software which supports Plug In’s.
It expects the Plug In’s to be in a certain location which is not ~/ related.
So could we have something like AppData folder next to the AppImage which can be configured to be copied to somewhere to allow Plug In’s functionality?

Really like the Portable Data Feature.
I think this is your edge over FlatPak and Snap (Allowing Portable Use Case).

All needed now it Portable AppImage which is a Menu System to launch other AppImages (Think like the PortableApps Menu which is a portable application by itself, no system wide installation).

Added.

This is probably something specific to the application in question that should best be implemented either within the application itself, or by writing a custom AppRun launcher. Every application probably needs some environment variable to be set in order to load plugins from custom locations. Actually I would assume that most will (also) load plugins from somewhere within $HOME, so the .home feature (described above) that is already available might be sufficient in many cases.

@probono,
Do you expect that TeXStudio will download MiKTeX to .home?
Let’s sya I use both TeXMaker and TeXStudio, should I expect each to download MiKTeX?

There should be a well defined way to have AppImage format auxiliary data.

Again, have a look on PortableApss approach for that.

No, if TeXStudio requires MiKTeX to work properly, then I expect a TeXStudio.AppImage to contain MiKTeX. Because an AppImage is supposed to run without the user needing to download anything else besides the AppImage.

But in most cases Minimal TeXLive won’t cut it.
So you suggest user who use both TeXMaker and TeXStudio and needs extra packages to have 2 ~4 GB programs.

Yea, great user experience.
Not to mention the chances the TeXMaker / TeXStudio maintainers to have such a mess as a choice.

Really, those design choices only makes FlatPak / Snap look much more reasonable.

Flatpak and Snap allow dependencies. We discourage them. But hey, in the end it’s up to whoever makes the TeXMaker/TeXStudio AppImage to decide what goes inside and what doesn’t. Unlike Flatpak and Snap we don’t enforce things. We just provide the tools. AppImage does not restrict them from doing what they want to do. The developer of an AppImage can do what they want. An AppImage is just a self-mounting filesystem image (“disk image”) that runs what someone puts inside.

I tried the suggested solution to save appimage application settings in the same folder, by creating folder with the same name and extension .config or .home, but none of them worked. The folders are empty.

I also tried to change the home directory of appimage application by launching it with the command export HOME=/path/to/data/folder ./xxxx.appimage but also it didn’t worked. I get bash export not a valid identifier.

Hi @emil_9822, which AppImage? Try running the AppImage with --appimage-portable-home .

For more information, please see https://github.com/AppImage/AppImageKit/issues/539.

Please open an issue in https://github.com/AppImage/AppImageKit/ if it does not work with any AppImage.

hi @probono – thanks for all your work.

Right now, Cisco are developing WebEx support for Linux.

I’ve tried to make the argument for AppImage, but joe follows on up-voting availability on his particular distro and says +1 for fedora and sue says +1 for redhat and alex says +1 for CentOS.

After years, Cisco relents and commits to develop WebEx desktop client for Linux

@dawnstar raised the issue of removable media and file shares. We use thin clients. For every app I have to write a launcher that looks for the AppImage (or un-tarballed bundle) on USB and on file share.

While preservation of user configs, perhaps balanced by the need to have test configs – the focus of your discussion is important, it isn’t as important to me as the need to stop home thrashing. (I could also add stop home ballooning – I’ll come to that).

So, many of my launchers do re-define $HOME to /tmp/$USER.

Configs in $HOME isn’t (from my POV) the problem; it’s heavily volatile files that are heavily written-to. Apart from becoming the limiting factor to the responsiveness of the apps, is $HOME is on flash, thrashing flash trashes flash. (Yes, I have those databases that Mozilla thunderbird email and firefox browser, ditto Chrome, in mind).

AppImage simplifies app updating since no (re)installation is required.

It remains problematic if app developers insist on implementing in-app updates to $HOME (sometimes bypassing redefinition by consulting the password file). If Zoom or whoever put out some enormous electron update and within a day or two you’ve got tens, hundreds or potentially thousands of copies in user homes, that’s to be a bigger fish to fry.

Precisely. We want AppImages to be read-only by design. An “update” is, in fact, downloading the new version without throwing away the old version, so that the user can decide to delete the old one only after they have confirmed the new one works for them.

Precisely and a convention for naming AppImages with their version number would help. I’ve run-out of fingers to count the number of times I’ve had to launch an AppImage and find my way to the About to work-out where the stored AppImage version stands in relation to one seen published out there.

ApplicationName_1.0.0_x86_64.AppImage is the naming convention.