Était-ce utile?

La solution

Vraiment, on dirait que vous essayez de faire en sorte que votre communication inter-processus se déroule au niveau de la vue, ce qui n’est pas vraiment le fonctionnement de Cocoa. Les choses seront beaucoup plus faciles si vous séparez un peu plus vos couches.

Pourquoi ne voulez-vous pas insérer le code de feuille dans l’autre processus? C'est le code de vue, et le code de vue est intrinsèquement spécifique au processus. La bonne chose à faire ici est probablement d'ajouter un support quelque peu générique à votre code de plug-in, et un appel IPC que votre démon peut effectuer pour appeler ce code. Essayer d'expédier des objets de vue au processus distant va devenir cauchemardesque si vous pouvez le faire fonctionner.

Vous combattez les cadres avec cette approche.

Autres conseils

Vous ne pouvez pas ajouter de feuille à une fenêtre dans un autre processus, car vous disposez au maximum de l'accès le plus restreint possible aux fenêtres de l'autre processus.

S'il vous plaît, ne faites pas ça. Rendre l’interaction non modale si possible. Surtout dans un type de commit, il est bien plus agréable de pouvoir parcourir vos fichiers pendant que vous écrivez des commentaires de commit.

OS X a des groupes de fenêtres, mais je ne pense pas qu’ils puissent étendre (facilement) des applications.

Il est également important de noter que sous OS X, il est possible d’avoir plusieurs fenêtres du Finder ouvertes sur le même dossier (contrairement à OS 9). Même si vous disposiez de privilèges / API suffisants pour ajouter une feuille à une fenêtre du Finder, ce n'est pas comme si la modalité de cette fenêtre empêcherait l'utilisateur de continuer à utiliser les fichiers.

(Mon opinion personnelle, en tant qu'utilisateur Mac de longue date, est que ce type d'interaction me conduirait droit au mur.)

scroll top