Klingt nach einem Fall für ein benutzerdefiniertes AppRun-Skript?

Klingt nach einem Fall für ein benutzerdefiniertes AppRun-Skript?

Es tut mir leid, ich verstehe nicht. Könntest du ein bisschen erklären?

Mit #335 zusammengeführt, dies:

Erstellen Sie einen tragbaren Home-Ordner, um ihn als $HOME . zu verwenden

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

Erstellen Sie einen portablen Konfigurationsordner zur Verwendung als $XDG_CONFIG_HOME

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

und das:

"Fehler beim Speichern von Lesezeichen" "Schreibgeschütztes Dateisystem" beim Beenden

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

wird nicht mehr benötigt (Daumen drücken :) )

Es tut mir leid, ich verstehe nicht. Könntest du ein bisschen erklären?

Nach dem, was Sie geschrieben haben, muss der Benutzer bestimmte Umgebungsvariablen exportieren, damit dies funktioniert. Worauf ich hinweisen wollte, ist AppRun , eine Datei im AppImage, mit der Sie Ihr eigenes Skript schreiben können, das die erforderlichen Umgebungsvariablen exportiert.

Lassen Sie mich wissen, wenn Sie nicht weiterkommen und konkrete Hilfe benötigen.

Mit #335 zusammengeführt, dies:

Erstellen Sie einen tragbaren Home-Ordner, um ihn als $HOME . zu verwenden
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
Erstellen Sie einen portablen Konfigurationsordner zur Verwendung als $XDG_CONFIG_HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config

und das:

"Fehler beim Speichern von Lesezeichen" "Schreibgeschütztes Dateisystem" beim Beenden
$ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config

wird nicht mehr benötigt (Daumen drücken :) )

Bitte beachten Sie:

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

haben nichts mit Problemen oder Fehlern zu tun, im Gegenteil, sie bieten die Möglichkeit, Konfigurationen und dergleichen nicht unter $HOME/, $HOME/.config, $HOME/.local, sondern unter den oben genannten portablen Verzeichnissen zu speichern.

Entschuldigung, dann habe ich mich falsch verstanden. Tatsächlich ist es wirklich so einfach wie diese 3 Schritte:

Tutorial zum Ausführen des 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

Hier läuft es auf Xubuntu 18.04:

__Super!__ :+1:

Es tut mir leid, ich verstehe nicht. Könntest du ein bisschen erklären?

Nach dem, was Sie geschrieben haben, muss der Benutzer bestimmte Umgebungsvariablen exportieren, damit dies funktioniert. Worauf ich hinweisen wollte, ist AppRun , eine Datei im AppImage, mit der Sie Ihr eigenes Skript schreiben können, das die erforderlichen Umgebungsvariablen exportiert.

Lassen Sie mich wissen, wenn Sie nicht weiterkommen und konkrete Hilfe benötigen.

Es wäre sicherlich von Vorteil, https://build.opensuse.org/project/show/OBS :AppImage zu bereinigen, neue Versionen zu installieren und die vorhandenen nicht auflösbaren/failed/broken Builds zu reparieren.
Aber es gibt andere, die dafür verantwortlich sind, ich werde wahrscheinlich einen Fehlereintrag machen.
Mir ist auch aufgefallen, dass AppImageUpdate mit den von OBS generierten AppImages nicht richtig funktioniert - aber das muss ich mir genauer ansehen.

Die Sache mit libmurrine.so ist zwar ärgerlich, aber wir sollten auf möglichst vielen Plattformen weitere Tests der Nutzer abwarten.

haben nichts mit Problemen oder Fehlern zu tun, im Gegenteil, sie bieten die Möglichkeit, Konfigurationen und dergleichen nicht unter $HOME/, $HOME/.config, $HOME/.local, sondern unter den oben genannten portablen Verzeichnissen zu speichern.

Scheint, dass Sie Recht haben, denn wie ich sehe, verwenden Sie, wenn Sie diese Verzeichnisse appimage nicht explizit erstellen, die Standardeinstellung $HOME usw.

