Utilisation InterfaceBuilder + Xcode

[Mac_Kain]

Bonjour,
Je voudrai arriver à créer une interface graphique avec Interface Builder et qu'il y ait une interaction avec du code en C que j'aurai écrit avec Xcode. J'ai déja lu une grande partie de la doc en ligne d'Apple sur ce sujet mais je n'ai pas vraiment saisi... En fait j'arrive à créer une interface, et j'ai déja pas mal dévelloper auparavant avec Xcode.
En définitif, quelqu'un pourrait il me donner, de façon claire, simple et la plus conçise à suivre, la démarche necessaire pour faire, par exemple, une fenetre avec un seul bouton et que lorsque l'utilisateur clique sur le bouton, cela affiche, par exemple '5' dans une boite de texte située dans la meme fenetre.
N'étant pas trop bete avec ça je devrai arriver à étendre la démarche pour des actionns plus compliquées...

PS : sauf s'il est vraiment vraiment vraiment simple, claire et conçis, je vous en supplie ne me donnez pas simplement la référence d'un lien à aller visiter car je sature un peu après avoir lu 10h de page en anglais sur le sujet...

Merci d'avance à tous mes futurs sauveurs

 

[mpergand]

Here I am

- dans Xcode créer un nouveau projet Cocoa Application
- double-cliquer sur MainMenu.nib ( IB se lance)
- dans IB, ajouter un bouton et un TextField à la fenêtre
- cliquer sur l'onglet Classes, faire un clic-droit sur NSObject et choisir Subclass NSObjet et renommer cette classe "Controller" et enfin à nouveau clic-droit sur cette classe et choisir Instanciate Controller.

Faire un double-clic sur l'instance Controller, dans la palette info cliquer sur l'onglet Actions, cliquer sur Add, taper "buttonAction", puis cliquer sur l'onglet Outlets, cliquer sur Add, taper textField pour le nom et choisir NSTextField pour le type.

Dans la fenêtre "MainMenu.nib" cliquer sur l'onglet Instances, maintenir la touche control pressée tout en cliquant sur l'objet Controller, un lien apparait, faire glisser ce lien jusqu'à l'objet TextField de la fenêtre, relacher la souris et dans la palette Info choisir dans Outlets "textField" puis cliquer Connect.

Répéter l'opération, mais cette fois en partant du NSButton pour créer un lien avec le Controller, dans la palette Info choisir dans Target/Action "buttonAction" et cliquer Connect.

Revenir dans l'onglet Classes, puis clic-droit sur Controller et choisir "Create File for Controller"

Retour dans Xcode, dans le fichier Controller.m taper:

#import "Controller.h"

@implementation Controller

- (IBAction)buttonAction:(id)sender
{
	[textField setStringValue:@"Coucou"];
}

@end

Build !!!!!!

 

[Mac_Kain]

Great !
Parfait. Je viens de faire un pas de géant en avant. Une question reste cependant : tu utilises cocoa, mais est il possible de plutot utiliser carbon ? (En utilisant les events je crois du type kEventMouseDown...)

 

[mpergand]

Aucune raison d'utiliser carbon pour gérer l'interface, à moins d'être maso ou totalement réfractaire à la programmation objets, mais c'est une grave erreur

 

[Mac_Kain]

