7 votes

Sauvegarder l'état des applications ouvertes et des onglets dans un fichier et pouvoir le restaurer

J'ai deux ordinateurs sur lesquels sont installées les mêmes applications et je les utilise tous les deux pour mon travail. Je voudrais passer de l'un à l'autre de manière transparente et recréer l'état des applications ouvertes que j'avais dans la précédente avec une commande .

Je me suis penché sur une application appelée Maestro du clavier mais il ne semble pas être en mesure de sauvegarder les applications et les onglets ouverts de manière arbitraire, il faut plutôt créer des macros spécifiques.

Avec AppleScript, je peux peut-être utiliser une liste d'applications ouvertes :

osascript -e 'tell application "System Events" to get name of every process where visible is true'

Mais je ne suis pas sûr de savoir où aller à partir de là, ni même si c'est possible.

Je devrais peut-être plutôt m'intéresser aux sessions des utilisateurs. Quelqu'un a suggéré que je devrais synchroniser ~/Library/Preferences/ByHost/com.apple.loginwindow.* sur les deux ordinateurs, mais je ne suis pas sûr que cela suffise, et cela m'oblige à me déconnecter et à me reconnecter, ce que je ne veux pas.

Avez-vous des indications sur la manière d'y parvenir ?

Portée

Le fait de ne pas pouvoir "recharger à chaud" les programmes n'est pas un problème. La position des fenêtres n'en est pas un non plus. Si, d'une simple pression sur un bouton, je pouvais tout fermer et ouvrir des applications à partir d'un fichier d'état enregistré, ce serait suffisant. Le problème est surtout que les applications ouvrent les fichiers que j'avais ouverts sur l'autre ordinateur. Si je pouvais avoir plus d'un état sauvegardé (par exemple, un par projet), ce serait excellent. Si je peux obtenir un code initial, je pourrai le développer à partir de là.

3voto

OnePablo Points 1

NOTE : Réponse encore en construction...

Encore une section à écrire, détaillant les scripts qui vont synchroniser l'état de fonctionnement des applications. Je dois d'abord écrire ces scripts.


L'objectif

En gros, il s'agit de concevoir un moyen permettant à deux Mac de sauvegarder et de partager des informations sur l'environnement de l'utilisateur, notamment les états et propriétés des applications, les documents chargés et les applications en cours d'exécution. .

Votre demande initiale était de se déplacer sans problème d'une [machine] à l'autre et recréer l'état des applications ouvertes que j'avais dans la précédente avec une commande. Depuis, vous avez un peu relâché vos attentes et précisé que le "rechargement à chaud" des applications n'est pas recherché, et que les détails tels que la taille et la position des fenêtres ne sont pas une préoccupation.

Méthodologie conceptuelle

1. Deux scripts + un fichier de données partagé

Mon idée initiale était d'avoir une copie d'un script (probablement un AppleScript) sur chaque machine qui aurait un gestionnaire chargé d'obtenir des informations sur les environnements d'application et de les stocker dans un fichier partagé auquel les deux machines auraient accès (par exemple par le biais de Dropbox , iCloud , ...). Le script aurait un gestionnaire séparé qui récupérerait le contenu de ce fichier partagé, et appliquerait les paramètres à l'environnement local. Cela nécessiterait que l'utilisateur exécute le script une fois en arrivant sur une machine afin d'appliquer les paramètres ; et une fois juste avant de quitter la machine afin de mettre à jour le fichier de données partagé avec les nouveaux paramètres.

2. .savedState synchronisation

Ma deuxième idée a été inspirée par l'idée d'une autre personne de synchroniser le fichier situé à l'adresse suivante ~/Library/Preferences/ByHost/com.apple.loginwindow.* . Bien que cela ne soit pas utile, cela soulève la question de savoir si la synchronisation .savedState fichiers trouvés dans le dossier ~/Library/Saved Application State serait la solution.

Certes, je ne peux pas prétendre connaître toutes les conséquences d'une tentative de synchronisation de ces fichiers sur deux systèmes différents. Cela ne veut pas dire que quelque chose de mauvais arriverait, mais c'est un territoire inconnu, donc le potentiel pour des résultats indésirables est là. Cependant, j'ai le sentiment que ce serait en grande partie sans danger, et probablement assez inoffensif, étant donné que, si quelque chose devait mal tourner à cause d'un mauvais .savedState la solution consiste presque toujours à supprimer le fichier .savedState et permettre à l'application en question d'en générer un nouveau.

Je pense qu'une combinaison de ces deux méthodes sera nécessaire.

