Sounds like a case for a custom AppRun script?

Sounds like a case for a custom AppRun script?

I'm sorry, i don't get. Could you explain a little bit?

With #335 merged, this:

create a portable home folder to use as $HOME

$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home

create a portable config folder to use as $XDG_CONFIG_HOME

$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config

and this:

"Error Saving Bookmarks" "Read-only file system" on exit

$ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config

is not required any more (crossing my fingers :) )

I'm sorry, i don't get. Could you explain a little bit?

From what you wrote it seems like the user has to export certain environment variables in order to make this work. What I wanted to point to is AppRun, a file inside the AppImage which you can use to write your own script, that would export the needed environment variables.

Let me know if you are stuck and need concrete help.

With #335 merged, this:

create a portable home folder to use as $HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
create a portable config folder to use as $XDG_CONFIG_HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config

and this:

"Error Saving Bookmarks" "Read-only file system" on exit
$ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config

is not required any more (crossing my fingers :) )

Please note:

$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config

have nothing to do with problems or errors, on the contrary, they offer the possibility to store configurations and the like not under $HOME/, $HOME/.config, $HOME/.local, but under the above mentioned portable directories.

Sorry, then I was misunderstanding. In fact it's really as simple as those 3 steps:

Tutorial how to run the AppImage

wget -c https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage # Download
chmod +x celestia-qt-latest-x86_64.AppImage # Make executable
./celestia-qt-latest-x86_64.AppImage # Run

Here it is running on Xubuntu 18.04:

__Awesome!__ :+1:

I'm sorry, i don't get. Could you explain a little bit?

From what you wrote it seems like the user has to export certain environment variables in order to make this work. What I wanted to point to is AppRun, a file inside the AppImage which you can use to write your own script, that would export the needed environment variables.

Let me know if you are stuck and need concrete help.

It would certainly be an advantage to clean up https://build.opensuse.org/project/show/OBS:AppImage, install new versions and fix the existing unresolvable/failed/broken builds.
But there are others in charge, I'll probably make a bug entry.
I've also noticed that AppImageUpdate doesn't work correctly with the AppImages generated by OBS - but I need to take a closer look at that.

The thing with libmurrine.so is annoying, yes, but we should wait for further tests of the users on as many platforms as possible.

have nothing to do with problems or errors, on the contrary, they offer the possibility to store configurations and the like not under $HOME/, $HOME/.config, $HOME/.local, but under the above mentioned portable directories.

Seems that you are correct, because as I see if you don't explicitly create those dirs appimage use default $HOME etc.

But frankly speaking --appimage-portable-config required only for those who has nondefault $XDG_CONFIG_HOME. And appimage doesn't have means to redefine $XDG_DATA_HOME.

I tried with two different updater tools and neither was able to update it correctly:

https://github.com/AppImage/AppImageUpdate

https://github.com/antony-jr/AppImageUpdater

This message is actually very helpful @antony-jr. We can see:

me@host:~$ strings Downloads/celestia-qt-0-Build160.1.glibc2.14-x86_64.AppImage | strings | grep zsync
zsync|https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync
(...)

me@host:~$ wget https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync

--2019-08-04 20:57:11--  https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync
(...)
HTTP request sent, awaiting response... 302 Found
Location: http://downloadcontent.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-0-Build160.1.glibc2.14-x86_64.AppImage.zsync [following]

So it seems like there is a bug in https://download.opensuse.org that makes it redirect to http rather than to https. This used to work; so I suspect it to be a bug that was recently introduced.

cc @AdrianSchroeter

appimage doesn't have means to redefine $XDG_DATA_HOME

Do you think we should add it?

I tried with two different updater tools and neither was able to update it correctly:

https://github.com/AppImage/AppImageUpdate

https://github.com/CelestiaProject/Celestia/issues/333#issuecomment-518027817

yep, I was thinking something like that, thanks for testing.

For celestia AppImageUpdate would be very advantageous, so you don't have to download the whole package with every build.

For celestia AppImageUpdate would be very advantageous, so you don't have to download the whole package with every build.

Indeed! :+1:

appimage doesn't have means to redefine $XDG_DATA_HOME

Do you think we should add it?

This sounds logical to me.

Would you be interested in having an updater inside the application? There is a Qt plugin that can do it. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

Would you be interested in having an updater inside the application? There is a Qt plugin that can do it. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

That sounds interesting. I'll take a closer look.

@munix9 let me know if you want to integrate the updater into your application. You can also use https://antony-jr.github.io/AppImageUpdaterBridge which can be used as a library or as a Qt plugin to do the self update. Its entirely written in Qt and respects the event loop.

PS: updatedeployqt is still in alpha and it gets a open heart surgery every week so I'm not very confident to recommend it to you.

@munix9 If you want to see how the update works, See how qtox uses it -> https://github.com/qTox/qTox-nightly-releases/releases

After downloading it, add some garbage data to trigger an update,

 $ echo "changes" >> qTox-*-x86_64.AppImage
 $ ./qTox-*-x86_64.AppImage