Et bien en fait l'interface que je voudrai créer doit (hélas pour moi apparemment !) répondre à un cahier des charges qui précise que carbon doit être utilisé. Cela va t'il être si compliqué que ça ? (je rêverrai de programmer en POO, mais là, VRAIMENT, je n'ai pas le choix)

 

[mpergand]

Pour quelle raison ? L'appli doit être compatible OS 9 ?
Sinon en Cocoa on peut appeler les fonctions Carbon, et on peut mixer ObjectiveC avec du C ou du C++.

Si l'interface de ton appli n'est pas trop complexe, c'est envisageable de tout faire en carbon, il existe un nouveau modèle basé sur les Hi Views:
http://developer.apple.com/document...Doc/index.html#//apple_ref/doc/uid/TP30000923
Mais je ne connais pas du tout.

Sinon la voie royale pour programmer en Carbon, c'est d'utiliser la framework PowerPlant de Codewarrior en C++. Mais cette framework n'existera jamais pour les processeurs Intel.

 

[Mac_Kain]

Bon je pense qu'effectivement je devrai donner plus d'explications, car peut être me suis je trompé dès la base du problème.
Au départ, il me fallait réaliser une application en C interfaçée avec une API. Bon, le C ça se passe bien, mais les API... En me renseignant, j'ai cru comprendre que une API c'était une interface graphique liée au programme par un genre de lien action/réaction. Ca c'est immuable et je peux pas y toucher.
Ensuite je découvre que les API c'est que pour Window, et moi j'ai un mac et jusqu'à maintenant j'ai tout fait avec Xcode et ça c'est bien passé.
Et donc j'ai cru comprendre, à travers ce que j'ai lu, que ce qui se rapprochait le plus de tout ça, c'était de créer une IG avec IB et d'écrire le code et les évenements en Carbon (car il faut ABSOLUMENT que ça soit en C).
Alors peut être que je me suis trompé dès ses premiers choix. Et puis comment ça va se passer pour la portabilité ?
En bref je suis perdu, je n'ai pas envie de baisser mon caleçon devant Windows et abandonné la résistance ici. Je voudrai vraiment arriver à programmer sous mac une application qui correspond à tout ça...
Verdict ? :mouais:

 

[ntx]

Ton code en C est directement appelable dans ton code en Objective-C, pas besoin de Carbon la-dedans. Par contre pour la probabilité vers Windows ou Linux, oublie IB et Cocoa. Il faut passer par d'autres libraries : QT, wxWidget, ...

PS : API s'applique à toutes les interfaces de programmation, pas seulement les graphiques.

 

[Mac_Kain]

OK je pense avoir compris, dites moi si je me trompe :
1/ Je me sers de cocoa pour faire la liaison interface/code
2/ J'utilise le C pour coder les actions à effectuer en réponses aux évenements

Donc j'imagine que ça donne une structure du genre (en réutilisant le code de mpergand) :

------------------------------------------------------------

#import "Controller.h"

@implementation Controller

- (IBAction)buttonActionid)sender
{
// code en C ou appel d'une fonction codée en C
}

@end

------------------------------------------------------------

Bon alors votez 1 si j'ai rien compris ou 2 si je suis sur la bonne voie

 

[mpergand]

En fait, tu veux faire une appli portable Mac/windows et tu penses que carbon est compatible Windows car en C ? Si c'est le cas, tu te trompes lourdement

Pour faire une appli portable, 2 soluces:
1) utiliser un langage portable:
- Java , conçu pour être portable, mais c'est moche.
- RealBasic , langage proche de VisualBasic, pas gratuit.
- Mono , tentative de portage de C#/.NET, encore à l'état expérimental.
- C, C++ , à l'aide de Qt, xWidgets ...

2) Ecrire le moteur de l'appli en C/C++ et pour l'interface utiliser le système natif, Cocoa pour Mac et Visual C++, C# ou autre, coté windows. Résultat top pro, mais exige une bonne connaissances des deux environnements.

Bon courage

 

[yduc]

Bon alors votez 1 si j'ai rien compris ou 2 si je suis sur la bonne voie

