Problème de menu, incompréhensible

Réponses

• Pyroh Membre

  mai 2019 #2

  On va commencer par le début du commencement...

  @interface SidebarView : NSOutlineView <NSOutlineViewDelegate, NSOutlineViewDataSource, NSMenuDelegate, MainViewControllerDelegate>
  

  Ça veut dire, si je comprends bien, que tu crée une subclass de NSOutlineView qui est elle même son propre delegate ainsi que ça propre data source tout en étant le delegate du menu et en plus le delegate d'une instance de NSViewController. J'ai bon là ?

  Je continue une fois que tu auras répondu.
• [Utilisateur supprimé]

  mai 2019 mai 2019 modifié #3

  C'est ce qui s'appel me mettre le nez dans mon caca ?

  J'ai un subclass NSOutlineView.

  Pour moi, je ne maitrise pas encore, NSOutlineViewDelegate et NSOutlineViewDataSource = me permet d'envoyer mes datas dans NSOutlineView via tout le baratin - (void)outlineViewblabla bla

  delegate de NSViewController pour récupérer la commande du menu contextuel.

  C'est p'tet pas bon mais interfacebuilder me perturbe au plus haut point. C'est assez étrange parce qu'il ne colle pas du tout à la mentalité *nix et me fait penser à un truc provenant de chez microsoft dans sa conception.
• Pyroh Membre

  mai 2019 #4

  @Harlo a dit :
  C'est ce qui s'appel me mettre le nez dans mon caca ?

  Je dirai pas ça comme ça mais c'est l'idée. Enfin c'est surtout l'occasion de t'expliquer pourquoi on ne le fait pas et surtout ce qu'il faut faire à la place.

  De base quand on fait une application de type GUI on utilise un design pattern appelé MVC (pour Model View Controller). Il en existe d'autres Medium et rempli de posts qui expliquent comment utiliser des design patterns révolutionnaires qui enterre le MVC mais dans ton cas je te conseille de le maîtriser avant d'aller voir ce qu'il se fait ailleurs.

  Le MVC est simple :

  • La couche model s'occupe de créer et maintenir les données. Tu peux intégrer de la logique interne et mettre à jour des champs inter-dépendant lors d'une modification.
  • La couche view présente les donnés du modèle avec mise-en-forme préalable au besoin et gère les entrées de l'utilisateur.
  • La couche controller orchestre le tout. Basiquement elle observe les changements dans la couche model et met à jour la couche view en conséquence. De la même manière il attend de la couche view qu'elle le notifie des actions de l'utilisateur pour répercuter tout ça dans la couche model.

  Voilà pour la version basique du MVC après tu peux adapter tout ça selon les besoins.

  Ce qui nous amène à ton code, si tu as bien suivit tu comprends déjà que c'est le contrôleur qui doit fournir les données du modèle aux vues. Conséquemment une NSOutlineView qui est elle même sa propre data source partirait du principe qu'elle appartient aux trois couches à la fois. Ce qui est l'équivalent de la balle dans le pieds en terme de génie logiciel (j'aurai pu employer un langage plus fleuri). Logiquement c'est le contrôleur qui doit occuper cette place.

  Pour ce qui est du delegate c'est aussi un design pattern (le delegate pattern). Il permet à la base détendre et modifier le comportement d'une classe sans avoir à la sous-classer. On s'accordera dès lors sur l'aspect incongru de ton architecture. Encore une fois c'est la couche controller qui doit prendre ce rôle certainement pas la vue elle-même. Ça vaut pour les deux delegates.

  Pour finir on parle de couches ce qui veut dire que chacune d'entre elles peut être composées de n classes différentes qui s'articulent entre elles. Ici tu peux avoir une instance de NSViewController qui s'occupe de tout parce qu'il n'y a pas tellement de code. Tu peux aussi utiliser une instance standard de NSOutlineView vu que tu n'ajoute rien à la classe en elle-même.

  Tu peux aussi peupler ton outline view en utilisant les bindings tu éliminera tout le glue code lié à la data source et autres synchro de la sélection, etc...
• [Utilisateur supprimé]

  mai 2019 mai 2019 modifié #5

  Merci

  ou pas, ça veut dire que ma première application qui me rendait si fier est elle aussi de conception moisie
• Larme Membre

  mai 2019 #6

  @Harlo a dit :
  Merci

  ou pas, ça veut dire que ma première application qui me rendait si fier est elle aussi de conception moisie

  C'est normal et ça fait partie de l'expérience. Plus tu acquiers de l'XP, plus tu te dis que ton code d'hier n'était pas forcément top.
• Pyroh Membre

  mai 2019 #7

  @Harlo a dit :
  Merci

  ou pas, ça veut dire que ma première application qui me rendait si fier est elle aussi de conception moisie

  De rien !

  Après tu as raison la conception de ta première app est apocalyptique mais tu as surtout raison d'en être fier. Le génie logiciel c'est compliqué et comme dit @Larme on a tous du code dont on a été fier un jour mais qui nous fait honte aujourd'hui. Un peu comme des enfants en fait 😐
• [Utilisateur supprimé]

  mai 2019 #8

  @Pyroh a dit :
  Un peu comme des enfants en fait 😐

  🤣
• Lexxis Membre

  mai 2019 #9

  Si tu n'as pas spécifié de target sur les NSMenuItem, c'est la chaine de répondeurs qui est mise à contribution. MainViewController doit en faire partie mais SideBarView j'imagine.
• [Utilisateur supprimé]

  mai 2019 #10

  Là je ne vois pas du tout comment lui indiquer la cible