Cela ressemble à un cas pour un script AppRun personnalisé ?

Cela ressemble à un cas pour un script AppRun personnalisé ?

Je suis désolé, je ne comprends pas. Pouvez-vous expliquer un peu?

Avec #335 fusionné, ceci :

créer un dossier de départ portable à utiliser comme $HOME

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

créer un dossier de configuration portable à utiliser comme $XDG_CONFIG_HOME

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

et ça:

"Erreur lors de l'enregistrement des signets" "Système de fichiers en lecture seule" à la sortie

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

n'est plus nécessaire (je croise les doigts :) )

Je suis désolé, je ne comprends pas. Pouvez-vous expliquer un peu?

D'après ce que vous avez écrit, il semble que l'utilisateur doive exporter certaines variables d'environnement pour que cela fonctionne. Ce que je voulais signaler, c'est AppRun , un fichier à l'intérieur de l'AppImage que vous pouvez utiliser pour écrire votre propre script, qui exporterait les variables d'environnement nécessaires.

Faites-moi savoir si vous êtes coincé et avez besoin d'une aide concrète.

Avec #335 fusionné, ceci :

créer un dossier de départ portable à utiliser comme $HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
créer un dossier de configuration portable à utiliser comme $XDG_CONFIG_HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config

et ça:

"Erreur lors de l'enregistrement des signets" "Système de fichiers en lecture seule" à la sortie
$ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config

n'est plus nécessaire (je croise les doigts :) )

Veuillez noter:

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

n'ont rien à voir avec des problèmes ou des erreurs, au contraire, ils offrent la possibilité de stocker des configurations et autres non pas sous $HOME/, $HOME/.config, $HOME/.local, mais sous les répertoires portables mentionnés ci-dessus.

Désolé, alors j'ai mal compris. En fait, c'est vraiment aussi simple que ces 3 étapes :

Tutoriel comment exécuter l'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

Ici, il fonctionne sur Xubuntu 18.04 :

__Super !__ :+1:

Je suis désolé, je ne comprends pas. Pouvez-vous expliquer un peu?

D'après ce que vous avez écrit, il semble que l'utilisateur doive exporter certaines variables d'environnement pour que cela fonctionne. Ce que je voulais signaler, c'est AppRun , un fichier à l'intérieur de l'AppImage que vous pouvez utiliser pour écrire votre propre script, qui exporterait les variables d'environnement nécessaires.

Faites-moi savoir si vous êtes coincé et avez besoin d'une aide concrète.

Ce serait certainement un avantage de nettoyer https://build.opensuse.org/project/show/OBS :AppImage, d'installer de nouvelles versions et de corriger les builds insolubles/failed/broken existants.
Mais il y en a d'autres en charge, je vais probablement faire une entrée de bogue.
J'ai également remarqué qu'AppImageUpdate ne fonctionne pas correctement avec les AppImages générées par OBS - mais je dois y regarder de plus près.

Le truc avec libmurrine.so est ennuyeux, oui, mais nous devons attendre d'autres tests des utilisateurs sur autant de plateformes que possible.

n'ont rien à voir avec des problèmes ou des erreurs, au contraire, ils offrent la possibilité de stocker des configurations et autres non pas sous $HOME/, $HOME/.config, $HOME/.local, mais sous les répertoires portables mentionnés ci-dessus.

Il semble que vous ayez raison, car, comme je le vois, si vous ne créez pas explicitement ces répertoires, l'image d'application utilise par défaut $HOME, etc.

Mais franchement, --appimage-portable-config n'est requis que pour ceux qui n'ont pas par défaut $XDG_CONFIG_HOME . Et appimage n'a pas les moyens de redéfinir $XDG_DATA_HOME .

J'ai essayé avec deux outils de mise à jour différents et aucun n'a pu le mettre à jour correctement :

https://github.com/AppImage/AppImageUpdate

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

Ce message est en fait très utile @antony-jr. Nous pouvons voir:

me<strong i="15">@host</strong>:~$ 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<strong i="16">@host</strong>:~$ 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]

Il semble donc qu'il y ait un bogue dans https://download.opensuse.org qui le fait rediriger vers http plutôt que vers https. Cela fonctionnait; donc je soupçonne qu'il s'agit d'un bug qui a été récemment introduit.

cc @AdrianSchroeter

appimage n'a pas les moyens de redéfinir $XDG_DATA_HOME

Pensez-vous que nous devrions l'ajouter?

J'ai essayé avec deux outils de mise à jour différents et aucun n'a pu le mettre à jour correctement :

https://github.com/AppImage/AppImageUpdate

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

oui, je pensais à quelque chose comme ça, merci pour le test.

Pour celestia, AppImageUpdate serait très avantageux, vous n'avez donc pas besoin de télécharger l'intégralité du package avec chaque version.

Pour celestia, AppImageUpdate serait très avantageux, vous n'avez donc pas besoin de télécharger l'intégralité du package avec chaque version.

En effet! :+1:

appimage n'a pas les moyens de redéfinir $XDG_DATA_HOME

Pensez-vous que nous devrions l'ajouter?

Cela me semble logique.

Seriez-vous intéressé par un programme de mise à jour dans l'application ? Il existe un plugin Qt qui peut le faire. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

Seriez-vous intéressé par un programme de mise à jour dans l'application ? Il existe un plugin Qt qui peut le faire. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

Cela semble intéressant. Je vais regarder de plus près.