Synchronisation

Synchronisation de la ~/ dossier via Dropbox

La synchronisation du dossier personnel ne vous permettrait probablement que de rendre les documents disponibles sur chaque machine, mais ne vous permettrait peut-être pas de synchroniser le dossier de l'utilisateur. ~/Library si son emplacement ne peut être modifié. En outre, ce dossier a une taille de 26 Go sur mon système, ce qui impliquerait de payer un abonnement pour un espace de stockage supplémentaire dans le nuage.

En fin de compte, si la synchronisation du dossier personnel se limite à Downloads , Documents , Music et Movies il n'y a pas beaucoup d'avantages par rapport au fait d'avoir la Documents y Desktop dossiers synchronisés par iCloud .

Cependant, la synchronisation des documents est une bonne idée, car il est important d'avoir accès aux mêmes fichiers sur les deux ordinateurs et que les modifications apportées à l'un soient répercutées sur l'autre. iCloud bien qu'assez lent, est parfait pour ce travail.

Synchronisation de la ~/Library dossier

Le site ~/Library ou, du moins, des sous-dossiers spécifiques de ce dossier, est un objectif crucial si l'on envisage d'utiliser le dossier .savedState pour mettre en correspondance les états des applications d'un système à l'autre. Une solution de stockage en nuage à domicile serait idéale pour cette tâche, car elle ne prélève pas de frais d'abonnement ; vos données sensibles seraient en sécurité en votre possession et n'appartiendraient pas à Dropbox o Apple Et il n'y a pas de limitation de vitesse en dehors de celle imposée par votre fournisseur d'accès à Internet en cas de synchronisation sur Internet.

J'utilise déjà Resilio Sync Ce logiciel est gratuit pour un usage individuel et utilise les transferts peer-to-peer pour synchroniser les dossiers sélectionnés entre les machines ou les appareils sur lesquels vous installez l'application. Il suffirait de sélectionner le ~/Library ou le dossier ~/Library/Saved Application State à surveiller et à synchroniser en temps réel. Les dossiers peuvent rester en l'état, et si vous choisissez de payer pour des fonctionnalités supplémentaires (paiement unique), vous pouvez synchroniser de manière sélective des fichiers individuels dans un dossier, et les crypter pour la sécurité des données. Je recommande vraiment cette application, qui semble idéale pour cette situation spécifique.

Scripting

Si la synchronisation de la .savedState est réussie, ce qui pourrait être nécessaire est un script pour ouvrir (ou rouvrir) les applications qui étaient en cours d'exécution sur l'autre machine. La réouverture permettra, avec un peu de chance, à l'application de lire ses fichiers mis à jour. .savedState et reproduire l'état dans lequel il était sur l'autre système. Je pense que cela aura un succès partiel, mais peut-être pas total.

Récupération d'une liste d'applications en cours d'exécution

C'est plus difficile qu'il n'y paraît, car il existe plusieurs façons de vérifier si une application fonctionne, et aucun test n'est parfait. Il y a les applications au premier plan qui sont visibles avec Windows ; il y a les applications de la barre de menu, certaines sans Windows, qui s'exécutent en arrière-plan ; et il pourrait y avoir des applications cachées réduites dans le dock, sans Windows visible.

Après avoir expérimenté quelques méthodes différentes dans AppleScript, cette ligne de code semble produire une bonne liste exhaustive des applications en cours d'exécution, y compris les applications de la barre de menu :

    tell application "System Events" to set OpenApps to the ¬
        name of every application process whose ¬
        class of its menu bar contains menu bar and ¬
        POSIX path of the application file does not start with "/System" and ¬
        POSIX path of the application file does not start with "/Library"

Il faut quelques secondes pour renvoyer un résultat, mais je ne pense pas que cette rapidité aura trop d'importance si les scripts sont implémentés de manière judicieuse.

Une méthode Bash pour obtenir une liste des applications en cours est la suivante :

    IFS=$'\r\n'; basename $( \
    egrep -i -e '^/Applications/.*\.app/Contents/MacOS/[^/]+$' \
    <<<"$(ps -U 501 -o 'comm')" ) | sort -u

Il est rapide (instantané), mais il lui manque quelques applications dans la barre de menu et en arrière-plan.

Je pense que l'une ou l'autre de ces méthodes conviendra finalement pour ce qui est nécessaire, car les applications les plus importantes à capturer sont celles avec lesquelles vous interagissez au premier plan, et celles-là sont capturées par la plupart des méthodes.