Je crois que ton message résume bien les choses (#9). Seul Carbon te permet de répondre strictement à ton cahier des charges (s'en tenir au langage C exclusivement), mais Cocoa est la technologie d'avenir et requiert une dose d'Objective-C dans ton programme.

Et puis comment ça va se passer pour la portabilité ?

J'ai l'impression qu'il s'agit d'un exercice d'école et non d'être compatible avec OS 9 ou d'être portable. Cela dit, et corrigez-moi si je me trompe, un programme en C/Carbon ne sera pas portable (sur Wintel par ex.). Mais un programme C attaquant les API Windows ne l'est pas non plus !
J'ai entendu dire qu'on pouvait compiler Cocoa pour Wintel et MFC pour Mac OS, mais je ne suis pas sûr... iTunes pour Windows est-il une simple recompilation ?

PS : API s'applique à toutes les interfaces de programmation, pas seulement les graphiques.

En effet ; API signifie Application Programming Interface et désigne de façon générale des librairies sur lesquelles le programmeur s'appuie.

Un petit ajout : si tu as encore du courage pour de la doc anglaise, il y a le tutoriel d'Apple, idéal pour faire ses premiers pas en Objective-C/Cocoa : objctutorial.pdf. Ça complètera la réponse de mpergand. (Je viens de le terminer ! ;-))

Bon courage.

Yves

 

[Céroce]

Je crois que ton message résume bien les choses (#9). Seul Carbon te permet de répondre strictement à ton cahier des charges (s'en tenir au langage C exclusivement), mais Cocoa est la technologie d'avenir et requiert une dose d'Objective-C dans ton programme.

Surtout, pour avoir longtemps développé sous Mac OS 7 et ses successeurs, je peux te dire que c'est très compliqué. Ca s'est amélioré, mais dans le temps, pour un simple clic, il fallait tester s'il s'adressait à notre appli, si oui à une fenêtre ou la barre de menu, convertir ses coordonnées en coordonnées locales, etc. et peut-être un jour pouvoir enfin faire du fonctionnel.

Cocoa c'est plus simple, plus rapide, moins plantogène, et tu es quasiment sûr de respecter les standards d'Apple.

Cela dit, et corrigez-moi si je me trompe, un programme en C/Carbon ne sera pas portable (sur Wintel par ex.). Mais un programme C attaquant les API Windows ne l'est pas non plus !
J'ai entendu dire qu'on pouvait compiler Cocoa pour Wintel et MFC pour Mac OS, mais je ne suis pas sûr... iTunes pour Windows est-il une simple recompilation ?

Tout à fait, quelque soit le langage, il faut redévelopper l'interface utilisateur pour chaque système.
La partie interface utilisateur de iTunes Mac est certainement écrite pour Carbon.
Cocoa n'existe pas sous Windows, il existe une vague adaptation de son ancètre...

 

[yduc]

Surtout, pour avoir longtemps développé sous Mac OS 7 et ses successeurs, je peux te dire que c'est très compliqué.

"Très compliqué", n'exagérons rien. J'ai réussi à apprendre tout seul la Toolbox classique à l'époque où j'étais étudiant, et aujourd'hui avec plus de bouteille je me demande si je vais y parvenir avec Cocoa ! :-(

pour un simple clic, il fallait tester s'il s'adressait à notre appli, si oui à une fenêtre ou la barre de menu, convertir ses coordonnées en coordonnées locales

C'est vrai mais il faut préciser que bien souvent, il suffisait de refiler l'événement à une fonction système faite exprès ! L'événement ne faisait que "passer" entre les mains du programmeur.
C'est vrai qu'il y avait quelques bouts de code de gestion basique que l'on retrouvait quasiment inchangés d'une appli à l'autre, mais en s'en faisant une petite librairie, on se débarassait du "problème".
Qu'aujourd'hui il y ait une seule librairie, Cocoa, au lieu de n librairies, une par programmeur, est un progrès, mais je réagissais au "compliqué"... ;-)

Cocoa c'est [...] moins plantogène

Un langage faiblement typé est plus plantogène, par définition ! C'est donc une question de point de vue... ;-)
Globalement j'observe que les applis Mac plantent beaucoup plus depuis OS X... (je tiens à votre disposition, si jamais cela vous intéresse, la liste de tous les plantages systèmes de mon ordi depuis OS X)

Yves

 

[ntx]

Globalement j'observe que les applis Mac plantent beaucoup plus depuis OS X... (je tiens à votre disposition, si jamais cela vous intéresse, la liste de tous les plantages systèmes de mon ordi depuis OS X)

Au contraire : depuis Mac OSX 10.2, on a enfin retrouvé la stabilité du bon vieux Mac OS7. Certes des applis plantent - encore que ça ne doit pas être toujours de la faute d'Apple - mais le système est très robuste. Je ne me souviens plus à quoi ressemble un écran de Kernel Panic.
Le problème n'est pas le langage utilisé mais la maîtrise du framework, comprendre sa philosophie et savoir utiliser toutes ses possibilités. Et quand on voit la quantité de documentations chez Apple, il y a en pour des années avant de tout maîtriser.

 

[Céroce]

C'est vrai mais il faut préciser que bien souvent, il suffisait de refiler l'événement à une fonction système faite exprès ! L'événement ne faisait que "passer" entre les mains du programmeur.
C'est vrai qu'il y avait quelques bouts de code de gestion basique que l'on retrouvait quasiment inchangés d'une appli à l'autre, mais en s'en faisant une petite librairie, on se débarassait du "problème".
Qu'aujourd'hui il y ait une seule librairie, Cocoa, au lieu de n librairies, une par programmeur, est un progrès, mais je réagissais au "compliqué"... ;-)