Aber ehrlich gesagt ist --appimage-portable-config nur für diejenigen erforderlich, die nicht standardmäßig $XDG_CONFIG_HOME . Und appimage kann $XDG_DATA_HOME nicht neu definieren.

Ich habe es mit zwei verschiedenen Updater-Tools versucht und keines konnte es richtig aktualisieren:

https://github.com/AppImage/AppImageUpdate

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

Diese Nachricht ist eigentlich sehr hilfreich @antony-jr. Wir sehen:

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]

Es scheint also einen Fehler in https://download.opensuse.org zu geben , der dazu führt, dass auf http statt auf https umgeleitet wird. Das hat früher funktioniert; Daher vermute ich, dass es sich um einen kürzlich eingeführten Fehler handelt.

cc @AdrianSchroeter

appimage kann $XDG_DATA_HOME nicht neu definieren

Meinst du, wir sollten es hinzufügen?

Ich habe es mit zwei verschiedenen Updater-Tools versucht und keines konnte es richtig aktualisieren:

https://github.com/AppImage/AppImageUpdate

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

Ja, so ähnlich habe ich mir gedacht, danke fürs Testen.

Für celestia wäre AppImageUpdate sehr vorteilhaft, damit man nicht bei jedem Build das ganze Paket herunterladen muss.

Für celestia wäre AppImageUpdate sehr vorteilhaft, damit man nicht bei jedem Build das ganze Paket herunterladen muss.

In der Tat! :+1:

appimage kann $XDG_DATA_HOME nicht neu definieren

Meinst du, wir sollten es hinzufügen?

Das klingt für mich logisch.

Wären Sie daran interessiert, einen Updater in der Anwendung zu haben? Es gibt ein Qt-Plugin, das dies kann. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

Wären Sie daran interessiert, einen Updater in der Anwendung zu haben? Es gibt ein Qt-Plugin, das dies kann. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr

Das hört sich interessant an. Ich werde genauer hinschauen.

@munix9 lassen Sie es mich wissen, wenn Sie den Updater in Ihre Anwendung integrieren möchten. Sie können auch https://antony-jr.github.io/AppImageUpdaterBridge verwenden, das als Bibliothek oder als Qt-Plugin verwendet werden kann, um die Selbstaktualisierung durchzuführen. Es ist vollständig in Qt geschrieben und respektiert die Ereignisschleife.

PS : updatedeployqt befindet sich noch in der Alpha-Phase und wird jede Woche am offenen Herzen operiert, daher bin ich nicht sehr zuversichtlich, es Ihnen zu empfehlen.

@munix9 Wenn Sie sehen möchten, wie das Update funktioniert, sehen Sie, wie qtox es verwendet -> https://github.com/qTox/qTox-nightly-releases/releases

Fügen Sie nach dem Herunterladen einige Mülldaten hinzu, um ein Update auszulösen.

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

gehe zu Einstellungen -> Info -> Update verfügbar (Schaltfläche erscheint nach einiger Zeit)

Zu Ihrer Information: Ich habe https://github.com/antony-jr/updatedeployqt verwendet , um die Update-Option zu testen (das "1"-Tag, das "continuous"-Tag scheint im Moment nicht zu funktionieren).
Ich denke, es ist eine schnelle und einfache Möglichkeit, eine integrierte Update-Funktionalität auszuprobieren - der Code muss nicht geändert werden - außer der Zuweisung eines QObject-Namens für das Hilfemenü.
AppImageUpdaterBridge scheint eine interessante Alternative zu sein - mal sehen, was die Zukunft bringt.

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

mit Ausnahme der Zuweisung eines QObject-Namens für das Hilfemenü.

Sie können auch versuchen, die Teilzeichenfolge aller QMenu-Objekte oder QAction-Objekte im Programm abzugleichen.

BEARBEITEN : Ich habe keine Dokumentation hinzugefügt, da ich wirklich keine Zeit habe (aber ich bin sehr aufgeregt) und das Tool noch in der Alpha-Phase ist, so dass noch große Änderungen anstehen.

