›

[®esolu] interface coredata itunes-like

cargocargo Membre
mars 2006 modifié dans API AppKit #1
Je me demandais ce qu'il y a derrière la colonne de gauche dans itunes : c'est une tableview apparemment...
Les listes "Bibliothèque" et "Music Store" par ex, représentent des boutons contrôles d'une tabview ou purement des entrées dans une tableview ou les deux ou autre chose ?
Si je souhaite par ex mettre dans une tableview des entrées correspondant aux intitulés des entités coredata (Département, Employés) et non pas différentes instances d'un managedObject, pour contrôler les views s'affichant sur la droite ça a du sens ou pas ? Sachant que ces views peuvent être totalement différentes.
Faire en quelque sorte une tabview contrôlée par une tableview ???
Je ne vois pas ce que c'est en fait dans itunes, j'ai l'impression qu'à  part les playlists le reste est "en dur" en quelque sorte, non ?

Réponses

  • SystemSystem
    février 2006 modifié #2
    Bon d'abord la colonne de gauche de iTunes n'est pas une tableview, mais un truc en carbon qui y ressemble.

    Le truc c'est d'utiliser la 'veille' méthode pour alimenter ta table et non les bindings, et puis tu utilises cette bonne vieille méthode de délégué tableViewSelectionDidChange: pour etre informé des changements de sélection dans ta table et sélectionner par code l'élément correspondant de ta tabview.
  • cargocargo Membre
    07:47 modifié #3
    Sinon j'avais pensé à  une solution plus simple qui marche : mettre des radios buttons en les customizant pour que le button aqua soit invisible en fait, avec un takeSelectedTabViewItemFromSender pour naviguer dans les tabs. Et dessous je met une tableview pour tout ce qui est dynamique (smart playlists...). Mais ça c'est tricher... :P
  • cargocargo Membre
    07:47 modifié #4
    FYI le NSBrowser (view du Finder) peut aussi servir à  contrôler les tabs
  • elfelf Membre
    07:47 modifié #5
    Renaud si je ne me trompe pas a partire de la v5 iTunes est en Cocoa, en tout cas c'est ce que j'ai entendu sur pompompompom je crois...
  • SystemSystem
    07:47 modifié #6
    Ah? Du cocoa où toutes les données UI (fenêtres et images) sont stockées dans un .rsrc ça me parait loufoque comme idée.
  • MathMath Membre
    07:47 modifié #7
    D'ailleurs à  ce propos je me demande un truc. Ils utilisent quel logiciel chez Apple pour faire des .rsrc au lieu des nib ?
  • cargocargo Membre
    07:47 modifié #8
    Le truc c'est d'utiliser la 'veille' méthode pour alimenter ta table et non les bindings, et puis tu utilises cette bonne vieille méthode de délégué tableViewSelectionDidChange: pour etre informé des changements de sélection dans ta table et sélectionner par code l'élément correspondant de ta tabview.


    La table serait finalement une outlineView contrôlée par un treeController et alimentée en données par une entité coredata "groups" avec 3 instances de managedObjects crées par défaut pour chaque doc. A chacune de ces instances doit correspondre une tabView.
    En child de ces instances des smart lists, donc créées par l'utilisateur à  volonté ; elles doivent afficher la tabView de leur parent réciproque bien sûr.
    C'est jouable ?



  • cargocargo Membre
    07:47 modifié #9
    J'ai une idée  ;)...Pas bête le gars vous allez voir... :)
    Une entité coredata "groups" avec comme attribut, entre autres, un int représentant l'identifier d'une tab.
    Je bind le selectedIdentifier de la tabView au controller de "groups", avec comme MKP cet attribute, à  mon avis ça peut gazer...Reste à  gérer le parent/child mais ça je vois comment faire...D'abord implémenter les smarts list  B) après on verra...
  • cargocargo Membre
    mars 2006 modifié #10
    Dixit Renaud :
    Citation de: cargo sur 23 Mars 2006, 05:27
    Une entité coredata "groups" avec comme attribut, entre autres, un int représentant l'identifier d'une tab.
    Je bind le selectedIdentifier de la tabView au controller de "groups", avec comme MKP cet attribute, à  mon avis ça peut gazer...


    Donc t'auras compris que pour moi, t'as toujours rien compris au MVC.


    Eh ben j'ai essayé ça marche ! Une entity "Group" avec un attribut int64 "groupPriority" qui me sert, d'une à  classer mes groupes dans la colonne avec un NSSortDescriptor, et de deux à  switcher dans les tabs !!!

    Voilà  le binding à  réaliser dans NSTabView:
    selectedIdentifier
    Bind to: leControllerDeGroup
    Controller Key : selection
    MKP : groupPriority

    Enjoy !
    Vive les bindings et les conseils de Renaud (c'est pas incompatible) !!!
    :p :p



  • SystemSystem
    mars 2006 modifié #11
    évidemment que ça peut marcher, je n'ai jamais dit que ça ne pouvait pas ...juste que ça démontrait une mauvaise compréhension du MVC.

    Tu introduis dans ton modèle des données qui aurait du se trouver dans la couche controlleur. Ce n'est pas à  un élément du modèle de choisir l'élément d'interface que tu veux afficher (ce que tu fais là  - si tu rajoutes un groupe sans rajouter le tab correspondant, ça peut causer un problème), c'est au controlleur de regarder quel élément est sélectionné et adapter l'affichage en fonction. Ton interface ne doit pas etre conçue en fonction du nombre d'éléments associés à  une entité donnée (enfin si, mais uniquement en utilisant des ordres de grandeurs, une interface ne se conçoit évidemment pas de la meme manière s'il y a beaucoup d'éléments ou s'il y en a peu).

    Comme ton nombre d'éléments est déterminé, tu aurais pu juste te contenter de créer un tableau dans ton controlleur (et pas une nouvelle entité) et faire les bindings en fonction de ce tableau, mais créer une entité pour ça est une incompréhension du MVC, je le maintiens.
  • cargocargo Membre
    07:47 modifié #12
    Et ça c'est mal.
      ;D
    Je suis pas le seul à  le faire, crois moi, on trouve dans certains exemples Apple des attributs qui ne sont pas vraiment des data mais plutôt des tips&tricks....
    Allez quoi... ouftiiii....bois donc un pequet avec moi... :p :p

    Sinon :
    Autant pour moi l'identifier est une string, en sautant au plafond j'avais pas vu le message de la console ;), donc l'attribut doit être une string, ça peut donc même être le nom du groupe par exemple, ça économise un attribute et ça fait plaisir à  Renaud. Dans ce cas, c'est donc bien un array ou treeController qui gère une vue en fonction du data model auquel il est associé.

  • SystemSystem
    mars 2006 modifié #13
    Les exemples ne sont que des exemples pour illustrer un point donné, mais il ne me semble pas qu'ils soient tous rigoureusement conformes à  ce qu'on peut trouver dans une "vraie" application.

    La question n'est pas de me faire plaisir, mais une séparation très rigoureuse des 3 couches permet d'éviter bien des ennuis, tout en conservant une bonne évolutivité. Autant prendre de bonnes habitudes dès le début (quitte à  en faire trop). Petit détail: si tu entends par "nom" élément qui est affiché dans la liste, il vaut mieux éviter, une interface doit pouvoir etre localisée sans toucher au code source.

    T'as du pequet à  la pomme?

    PS: je ne sais pas si tu as vu, mais 3 secondes avant que ta réponse n'arrive, j'ai remplacé mon texte par quelque chose de plus constructif.
Connectez-vous ou Inscrivez-vous pour répondre.