On n'a vraiment pas le même vécu. La Toolbox était super en retard, comparée aux outils dispos sur les autres plateformes. Je pense que déjà en 1995, aller chercher où a eu lieu le clic de souris, c'est dément! La Toolbox ne gérait pas les palettes flotantes, il fallait aller patcher en mémoire la liste des fenêtres. Alors, "plus stable", mon oeil! Sur PowerPC, il fallait utiliser des bidouilles pour personnaliser un élément de l'interface utilisateur, comme simplement dessiner le cadre autour du bouton par défaut! Les vues a l'intérieur des fenêtres n'étaient pas gérées. Il fallait aller lire les valeurs des ascenseurs puis se démerder pour transformer les coordonnées en local, mettre en place un clipping pour enfin dessiner.

Ce fut un grand soulagement quand je suis passé à PowerPlant. Mais il faut être clair: Cocoa divise encore les temps de développement par 4, par rapport à PowerPlant, qui les divisait déjà par 5. Je ne sais pas si Carbon est beaucoup plus facile à programmer que la vieille Toolbox, je ne connais pas Carbon, mais ils m'ont semblé assez proches, si ce n'est pour la boucle d'évenements.

Un langage faiblement typé est plus plantogène, par définition ! C'est donc une question de point de vue... ;-)

Un programme mal conçu est plus plantogène, par définition. Et quand il faut bidouiller la Toolbox, on fait pas toujours tout bien, parce qu'on ne comprend pas toujours ce qu'on fait.

Globalement j'observe que les applis Mac plantent beaucoup plus depuis OS X... (je tiens à votre disposition, si jamais cela vous intéresse, la liste de tous les plantages systèmes de mon ordi depuis OS X)
Yves

Je ne suis pas sûr que les applis plantent plus, mais ce qui est certain, c'est que le système plante beaucoup moins. C'est le problème des systèmes 7-8-9: les applis pouvaient écrire n'importe où en mémoire sans que le système ne leur reproche rien. Aujourd'hui, il les ferme au premier dépassement mémoire. Au moins, une appli ne peut pas aller corrompre la mémoire d'une autre appli ou du système, et si ton appli plante, tu es quasiment sûr que c'est de ta faute.

 

[mpergand]

Pour abonder dans le sens de céroce, je dirais que le maximum que j'ai du faire en toolBox pure, c'est 50 lignes de code: imbuvable et passage vite fait sur PowerPlant.
Il est difficile de concevoir de ne pas utiliser un langage objets pour la gestion des interfaces, c'est tellement plus adapté !

Le passage à Cocoa et à l'ObjectiveC, m'a fait prendre conscience que le C++ n'est qu'une grosse usine à gaz et maintenant je ne peux plus le voir en peinture

 

[yduc]

La Toolbox était super en retard, comparée aux outils dispos sur les autres plateformes.

C'est vrai. Mais va savoir pourquoi, je me sentais pourtant plus à l'aise avec la Toolbox qu'avec l'API Windows (mon principal autre point de comparaison), pourtant plus moderne ! Chez Windows, la difficulté vient de la complexité du mécanisme des messages et de leur automatisation partielle. Il en résulte qu'en certaines circonstances, tu ne comprends plus ce qui se passe dans ton propre programme, vu que Windows se charge de certaines choses mais pas de tout. Tandis qu'avec la Toolbox, tu as toujours la main et un événement quel qu'il soit passe toujours entre tes mains avant de repartir éventuellement ailleurs. C'est essentiel pour garder la compréhension de la circulation des événements.

déjà en 1995, aller chercher où a eu lieu le clic de souris, c'est dément!

C'est vrai ; Apple a mis le temps avant de proposer un framework digne de ce nom. Pour quelle raison les outils de développement et les librairies système ont-ils été si longtemps négligés ? Pourquoi Apple n'a pas démarré un projet de framework (objet) plus tôt, par-dessus la Toolbox ? J'avoue ne pas savoir... Peut-être qu'Apple privilégiait la stabilité, ou laissait le champ libre aux éditeurs ? (en quelle année CodeWarrior a-t-il été lancé ?)

Cocoa divise encore les temps de développement par 4

Pour le peu que j'en ai vu jusqu'à aujourd'hui, je trouve que le couple Cocoa/Xcode n'a pas rattrapé MFC/Visual C++ en termes de facilitation du travail de développement, concernant la liaison entre interface graphique et moteur. Mais C++Builder fait encore beaucoup mieux que Visual C++. CodeWarrior, je n'ai pas connu : j'ai essayé mais ma machine de l'époque n'était pas assez puissante...