go to settings -> about -> update available (button will appear after some time)

FYI: I used https://github.com/antony-jr/updatedeployqt to test the update option (the "1" tag, the "continuous" tag doesn't seem to work at the moment).
I think it's a quick and easy way to try out an integrated update functionality - the code doesn't need to be changed - except for assigning a QObject name for the help menu.
AppImageUpdaterBridge seems to be an interesting alternative - let's see what the future holds.

https://github.com/munix9/Celestia/releases/tag/continuous
https://github.com/munix9/Celestia/blob/appimage_build/dist/appimage/fix-appimage_dir.patch#L43

except for assigning a QObject name for the help menu.

You can also try matching the substring of all QMenu objects or QAction objects in the program.

EDIT: I did not add any documentation since I really don't have the time(buf I'm very excited) and the tool is still in alpha so major changes are yet to come.

@munix9 The updater works great on my side. :+1:

except for assigning a QObject name for the help menu.

You can also try matching the substring of all QMenu objects or QAction objects in the program.

EDIT: I did not add any documentation since I really don't have the time(buf I'm very excited) and the tool is still in alpha so major changes are yet to come.

@munix9 The updater works great on my side. +1

A thing that might be better solved:
If an update is available, then the new file gets the name e.g.

celestia-qt-continuous-x86_64-revised-on-2019-08-29T10-57-48.AppImage

This makes the existing directories

celestia-qt-continuous-x86_64.AppImage.config
celestia-qt-continuous-x86_64.AppImage.home

obsolete because they are not automatically renamed.

Is there a solution for this?

A thing that might be better solved:
If an update is available, then the new file gets the name e.g.

celestia-qt-continuous-x86_64-revised-on-2019-08-29T10-57-48.AppImage

@munix9 Actually, the updater renames it only if a file with the target filename exists, in the official updater, the old file is moved with the extension .zs_old but I decided to not touch the old version and let the users handle it. We can however add a option to delete the old file when this conflict occurs, or we can rename it just like how the official updater does.

Also if we keep moving old version with the extension .zs_old, other such version will be lost forever. In case the AppImage uses the same name for every release like in your case.

First of all, only ONE of the following should be used:

celestia-qt-continuous-x86_64.AppImage.config
celestia-qt-continuous-x86_64.AppImage.home

Normally, portable applications are supposed to keep their configuration per-version, so that a user could run multiple versions of the same application alongside without them interfering with each other. If you want different versions of the application to share the same set of configuration, you could, as part of a custom AppRun, do something like (untested pseudo-code):

VERSIONLESSHOME=$(dirname "$APPIMAGE")/celestia.home
if [ -d  "$VERSIONLESSHOME" ] ; then
  export HOME=$VERSIONLESSHOME
fi

Then it will use celestia.home if it is there, independent of the filename of the AppImage.

Does this make sense?

Yes, AppImage.home should be sufficient.
I had already considered and tested an adaptation in the AppRun.
Maybe with a fallback, if a version-AppImage.home does not exist for the current version, then use the general AppImage.home if available - similar to what you suggest.
This might make sense.
Let's see if there's any revealing feedback from the users.

Hello,
can we put the addons? and if so, in which directory?
Thank you

@Amich-26 Celestia 1.7 reads ~/.celestia.cfg if it exists.
In the file you can add ExtrasDirectories with directories with addons:

{
ExtrasDirectories  [ "extras-standard" "extras" "~/celestia"]
}

Please note that all directories must be listed, not only an additional one.

Actually @munix9 adds a patch for celestia.cfg, so you can use ~/.celestia to put addons.

It is also possible to extract the embedded data in the AppImage:
./celestia-1.7.0-git-x86_64.AppImage --celestia-extract-data

Addons can then be placed in the folder created and then started using CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage.

See also ./celestia-1.7.0-git-x86_64.AppImage -h

Celestia 1.7.0~git - Real-time visual space simulation

Usage: ./celestia-1.7.0-git-x86_64.AppImage [OPTION]...
       CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage [OPTION]...

Celestia options:
  --conf <file>
    Alternate configuration file.
  --dir <dir>
    Alternate installation directory.
    The same can also be achieved with
    CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage
  --extrasdir <dir>
    Additional 'extras' directory.
  --fullscreen
    Start full-screen (not implemented yet).
  -l, --log <file>
    Copy console output into a file.
  -s, --nosplash
    Disable splash screen (not implemented yet).
  -u, --url <url>
    Start with the given URL (not implemented yet).
  --help
    Show celestia help (not implemented yet).

AppImage options:
  --celestia-fisheye
    Start celestia with fisheye projection (celestia-fisheye.cfg)
  --celestia-create-general-home
    Create a general home directory depending on the main version
    /tmp/celestia-1.7.home
  --celestia-extract-data
    Extract the embedded data in the directory
    /tmp/celestia-1.7.0-git-x86_64.AppImage.data
  -h, --celestia-help
    Show this help and exit.

thank you ! It works.