@munix9 Der Updater funktioniert auf meiner Seite hervorragend. :+1:

mit Ausnahme der Zuweisung eines QObject-Namens für das Hilfemenü.

Sie können auch versuchen, die Teilzeichenfolge aller QMenu-Objekte oder QAction-Objekte im Programm abzugleichen.

BEARBEITEN : Ich habe keine Dokumentation hinzugefügt, da ich wirklich keine Zeit habe (aber ich bin sehr aufgeregt) und das Tool noch in der Alpha-Phase ist, so dass noch große Änderungen anstehen.

@munix9 Der Updater funktioniert auf meiner Seite hervorragend. +1

Eine Sache, die vielleicht besser gelöst werden könnte:
Wenn ein Update verfügbar ist, erhält die neue Datei den Namen zB

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

Dadurch werden die vorhandenen Verzeichnisse

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

veraltet, da sie nicht automatisch umbenannt werden.

Gibt es dafür eine Lösung?

Eine Sache, die vielleicht besser gelöst werden könnte:
Wenn ein Update verfügbar ist, erhält die neue Datei den Namen zB

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

@munix9 Eigentlich benennt der Updater es nur um, wenn eine Datei mit dem Zieldateinamen existiert, im offiziellen Updater wird die alte Datei mit der Erweiterung .zs_old verschoben, aber ich habe mich entschieden, die alte Version nicht anzufassen und die Benutzer zu lassen damit umgehen. Wir können jedoch eine Option zum Löschen der alten Datei hinzufügen, wenn dieser Konflikt auftritt, oder wir können sie wie beim offiziellen Updater umbenennen.

Auch wenn wir alte Versionen mit der Erweiterung .zs_old , gehen andere solche Versionen für immer verloren. Falls das AppImage für jede Version denselben Namen verwendet wie in Ihrem Fall.

Zunächst sollte nur EINER der folgenden Punkte verwendet werden:

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

Normalerweise sollen portable Anwendungen ihre Konfiguration pro Version beibehalten, so dass ein Benutzer mehrere Versionen derselben Anwendung gleichzeitig ausführen kann, ohne dass sie sich gegenseitig stören. Wenn Sie möchten, dass verschiedene Versionen der Anwendung denselben Konfigurationssatz verwenden, können Sie als Teil eines benutzerdefinierten AppRun Folgendes tun (ungetesteter Pseudocode):

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

Dann wird celestia.home wenn es vorhanden ist, unabhängig vom Dateinamen des AppImage.

Macht das Sinn?

Ja, AppImage.home sollte ausreichen.
Eine Anpassung im AppRun hatte ich mir schon überlegt und getestet.
Vielleicht mit einem Fallback, wenn ein version-AppImage.home für die aktuelle Version nicht existiert, dann verwenden Sie das allgemeine AppImage.home falls verfügbar - ähnlich wie Sie es vorschlagen.
Dies kann sinnvoll sein.
Mal sehen, ob es aufschlussreiches Feedback von den Benutzern gibt.

Hallo,
Können wir die Addons installieren? und wenn ja, in welchem ​​verzeichnis?
Dankeschön

@Amich-26 Celestia 1.7 liest ~/.celestia.cfg wenn es existiert.
In der Datei können Sie ExtrasDirectories mit Verzeichnissen mit Addons hinzufügen:

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

Bitte beachten Sie, dass alle Verzeichnisse aufgeführt werden müssen, nicht nur ein zusätzliches.

Tatsächlich fügt @munix9 einen Patch für celestia.cfg , sodass Sie ~/.celestia , um Addons zu installieren.

Es ist auch möglich, die eingebetteten Daten im AppImage zu extrahieren:
./celestia-1.7.0-git-x86_64.AppImage --celestia-extract-data

Addons können dann in dem erstellten Ordner abgelegt und dann mit CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage gestartet werden.

Siehe auch ./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.

Danke schön ! Es klappt.