@munix9 faites-moi savoir si vous souhaitez intégrer le programme de mise à jour dans votre application. Vous pouvez également utiliser https://antony-jr.github.io/AppImageUpdaterBridge qui peut être utilisé comme bibliothèque ou comme plugin Qt pour effectuer la mise à jour automatique. Il est entièrement écrit en Qt et respecte la boucle événementielle.

PS : updatedeployqt est toujours en alpha et il subit une opération à cœur ouvert chaque semaine donc je ne suis pas très confiant pour vous le recommander.

@ munix9 Si vous voulez voir comment fonctionne la mise à jour, voyez comment qtox l'utilise -> https://github.com/qTox/qTox-nightly-releases/releases

Après l'avoir téléchargé, ajoutez des données parasites pour déclencher une mise à jour,

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

allez dans les paramètres -> à propos -> mise à jour disponible (le bouton apparaîtra après un certain temps)

Pour info : j'ai utilisé https://github.com/antony-jr/updatedeployqt pour tester l'option de mise à jour (la balise "1", la balise "continue" ne semble pas fonctionner pour le moment).
Je pense que c'est un moyen rapide et facile d'essayer une fonctionnalité de mise à jour intégrée - le code n'a pas besoin d'être modifié - sauf pour attribuer un nom QObject au menu d'aide.
AppImageUpdaterBridge semble être une alternative intéressante - voyons ce que l'avenir nous réserve.

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

à l'exception de l'attribution d'un nom QObject pour le menu d'aide.

Vous pouvez également essayer de faire correspondre la sous-chaîne de tous les objets QMenu ou QAction dans le programme.

EDIT : Je n'ai pas ajouté de documentation car je n'ai vraiment pas le temps (mais je suis très excité) et l'outil est encore en alpha donc des changements majeurs sont encore à venir.

@ munix9 Le programme de mise à jour fonctionne très bien de mon côté. :+1:

à l'exception de l'attribution d'un nom QObject pour le menu d'aide.

Vous pouvez également essayer de faire correspondre la sous-chaîne de tous les objets QMenu ou QAction dans le programme.

EDIT : Je n'ai pas ajouté de documentation car je n'ai vraiment pas le temps (mais je suis très excité) et l'outil est encore en alpha donc des changements majeurs sont encore à venir.

@ munix9 Le programme de mise à jour fonctionne très bien de mon côté. +1

Une chose qui pourrait être mieux résolue :
Si une mise à jour est disponible, le nouveau fichier reçoit le nom par exemple

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

Cela rend les répertoires existants

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

obsolètes car ils ne sont pas automatiquement renommés.

Y a-t-il une solution pour cela?

Une chose qui pourrait être mieux résolue :
Si une mise à jour est disponible, le nouveau fichier reçoit le nom par exemple

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

@munix9 En fait, le programme de mise à jour ne le renomme que s'il existe un fichier avec le nom de fichier cible, dans le programme de mise à jour officiel, l'ancien fichier est déplacé avec l'extension .zs_old mais j'ai décidé de ne pas toucher à l'ancienne version et de laisser les utilisateurs le gérer. Nous pouvons cependant ajouter une option pour supprimer l'ancien fichier lorsque ce conflit se produit, ou nous pouvons le renommer comme le fait le programme de mise à jour officiel.

De plus, si nous continuons à déplacer l'ancienne version avec l'extension .zs_old , les autres versions de ce type seront perdues à jamais. Au cas où l'AppImage utilise le même nom pour chaque version, comme dans votre cas.

Tout d'abord, un seul des éléments suivants doit être utilisé :

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

Normalement, les applications portables sont censées conserver leur configuration par version, de sorte qu'un utilisateur puisse exécuter plusieurs versions de la même application en parallèle sans qu'elles n'interfèrent les unes avec les autres. Si vous souhaitez que différentes versions de l'application partagent le même ensemble de configuration, vous pouvez, dans le cadre d'un AppRun , faire quelque chose comme (pseudo-code non testé) :

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

Ensuite, il utilisera celestia.home s'il est là, indépendamment du nom de fichier de l'AppImage.

Est-ce que ça a du sens?

Oui, AppImage.home devrait suffire.
J'avais déjà envisagé et testé une adaptation dans l'AppRun.
Peut-être avec une solution de repli, si un version-AppImage.home n'existe pas pour la version actuelle, utilisez le général AppImage.home s'il est disponible - similaire à ce que vous suggérez.
Cela pourrait avoir du sens.
Voyons s'il y a des retours révélateurs des utilisateurs.

Bonjour,
peut-on mettre les addons ? et si oui, dans quel répertoire ?
Merci

@Amich-26 Celestia 1.7 lit ~/.celestia.cfg s'il existe.
Dans le fichier, vous pouvez ajouter ExtrasDirectories avec des répertoires avec des addons :

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

Veuillez noter que tous les répertoires doivent être répertoriés, pas seulement un autre.

En fait @munix9 ajoute un patch pour celestia.cfg , vous pouvez donc utiliser ~/.celestia pour mettre des addons.

Il est également possible d'extraire les données embarquées dans l'AppImage :
./celestia-1.7.0-git-x86_64.AppImage --celestia-extract-data

Les modules complémentaires peuvent ensuite être placés dans le dossier créé puis démarrés à l'aide de CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage .

Voir aussi ./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.

Merci ! Ça marche.