Stockage des informations dans un fichier de paramètres partagé

L'écriture des paramètres qui doivent être sauvegardés peut se faire sur une .plist qui stocke paires clé/valeur de données ainsi que les types de données. Cela permet d'enregistrer et de retrouver n'importe quelle valeur par son nom. Ils sont également relativement simples à lire et à modifier par programme à l'aide d'AppleScript ou de l'utilitaire de ligne de commande. plutil .

Supposons que le fichier de paramètres partagés soit enregistré à l'adresse suivante ~/Example/savedState.plist~/Example/ est une sorte de dossier partagé (par exemple, un dossier de stockage en nuage) auquel les deux ordinateurs ont accès.

En utilisant AppleScript, voici comment on peut enregistrer une liste d'applications actuellement ouvertes :

    property plist : "~/Example/SavedState.plist"

    tell application "System Events"
        if not (the file plist exists) then make new property list file ¬
            with properties {name:plist}

        set plistf to the property list file named plist

        tell plistf to make new property list item with properties ¬
            {name:"OpenApps", kind:list, value:OpenApps}
    end tell

où la variable OpenApps est tiré de l'extrait d'AppleScript ci-dessus. Astucieusement, le make new property list La commande écraser tout élément clé/valeur existant qui porte déjà ce nom. "OpenApps" afin qu'elle ne soit pas dupliquée.

Ensuite, nous avons besoin d'un moyen de quitter les applications sur un système :

    to kill(A as list, X as list)
        local A, X

        if A = {} then return

        script jury
            property A0 : item 1 of A
            property An : rest of A
            property OK : A0 is not in X
        end script

        tell the jury
            ignoring application responses
                if its OK then quit the application named (its A0)
                kill(its An, X)
            end ignoring
        end tell
    end kill

Il s'agit d'un gestionnaire récursif qui reçoit une liste d'applications à quitter (paramètre A ) et une liste d'applications qui doivent être exclues (paramètre X ). Il parcourt ensuite les listes une par une et vérifie que l'application ne fait pas partie de celles qui figurent dans la liste suivante X avant de le quitter et de passer au reste de la liste.

Réouverture de documents

En utilisant l'utilisation de la synchronisation .savedState L'espoir est que, lorsqu'une application se réinitialise sur un système (par exemple, en la fermant et en l'ouvrant à nouveau), elle rouvre les documents qui étaient ouverts sur l'autre système.

Toutefois, il peut être prudent de conserver notre propre liste de documents dont nous pouvons détecter (au mieux de nos capacités) qu'ils sont ouverts et actifs.


[NOTES À INTÉGRER DANS LA RÉPONSE]

  • J'ai remarqué que certains .savedState sont stockés dans ~/Library/Saved Application State comme pseudonymes (liens symboliques) au lieu du fichier lui-même. Ceux-ci sont généralement liés à ~/Library/Containers/%bundle-id%/Data/Library/Saved Application State/%file%%bundle-id% est, par exemple, com.apple.Preview et son correspondant %file% est com.apple.Preview.savedState .

Cela signifie que ~/Library/Containers devra probablement aussi être synchronisée entre les deux machines.

  • .savedState sont supprimés lorsqu'une application se termine proprement. Par conséquent, gardez à l'esprit que la fermeture des applications sur un système supprimera ces fichiers de données, puis synchronisera potentiellement ces suppressions avec l'autre machine.

1voto

Matt Sephton Points 4570

Auparavant (avant Sierra), vous pouviez avoir des répertoires personnels portables, stockés sur le réseau, qui permettaient d'utiliser facilement plusieurs machines avec le même profil utilisateur. Bien sûr, cela fonctionnait mieux pour les profils d'utilisateurs qui ne contenaient pas des centaines de gigaoctets de données. Les performances de cette approche sur un réseau local câblé étaient très bonnes, certains endroits où j'ai travaillé l'utilisaient pour permettre le hot-desking.

La seule chose de ce type encore prise en charge sont les comptes mobiles. https://support.apple.com/kb/ph25671

Sinon, vous pouvez utiliser iCloud Drive pour synchroniser ~/Desktop y ~/Documents , et tous les dossiers supplémentaires dont vous avez besoin .

Vous pouvez également envisager de stocker votre dossier d'accueil dans le nuage en utilisant les services suivants csync , Dropbox ou autre. https://www.amsys.co.uk/using-cloud-storage-sync-home-folder-macs/

Tous ces systèmes nécessitent l'utilisation d'un seul ordinateur à la fois, ce qui ne convient peut-être pas ?

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X