Multi-nib et barre d'outils
muqaddar
Administrateur
Salut,
Bon, je suis en train de créer ma première application multi-nib.
J'arrive à charger un autre nib depuis le premier en cliquant sur une icone de ma barre d'outils. Seulement, mon nib se charge et charge la fenetre associée à ce nib sur l'écran, en plus de la fenêtre principale. Moi je voudrais remplacer la fenetre mainWindow du mainMenu.nib par celle du nouveau nib (casier.nib), tout en gardant la barre d'outils associée à la fenetre du maimMenu.nib.
Si je ne suis pas clair, c'est exactement le même principe que les prefs d'ichat...
Tout ça est passionnant !
Bon, je suis en train de créer ma première application multi-nib.
J'arrive à charger un autre nib depuis le premier en cliquant sur une icone de ma barre d'outils. Seulement, mon nib se charge et charge la fenetre associée à ce nib sur l'écran, en plus de la fenêtre principale. Moi je voudrais remplacer la fenetre mainWindow du mainMenu.nib par celle du nouveau nib (casier.nib), tout en gardant la barre d'outils associée à la fenetre du maimMenu.nib.
Si je ne suis pas clair, c'est exactement le même principe que les prefs d'ichat...
Tout ça est passionnant !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Globalement par setContentView
Ou en utilisant un tabView sans tabs visibles
http://www.projectomega.org/article.php?lg=fr&php=oreilly_cocoa19&p=1
mpergan, il manque pas des mots dans ton message ?
Une méthode possible est d'utiliser un NSTabView avec un tabView pour chaque vue que tu veux afficher, lors d'un clic sur une icône de ta barre d'outils, tu selectionneras la tabView correspondante avec selectTabViewItem ou selectTabViewAtIndex.
J'ai donc 2 nib (en tout j'en aurais 5 plus tard) qui contiennent chacun 1 vue (view).
Dans le awakeFromNib, j'initialise la vue du mainMenu.nib. Ensuite, qd je clique sur l'icone de ma barre d'outils, j'appelle une action qui charge le nib (l'autre) et affiche sa vue. Le pied avec la méthode resize d'animer ça ! :-)
Dependant, il y a 2 points qui foirent :
- D'abord, je ne suis pas sûr que quand un nib a été chargé, il ne soit pas à nouveau chargé.
J'ai fait ça :
casierView étant la vue du nib casier... je doute que ça suffise.
- Second point :
Au lancement de l'appli tout est parfait. Je change de nib et de vue : OK. La deuxième vue est plus petite. Je repasse dans la première et patatrac, le haut de la vue est caché par la toolbar. Et oui on se sert de la frame de la fenêtre pour ajuster à la taille mais ça prend pas en compte la barre d'outils apparemment.
Le code de redimenssionnement :
Je pense pouvoir tricher en ajoutant une dimension en pixels en hauteur, mais je pense que ça augmentera la taille aussi au démarrage de l'appli (qd ça marche)...
float newHeight = newSize.height + 50;
ça marche, mais je trouve pas cette solution très propre... Il doit y avoir mieux...
Moi non plus..
Je ferais plutôt comme a dit mpergand: un TabView..
C'est une View qui sait gérer plusieurs vues et qui en affiche qu'une seule à la fois.. ca semble correspondre à ton besoin (tu peux ne pas afficher les onglets)
Tu met la TabView dans la fenêtre avec ta toolbar, et tu fournis tous les NSTabViewItem initialisés pour chacune de tes vue de nib..
C'est encore plus simple si tu n'a pas la contrainte d'avoir plusieurs nibs..
Et oui, je comprends pas bien l'interet d'avoir plusieurs nibs, en fait ???
Hein osxitan ?  ;)
file:///Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/LoadingResources/Concepts/UsingMultiNibFiles.html
Il va de soit que c'est peut-être démesuré dans mon cas, mais autant faire les choses bien même sur un petit programme...
Ton lien ne marche pas Génose.
Quant à la solution de charger les vues, ça marche très bien hormis l'histoire du décalage dû à la toolbar. C'est comme ça qu'ils font en général (j'ai lu des tutorials), je ne vois pas trop l'intérêt de "bricoler" avec des tabView qui ne sont pas là pour ça, non ?
L'économie de mémoire, pfff c'était bon du temps de NEXT y a 15 ans, quant au temps de chargement, ben c'est pareil, quand les ordis plafonnaient à 20Mhz
Sérieusement, le multi-nibs ne se justifie que dans le cas de grosses applis bien gourmandes en ressources...
Pour moi le multi-nibs à une autre utilité, il peut aider à la structuration d'un programme et permettre de créer des modules autonomes. Ex, j'ai dans mes éditeurs de synthés un clavier MIDI virtuel, il est composé d'un nib et de sa classe contrôleur, formant un module indépendant. Il me suffit de l'ajouter à un projet et de le charger au démarrage et voila il est intégré à la nouvelle appli.
Franchement ces économies de bouts de ficelles sur la mémoire et la vitesse de chargement: laissez tomber
ils racontent que pour que acceder aux classes et aux NSWindow, on doit creer une instance de NSWindowController,
jusque la ok ca marche.
//@ mycontrollerwind : NSWindowController
::main.m
mycontrollerwind *mycontroller = [[mycontrollerwind alloc] init];
ensuite je charge le nib avec
if (![NSBundle loadNibNamed:@Stratup_screen owner:mycontrollerwind]) {
NSLog(@Error loading Nib for document!);
[mycontrollerwind release];
} else {
NSLog(@ Nib loaded for document!);
[mycontrollerwind doSomething];
}
::end
et enfin avec dosomething je fait dans ma class :
::mycontrollerwind.m
[MyIBWind makeKeyAndOrderFront];
meme en suivant les recomandations des doc apple et des tutos sur le web ca n'a rien changer
ma fenetre reste cacher et dans la console j'ai des alerte genre "bad connection" alors que en definisant ce meme nib comme etant le mainnib il charge et affiche la fenetre :why?:
a croire je devrai refaire les connections avec un Truc comme NSNibConnection
une idée du pourquoi de ce truc?
Merci
Genose
pour obtenir la taille de la barre d'outils:
Décidément le multi-nibs posent bien des problèmes et pourtant c'est pas compliqué, il suffit de les utiliser à bon escient.
Les applis documents-based sont par nature multi-nibs puisqu'il y a un nib par type de document + le mainNib
Pour l'histoire du windowController, le seul cas où j'ai eu à l'utiliser, c'est pour ouvrir plusieurs fenêtres contenant le même document (représentation différentes des données)
Que veux-tu faire avec ce windowController ?
Je pense que c'est une erreur de saisie, mais vérifie bien que c'est mycontroller et non mycontrollerwind, car dans le bout de code que tu as mis dans ton post, tu as fait la confusion entre les 2 (argument owner de (![NSBundle loadNibNamed:owner:], destinataire du message release ou doSomething dans le if/else).
.
Merci cbrandt, ça a l'air de marcher nikel ! :-)
Sinon effectivement tu peux gagner du temps de chargement et de la mémoire, mais dans ton cas je ne pense pas que tu n'aura pas cet avantage.. puisque pour afficher ta fenêtre il te faudra charger tous les nibs de tes fragments d'interface.. tu te compliques la vie..
Pour profiter de ces avantages, tu pourrais faire un nib spécifique pour cette fenêtre qui incluerai aussi toutes tes vues différentes dans un TabView.. Et au moment voulu, tu charge ce nib en l'associant à ton WindowController spécifique..
A propos de WindowController dans une application "document-based", ca peut être utile de faire sa propre version pour découpler la classe document de truc périphériques comme la gestion des tiroirs, des barres d'outils.. Ainsi la classe document se voit affecter des responsabilité plus en rapport avec le modèle (MVC) et moins en rapport avec l'interaction utilisateur
Merci à vous.
ça aura au moins le mérite de m'avoir fait utiliser les nibs.
effectivement, mais bon cela n'a pas changer grand chose dans le code, une fois compiler
en plus la class mycontrollerwind est la classe stoké dans mon nib avec cette fenetre donc c'est pas logique que elle se retrouve pas.
bien que ...
mon log donne :
k s ki cloche dans ce Ko 2 ?
ps: je veux faire comme d'autre on appris a le faire, une fenetre qui s'affichera apres avoir charger une ressource nib.
Pour finir je suis parvenu a creer une startup screen, comme pendant le demarrage de macosX, avec texte qui defile en temp reel pendant les phases de chargement de tout mes nib, plug-ins, et de mes documents, en gros pendant toutes le durée du chargement de l'appli.
le muti-nib est vraiment super.
j'apprend doucement mais je progresse mieux deja !!
A bientot.
Genose
Merci cbrandt, ça a l'air de marcher nikel ! :-)
Il y a plus simple:
Ce code te donne la de la différence entre la taille de la fenetre et son contenu, cà d la taille de la barre de titre et de la barre d'outils. Il te suffit d'ajouter cette grandeur à la taille de la nouvelle vue. Le fait de ne pas avoir de constante fait que ce code est aussi ok pour des palettes par exemple.
En plus je ne vois pas à quoi correspond le 20: il me semble que la taille d'une barre de titre est 22...
Je confirme que c'est bon !
En fait, c'est un vieux bout de code que j'ai utilisé dans un projet, et ce code était basé sur cette page chez apple http://developer.apple.com/documentation/Cocoa/Conceptual/Toolbars/Tasks/ToolbarHeight.html. par contre, je ne sais plus pourquoi j'ai mis cette constante de 20... ???
Ca ressemble à ce que tu essaye de faire non?
Ca utilise une NSTabView.. :sors:
merci