Un programme mal conçu est plus plantogène, par définition. Et quand il faut bidouiller la Toolbox, on fait pas toujours tout bien, parce qu'on ne comprend pas toujours ce qu'on fait.

C'est de la théorie. La pratique c'est qu'il faut que les concepts soient simples pour que le programmeur comprenne et fasse bien. Un bricolage ne sera pas forcément plantogène, même s'il offense l'esprit ! Et inversement, un système très pur et très beau intellectuellement peut se révéler ardu à manier, parce que reposant sur plusieurs couches de génie logiciel pas évidentes à comprendre.

ce qui est certain, c'est que le système plante beaucoup moins.

On n'a pas le même vécu ! ;-) Je n'ai jamais vu mon OS 7 planter, une seule fois mon OS 9 (le jour de l'achat de la machine, et peut-être par la faute d'une appli, d'ailleurs), et déjà... 13 fois OS X ! (y compris qqs redémarrages du Finder) Soit :
- Classic : 1 fois en 8 ans,
- OS X : 13 fois en 2 ans.
Du côté des applications, même chose. Mail, Safari et Xcode plantent joyeusement...

les applis pouvaient écrire n'importe où en mémoire

Les applis pouvaient mais ne le faisaient pas parce qu'elles étaient écrites par des gens qui maîtrisaient leur sujet ! Et justement, je suis assez amusé de voir comme le nombre de plantages a augmenté depuis ce système professionnel qu'est Unix, qu'on dit si stable, robuste et protégé, alors qu'avec le vieux et "sale" système permissif les plantages étaient si rares que j'avais pris l'habitude de n'enregistrer mon travail... qu'en fin de journée !!! (soit une fois par jour) Et je n'ai jamais perdu mon travail en procédant ainsi. Aujourd'hui j'ai plutôt le réflexe Pomme-S chaque minute...

Il est difficile de concevoir de ne pas utiliser un langage objets pour la gestion des interfaces, c'est tellement plus adapté !

Entièrement d'accord.

le C++ n'est qu'une grosse usine à gaz et maintenant je ne peux plus le voir en peinture

Je ne pense pas qu'il y ait un tel gouffre, intellectuel du moins, entre C++ et Obj-C.

Yves

 

[mpergand]

On n'a pas le même vécu ! ;-) Je n'ai jamais vu mon OS 7 planter, une seule fois mon OS 9 (le jour de l'achat de la machine, et peut-être par la faute d'une appli, d'ailleurs), et déjà... 13 fois OS X ! (y compris qqs redémarrages du Finder) Soit :
- Classic : 1 fois en 8 ans,
- OS X : 13 fois en 2 ans.

Tu n'as jamais eu la joie d'utiliser le système 7.5.3, celui qui plantait plus vite que son ombre !

Je ne pense pas qu'il y ait un tel gouffre, intellectuel du moins, entre C++ et Obj-C.

Presque autant qu'entre C++ et Java ...

 

[yduc]

Presque autant qu'entre C++ et Java ...

Du peu que je connaisse de Java, le langage en lui-même n'est pas révolutionnaire, si ce n'est tout de même qu'il supprime les pointeurs (si j'ai bien compris). C'est surtout sa compilation vers un assembleur virtuel qui constitue la véritable révolution, technique donc et non intellectuelle, ainsi que la présence en standard de librairies pour construire l'interface utilisateur. (non ?)

Quant au gouffre entre C++ et Obj-C, je trouve que les arguments des différents intervenants, dans la discussion "Quel langage choisir ?", sont peu convaincants (même si je vous sens convaincus, nuance ;-)). Finalement, c'est Cocoa qui vous enthousiasme, pas Obj-C. Mais peut-être qu'à l'usage je comprendrai en quoi il y a un monde entre C++ et Obj-C... En attendant, je me mange de la doc en anglais jusqu'à plus soif !

Yves

 

[ntx]

Finalement, c'est Cocoa qui vous enthousiasme, pas Obj-C.

Tout à fait car je pense que Java a autant de capacités "runtime" que Obj-C. Mais Cocoa est fantastique

Mais pour y avoir été confronté, le fait d'avoir un code "décompilable" est un gros désavantage en défaveur de Java pour des applications commerciales, tout comme les performances de la JVM sur certaines plateformes ... Vous voyez sûrement de quoi je veux parler

Par contre gros point fort de Java : les environnements de développement, Eclipse et surtout IntelliJ, qui sont formidables. Apple a encore du boulot pour rendre XCode plus agréable à utiliser.