Programmer le "Pomme + N"

FreggFregg Membre
17:06 modifié dans API AppKit #1
Salut à  tous,

Toujours dans mon programme permettant d'afficher des info sur des fichiers, je souhaiterais permettre d'ouvrir plusieurs GUI en même temps. Je m'explique... Au lancement il m'affiche donc la GUI, avec la possibilité d'aller chercher un fichier (Pomme + O), et une fois ouvert, le GUI affiche les infos du fichier.

Ce que je souhaiterais faire c'est, dans une optique de comparaison (par exemple), pouvoir permettre de faire Pomme + N (ce qui ouvrirait un seconde instance de la GUI) où la on pourrait aller chercher un autre fichier pour afficher ses info, et comparer les deux fichiers en comparant les deux GUI d'un seul coup d'oeil...

J'ai déjà  chercher sur Google avec comme mot de rechercher "multi window cocoa application", "creating "New" menu cocoa application", ... etc. Mais je n'ai rien trouvé jusqu'à  présent...

J'arrive à  lier le menu "New" à  une méthodes au travers du contrôleur, mais je ne sais pas comment implémenter cette méthode pour qu'elle fasse ce que je veux...

Quelqu'un peut-il m'aider ?

Réponses

  • psychoh13psychoh13 Mothership Developer Membre
    janvier 2008 modifié #2
    Je pense que tu aurais du commencer par faire une application de type Document, dans l'assistant de projet tu cherches "Cocoa document-based Application", et là  tout est plus ou moins géré. Il faut bien sûr que tu programmes ce qui appartient spécifiquement à  ton application, c'est-à -dire l'apparence d'un document ou le code qu'il y a derrière pour archiver et désarchiver tes documents, etc.
    Mais sinon tout le côté "gestion" est déjà  géré.
  • FreggFregg Membre
    17:06 modifié #3
    Zut si j'avais su, j'aurais commencer par la...

    Le soucis, c'est que maintenant, j'ai pas mal de fichier de code (un bonne 30aine a  vue de nez)... Du coup, je me vois mal passer de ce que j'ai pour le réintégrer a un application de type Document.

    Y aurait-il un moyen "simple" (ou pas TROP compliqué) de codé ce que je veux ? Peut-être même de récupérer le code d'une App de type Document afin de gérer le Pomme + N ?

    Merci d'avance...

  • schlumschlum Membre
    17:06 modifié #4
    Tu peux créer un nouveau projet type gestion de documents et y intégrer ton code, non ?
    En général si l'architecture de classes n'est pas trop mal foutue, ça se fait assez vite  ;)
  • FreggFregg Membre
    janvier 2008 modifié #5
    Ben je tenterai le coup, mais comme j'suis pas super sur que mes classes soient super bien faites, j'suis pas sure que ca va aller tout seul... Enfin je tenterai dès que j'ai finit ce que je suis en train de faire...
  • BruBru Membre
    17:06 modifié #6
    Utiliser "de multiples instances de la GUI" n'est pas spécialement compliqué à  faire, même si le projet XCode n'est pas document-based.

    La seule condition est d'avoir une classe "super-contrôleur" présent dans le mainmenu.nib. Par contre la "GUI" (je pense que tu parles de ta fenêtre d'info) doit être dans un nib à  part.

    Ensuite tout ce gère à  partie du super-contrôleur (auquel est relié entre autre l'action POMME+N) qui va charger une nouvelle instance de la "GUI" et va instancier le contrôleur associé à  cette "GUI".

    .
  • FreggFregg Membre
    17:06 modifié #7
    dans 1200851313:

    La seule condition est d'avoir une classe "super-contrôleur" présent dans le mainmenu.nib. Par contre la "GUI" (je pense que tu parles de ta fenêtre d'info) doit être dans un nib à  part.

    Ensuite tout ce gère à  partie du super-contrôleur (auquel est relié entre autre l'action POMME+N) qui va charger une nouvelle instance de la "GUI" et va instancier le contrôleur associé à  cette "GUI".


    J'ai en effet un fichier .NIB (MainMenu.NIB pour être précis) dans lequel j'ai définit tous les champ que je veux afficher et tout et tout... Il suffirait donc que en plus de mon contrôler (que j'ai appelé GUIControler.h/m) que je fasse un "super contrôleur" (ex : GUISControler.h/m)...

    Cela voudrait dire que donc le "contrôleur" dans le MVC ne contrôle "que" une fenêtre (c-à -d un partie de la vue) et pas TOUTE la vue ?? Et donc, chaque petite partie de vue (c-à -d chaque fenêtre) nécessiterait un contrôleur spécifique... Ca me semble en même temps logique et en même temps pas super optimisé ! Surtout dans le cas où on affiche plusieurs fois LA MEME fenêtre, ne pourrait-on pas se contenter d'un seul contrôleur, dont une nouvelle instance serait créée à  chaque fois qu'on choisirait d'avoir une nouvelle GUI (c-à -d : POMME+N) ?? A moins que je n'ai pas compris certaine choses/paradigmes concernant le Obj-c, cocoa ou l' OOP...
  • psychoh13psychoh13 Mothership Developer Membre
    17:06 modifié #8
    J'ai l'impression que tu te contredis dans ce que tu écris...
    Tu dis que ça ne semble pas super optimisé de faire un controleur par fenêtre mais tu penses qu'il faudrait mieux qu'à  chaque fois qu'une nouvelle fenêtre apparaà®t on crée une nouvelle instance du controleur...

    On va faire simple... Dans une "Cocoa document-based application", le projet commence avec deux fichiers NIB. Le MainMenu.nib commun à  toutes les applications Cocoa, et le Document.nib.
    Le projet nous donne aussi par défaut deux fichiers définissant une sous-classe de NSDocument nommée MyDocument.
    Dans le .nib, le "File's owner" n'est plus de type NSApplication comme dans MainMenu.nib mais de type MyDocument.

    Cela signifie que lorsqu'on crée un nouveau document, Cocoa va en fait charger le fichier NIB du document de l'application et va instancier la classe MyDocument (ainsi que les autres indiqués dans le fichier .nib) puis afficher la fenêtre.
    Donc, on a bien une instance de la même classe MyDocument pour chaque document créé.
  • FreggFregg Membre
    17:06 modifié #9
    dans 1200865532:

    J'ai l'impression que tu te contredis dans ce que tu écris...
    Tu dis que ça ne semble pas super optimisé de faire un controleur par fenêtre mais tu penses qu'il faudrait mieux qu'à  chaque fois qu'une nouvelle fenêtre apparaà®t on crée une nouvelle instance du controleur...


    J'ai du mal m'exprimer... Je te prie de bien vouloir m'en excuser. En fait, dans ma tête, quand je pense "plusieurs controleurs" je pense en fait :" plusieurs classe, c-à -d plusieurs fichiers GUIControl.h/m (dans mon cas) ". Ce qui pour moi est différent de "plusieurs instance de contrôleur" ou je vois ca comme "plusieurs objet d'une même classe".

    Si il faut une classe contrôleur par affichage graphique, alors oui, je trouve pas ca super optimisé. Par contre si, lorsqu'on veut afficher plusieurs fois notre appli, il crée plusieurs fois une instance du seul (et unique) contrôleur qu'on a dans notre appli, alors en plus de me sembler logique, ca me semble optimisé...

    C'est cela que je voulais exprimer (en espérant que cette fois ci je l'ai bien fait)...
  • psychoh13psychoh13 Mothership Developer Membre
    17:06 modifié #10
    Donc oui c'est bon est sur la même longueur d'onde... Et c'est le principe que j'ai expliqué en me basant sur les document-based applications. Donc tu peux relire la deuxième partie de mon message (à  partir du "On va faire simple").

    Tu peux pour simplifier ajouter un nouveau fichier NIB (fais attention de choisir le bon modèle de fichier NIB, normalement dans ton cas ce serait le modèle "Window" (tu peux choisir ça en créant un nouveau fichier dans IB).
Connectez-vous ou Inscrivez-vous pour répondre.