Plusieurs installations de la même application ?

Vous pouvez le faire avec Reeder.

• Vous aurez besoin d'autant de comptes d'utilisateur que vous avez de comptes Google.
• Si vous avez deux comptes Google, vous pouvez évidemment utiliser votre compte Google principal comme utilisateur par défaut. Il suffit de cliquer sur Reeder à partir du lanceur ou du Dock et vous êtes prêt.
• Allez dans Préférences système, Utilisateurs et groupes, et créez un nouvel utilisateur. Appelez-le TestUser. Veillez à définir un mot de passe. Un compte utilisateur standard fera l'affaire.
• Terminal ouvert.
• exécutez ceci : echo "password" | sudo -S -u TestUser /Applications/Reeder.app/Contents/MacOS/Reeder &

voila ! Vous pouvez maintenant voir une deuxième fenêtre Reeder !

Créez un nouvel utilisateur de bureau pour chaque compte Google Reader différent. Vous pouvez ensuite utiliser la commutation rapide entre les comptes pour passer à l'utilisateur souhaité (une barre de menu est disponible à cet effet).

Vous pouvez également utiliser une commande shell pour lancer un processus sous le même gestionnaire de fenêtres depuis un autre utilisateur. Dites su other_user -c 'open /Applications/Reeder.app' . Je l'ai fait pour lancer des applications graphiques en tant que Root. J'ai joué avec l'ouverture de Chrome en utilisant cette approche, mais il semble que le trousseau ne soit pas initialisé correctement dans ce cas - il pourrait essayer de lire le trousseau de l'utilisateur hôte. Vous pouvez peut-être résoudre ce problème en vous connectant d'abord en tant qu'utilisateur, en créant le trousseau, puis en exécutant le script.

Addendum : Je ne suis pas sûr qu'un programme App Store se lancera en tant qu'autre utilisateur, ayant une authentification différente (je n'ai pas encore utilisé App Store). Si c'est le cas, je créerais un script pour modifier temporairement le trousseau de clés, lancer Reeder, puis recréer l'original. C'est une approche assez grotesque, cependant.

Cela dépend de l'application, j'imagine que c'est parfaitement possible pour certaines, et pas pour d'autres. Cela dépend si l'application est contenue dans son propre bundle, ou si elle nécessite l'utilisation de fichiers auxiliaires dans votre dossier ~/library, comme des plists, etc. L'utilisation de ces fichiers plist, etc. est souvent l'endroit où vos paramètres et préférences sont stockés, y compris les paramètres du compte, et le fait d'avoir plusieurs instances de l'application fera qu'elles chercheront toutes au même endroit le fichier plist.

Vous pourriez intégrer le binaire de votre application dans un script pour mettre en place la plist correcte avant de démarrer chaque instance, mais là encore, cela dépend de l'application, il n'y a aucune garantie qu'une application déjà en cours d'exécution continuera à fonctionner si sa plist change, ou qu'elle adoptera simplement les nouveaux paramètres à un moment donné.

Si l'application provient d'un autre endroit que l'App Store, je dirais que vous avez une chance raisonnable de fouiller dans le paquet d'applications et peut-être de changer ce qu'il considère être son nom en éditant un .plist et en espérant que le nom influence l'utilisation du trousseau.

Cependant, comme Reeder est une application de l'App Store, je pense que vous êtes coincé. Si vous modifiez l'application, sa signature deviendra invalide et l'OS ne vous laissera pas l'exécuter. A moins qu'il y ait une sorte de hack d'auto-signature que vous puissiez faire...

Non - le trousseau est une interface système profondément intégrée où le mappage est fortement lié au dossier personnel de l'utilisateur (l'application ne peut pas choisir à quel trousseau de l'utilisateur accéder car le système lui indique quel dossier littéral correspond à ~).

Cependant, le seul cas particulier où cela fonctionnera est celui des applications programmées avec du code pour lire un fichier de configuration (fichier plist, .dotfile, ou autre mécanisme) et vous pourriez utiliser l'automatisation pour définir ces variables d'exécution, ces paramètres ou manipuler directement les fichiers .plist avant de lancer l'application en question.

• L'ornithorynque serait mon choix pour un shell script pour changer les choses et ensuite lancer l'application et regrouper les choses.
• Scripting du trousseau de clés pourrait également vous démanger si vous pouviez récupérer le nom de l'objet du trousseau de clés que vous voulez passer dans l'application pour obtenir un comportement différent à chaque lancement.

Le système ne dispose pas d'une vision de sandbox pour cette séparation des données, sauf si vous deviez littéralement démarrer une deuxième session utilisateur (ce que Lion et les versions ultérieures autorisent), mais l'application devrait envoyer les données vers un tuyau ou un fichier plutôt que d'exister à l'écran en tant qu'application en cours d'exécution d'un utilisateur différent.

À moins d'écrire cet outil vous-même (vous avez Xcode après tout), il n'y a rien qu'Apple fournisse pour automatiser le sandboxing du trousseau de clés comme je comprends votre description.