[EN] [IT]
  [INFO] [ACQUÉRIR] [PLAN] [RESSOURCES]


DU CÔTÉ DE CARBON

1 - Mais enfin c'est quoi ce machin appelé Carbon ?
[Ou, quelques pépins dans l'histoire de la pomme]

Si je devais commencer logiquement en décrivant en détails les diverses tentatives et tribulations d'Apple dans sa recherche d'une suite pour le Mac OS -- ou Système comme nous avons l'habitude de l'appeler depuis ce jour de l'an 1983 où, pour la première fois, quelqu'un alluma un Mac qui le gratifia d'un cordial "Bienvenue sur Macintosh" -- je pourrais écrire au moins cinq épisodes avant d'en arriver à Carbon. Et même là, je devrais simplifier un peu... je vais donc aller très vite; attachez vos ceintures.

En préambule, il y a d'abord l'importante et non-négligeable question du 'Pourquoi changer'. Je veux dire par là que la majorité des utilisateurs du Mac étaient contents avec un Système qu'ils connaissaient et maîtrisaient, et qui la plupart du temps faisait ce qu'on lui demandait. C'est exact, jusqu'à un certain point... chaque version successive du Système déployait des trésors de magie; et tout semblait couler de source et les lapins sortaient des chapeaux au bon endroit et au bon moment. Comme disaient les ingénieurs logiciels, avec le temps, le Système s'était encroûté, couturé de rustines de-ci, de-là, qui fâcheusement se décollaient de temps à autre; de sérieux doutes se propageaient sur le temps qu'il resterait à Apple avant l'effondrement de ce château de cartes au premier courant d'air venu à la suite d'une injection de nouvelles fonctionnalités. Il y avait aussi d'autres interrogations autour de l'impopulaire multitâche coopératif employé par le Mac, ou de sa protection de la mémoire considérée un peu légère, en particulier lorsqu'une application en chute libre entraînait, les autres avec elle dans sa débâcle. Mais enfin, c'était le Système que nous lui avions toujours connu, non ? Cela faisait partie du privilège d'utiliser un Mac, n'est-ce pas ?

Apple décida qu'elle allait offrir au monde un 'OS moderne'. Beaucoup s'accordaient sur le fait qu'une telle engence devait inclure une mémoire protégée, mais aussi un multi-tâche préemptif nécessaire pour empêcher une application mal élevée de s'accaparer tous les cycles du processeur. Et tout ceci se devait d'être une base sûre mais flexible sur laquelle construire pour l'avenir.

Comme on le sait, avant d'acheter NeXT, Apple s'est attardée avec [ils ont des drôles de noms de code chez Apple] Pink, Copland, Taligent... jetant des dollars à fonds perdus dans des aventures qu'elle a fini par abandonner les unes après les autres. Sur le pourquoi de la décision qui a vu NeXT l'emporter sur BeOS, pour fonder un nouvel OS en portant NeXSTEP sur le Mac, personne n'a de réponse, à part Gil Amelio...

Peu importe. Voilà Apple avec en main NeXTSTEP qu'elle commence à transformer en nouveau Mac OS. Mais revenons à Carbon.
Carbon -- le nom a été choisi parce que c'est l'élément fondamental de la vie, rien moins que ça -- est apparu pour la première fois en tant que base de l'Appearance Manager [le gestionnaire d'Apparence]. À l'origine, c'était une tentative pour porter des Thèmes -- des éléments d'interface modifiables par l'utilisateur -- depuis Copland, le mort-né [je savais qu'il allait être difficile de ne pas parler des autres tentatives...]. Pour ce faire, une grande partie de la Toolbox -- les routines fondamentales que les programmeurs Mac peuvent appeler depuis leur code, et qui, en fin de compte, font qu'un Mac est un Mac -- devait être réécrite puisque le code touchant à l'interface était reparti à travers un nombre important de gestionnaires : le Control Manager, le List Manager, le Window Manager, le Menu Manager...

Ces Thèmes [Gizmo, Techno, etc.] furent aussi abandonnés en route, ou plus exactement, réduits à des variantes inoffensives de l'interface dite 'Platinum' [soi-disant lorsque Steve Jobs, de retour à la barre, assista à une démonstration de l'extension Kaleidoscope et vit le monstrueux bordel dont sont capables les utilisateurs quand ils se mettent à créer une interface. La démonstration d'ailleurs avait été organisée justement par le groupe d'ingénieurs en charge de l'interface afin de démontrer ô combien les Thèmes étaient 'cools'!].

Quoi qu'il en soit, l'Appearance Manager était arrivé et comme il n'y avait pas encore d'applications exploitant ses fonctionnalités dont il fallait tenir compte, ce fut la première occasion pour Apple de remplacer d'anciens appels de la Toolbox par de nouveaux. La transition du 68K vers le PPC, n'avait été qu'un portage vers un processeur plus rapide. Les ingénieurs devaient même prendre soin de reproduire exactement les bizarreries et bogues documentés de l'ancienne Toolbox tant il y avait d'applications en circulation qui en tenaient compte!

À mesure que la route vers Mac OS X s'éclaircissait, la question du portage des applications existantes se manifestait de plus en plus fréquemment. OS X, comme vous vous en souvenez, a été construit à partir de NeXTSTEP, l'OS créé par NeXT, c'est-à-dire l'ancienne entreprise de Steve Jobs. Bien qu'il existât divers compilateurs pour réaliser des applications NeXTSTEP, la voie consacrée passait par Interface Builder, un croisement entre un framework et un outil de développement rapide anabolisé, écrit en Objective-C, une sorte de C++ en plus élégant.

Donc, un jour Apple annonça que les programmeurs devaient réécrire leurs projets en Objective-C afin de tourner sous OS X. "Oui Coco, et l'après-midi je ferai du ski..." fut le genre de réaction enthousiasmante suscitée par cette proposition.

Après d'âpres discussions, et probablement la considération de la "réjouissante" perspective d'un OS flambant neuf avec seulement une ou deux applications portées à la hâte depuis NeXTSTEP pour le faire rutiler, Apple décida qu'il serait absolument fabuleux -- après tout -- de fournir un moyen plus facile pour les applications Mac existantes de se préparer pour le grand jour. En bref, il s'agissait de trouver le moyen de faire tourner l'ancienne Toolbox sur le nouvel OS. À la même époque, des ingénieurs étaient déjà passablement occupés à créer un environnement spécial, appelé alors la Blue Box [la boîte bleue], connu aujourd'hui sous le nom de Classic. Il était prévu pour être le lieu de cohabitation des logiciels écrits pour les anciens Systèmes, mais sans les nouvelles fonctionnalités de Mac OS X [les applications pouvaient toujours s'accaparer le processeur, bomber et faire bomber les autres, mais seulement dans la partie du Mac qui leur était réservée... Classic].

Toutefois, comme la réécriture de la Toolbox avait déjà été abordée pour l'Appearance Manager, il n'y avait qu'à reprendre le travail là où il en était resté, l'étendre et l'appeler Carbon. Nous avions dès lors trois manières d'aborder le nouvel OS: une boîte de compatibilité -- Classic --, et deux approches 'natives'; Objective-C -- incluant Java qui lui avait emprunté son modèle objet-- et qui tournait à partir d'une Toolbox appelée Cocoa [peut-être parce que ce breuvage est plus doux que le café, qui sait ?], et maintenant Carbon.



the gnome
26/02/2002

[haut de la page]

2 - Mais est-ce que Carbon est de la vraie programmation pour Mac OS X ?
[Et, pourquoi je ne peux pas avoir de fenêtres tiroirs?]

Nous avons vu qu'Apple avait décidé de proposer des chemins différents pour aborder X: Classic, qui n'est en somme qu'une application contenant la boîte de compatibilité; Cocoa et puis Carbon qui sont sur un pied d'égalité eu respect à Mac OS X. Chacun emploie son équivalent de la Toolbox. Le système voit une application Cocoa et une application Carbon comme deux process différents, mais égaux, qui s'exécutent dans le même environnement protégé et de ce fait, elles en ont tous les avantages particulièrement si une application vient à perdre la boule. Une anecdote: d'après Apple, certaines parties de la Toolbox de Cocoa ne sont que de simples emballages vers des appels de la Toolbox de Carbon. Aussi, quiconque vous raconte que Cocoa est l'environnement priviligié pour la programmation sous Mac OS X, celui-là a dû faire un séjour prolongé dans un champ de distortion de la réalité.

Cocoa est donc un environnement orienté-objet employant le modèle objet d'Objective-C. Objective-C et Java sont donc logiquement ses langages privilègiés. Pour assister les programmeurs dans cet environnement, Apple fournit son portage de l'Interface Builder provenant de NeXT. Comme tout ceci possède un héritage NeXT très fort, c'est naturellement dans Cocoa que nous trouvons des applications généralement conçues à l'origine pour ce Système. Nous y trouvons également quelques nouvelles créations de programmeurs qui ont eu envie de s'essayer à ces nouveaux outils.

Le chemin vers Carbon passait par Mac OS et le gestionnaire d'Apparence. Par conséquent, de ce coté-ci, nous trouvons les applications que nous avons appris à connaître, à aimer [ou haïr dans le cas de MS Office... :-) ] et à utiliser sur nos machines. Apple fournit aussi, aux programmeurs Carbon, des appels pour accéder aux fichiers d'Interface Builder [.nib, pour Next Interface Builder] depuis Carbon.

De part leurs origines distinctes, mais aussi du fait des contraintes de temps dans leur réalisation, la Toolbox de Carbon et celle de Cocoa présentent de mineures différences quant à leurs possibilités, par exemple la disponibilité des fenêtres tiroirs [drawer windows]. Apple a promis qu'avec le temps ces disparités disparaîtraient. D'ici-là, ces fameuses fenêtres tiroirs [plus petites avec des coins arrondis et qui glissent depuis le côté d'une fenêtre-mère] ne sont pas accessibles aux applications Carbon.

Un développeur venant depuis le Système Mac a tout intérêt à employer Carbon pour porter un projet sous X. Il n'a rien à gagner à suivre la route Cocoa; il lui faudrait apprendre un nouveau langage, un nouvel environnement de développement, et jeter au panier son code existant. Certainement plus de désavantages que le contraire...

FutureBASIC vous offre deux manières d'aborder Mac OS X et elles passent toutes deux par Carbon. Les applications créées par FutureBASIC sont des applications Mac OS X à part entière, tout comme Office, iPhoto ou Photoshop.

Carbon présente aussi un autre avantage: tout le monde ne ressent pas le désir ou le besoin de passer à Mac OS X. Si vous utilisez Carbon pour créer vos applications, elles tourneront naturellement sous Mac OS X, mais aussi sous Mac OS 9, ainsi que, à quelques exceptions mineures près, sur des Systèmes à partir du 8.6 si le fichier CarbonLib se trouve dans le Dossier Système . Ainsi vos utilisateurs pourront choisir le meilleur des deux mondes.


[haut de la page]

3 - Et tout cela change quoi pour les utilisateurs de FutureBASIC?

Pas grand chose. Mais ce pas grand chose peut vous occuper un petit moment...

Examinons trois situations.

a) Les applications existantes

Les applications que vous avez créées avec une release antérieure de FutureBASIC tourneront dans la boîte de compatibilité Classic. Il peut y avoir des problèmes mineurs, mais 99% d'entre elles fonctionneront parfaitement.

Qu'est-ce qui est susceptible de ne pas tourner correctement?

Classic fait de son mieux pour laisser croire à votre application qu'elle tourne sur un Mac ordinaire sous Mac OS 9. Apple a beaucoup d'expérience dans ce domaine, pensez à la transition vers le PPC... La plupart du temps cela fonctionne. Il peut y avoir des problèmes de rafraîchissement de fenêtres, car les applications Classic sont présentées à l'écran par le nouveau moteur d'affichage appelé Quartz. Vos applications vous paraîtront certainement plus lentes que si elles étaient exécutées sur un ordinateur équivalent n'utilisant que Mac OS 9. Quelques extensions et tableaux de bord ne seront plus op&eactue;rationnels. Et vous trouverez peut-être irritant, à l'occasion, de voir le Dock cacher certaines parties de vos fenêtres. Dans l'ensemble, ces changements sont moins désagréables que les incompatibilités qui apparaissent avec chaque nouveau Système. Sur un plan personnel j'utilise toujours des applications que j'exploitais déjà sur mon premier Mac 128 en 1984 et qui tournent sans aucun problème dans Classic sous Mac OS X.

b) Les applications existantes que vous désirez porter sur Mac OS X

Dans ce cas de figure, votre application a été écrite soit avec le Runtime Standard, soit avec PG. La bonne nouvelle, c'est que les deux ont été réécrits afin de générer du code pour Carbon. Dans le meilleur des cas, cela veut dire une recompilation et hop! ça tourne sous Mac OS X.

Andy Gariepy, assisté par certains beta-testeurs parmi les plus pointus, a réalisé une oeuvre de maître en amenant le Runtime Standard à générer du code compatible Carbon de manière transparente. Il émule même certains des appels abandonnés par Apple vous épargnant ainsi la douloureuse tâche de modifier vous-m?me votre code! De plus, le processus de carbonisation a éliminé quelques bogues et situations critiques résiduels [du genre de ceux qui n'apparaissent que le second jeudi du mois, ou qui se manifestent si vous ne suivez pas les règles à la lettre]. Très peu de fonctions n'ont pas pu être ranimées de cette manière.

Alain Pastor de l'équipe euro.fb a préparé un document détaillé sur le portage de votre code vers Carbon. Vous pouvez trouver ce document ici.

Il y avait deux points qui manquaient dans son document (du moins quand je l'ai lu :-):

  • Dans Mac OS X, il n'est plus possible d'attribuer la mémoire requise pour l'exécution de votre application. Ceci est géré maintenant de manière dynamique par le Système. Les fuites de mémoire [memory leak] seront donc plus difficiles à détecter car, dans l'absolu, vous ne supecterez pas le problème tant que la pagination continuelle de la mémoire n'aura pas poussé la machine à au bord de l'asphyxie [la pagination mémoire -- un héritage Unix -- est l'échange de blocs de données entre la mémoire vive et le disque -- C'est l'équivalent de la Mémoire Virtuelle sous Mac OS X. Il sera donc judicieux de prévoir une séance de débogage sous Mac OS 9.

  • Il y a un autre point, probablement le plus difficile pour un programmeur: les applications dans Mac OS X évoluant dans l'interface Aqua, n'ont plus l'apparence que vous leur connaissez. Il est presque certain que vous serez obligé de reconcevoir les éléments de votre interface utilisateur. La bonne nouvelle ici, c'est qu'il y a pléthore de nouveaux contrôles à utiliser.

c) La programmation pour Mac OS X

Vous voulez démarrer un nouveau projet ou bien effectuer une mise à jour majeure d'un projet existant; dans ce cas, c'est le moment opportun pour faire connaissance avec le nouveau Runtime Appearance.

Voici quelques conseils. Cette liste, assez courte, ne peut pas tout traiter, votre besoin peut être tout à fait spécifique, mais rien dans ce qui suit ne peut vous faire de mal.

Les premiers pas:

  • 1) Lisez le manuel de Référence FutureBASIC.

    Il n'y a que les surdoués qui pourraient tout retenir, mais cette lecture devrait vous donner une vue d'ensemble et vous aider à vous rappeler où se trouve tel ou tel sujet pour y revenir ultérieurement. [Une astuce: pour trouver les nouveaux mots-clés dans le document, cherchez la mention 'Release 6'].

  • 2) Familiarisez-vous avec le Runtime Appearance.

    Prenez des fichiers d'exemples, faites-les tourner, changez des choses ici et là, retirez des fonctions pour voir. Vous constaterez que c'est toujours le même FutureBASIC, mais avec une foule de nouveautés. Les connaître toutes peut prendre un certain temps.

  • 3) Fabriquez-vous un petit squelette de programme.

    Un framework où vous pourrez tester les nouveaux contrôles. J'en ai un qui tourne; il ne fait pas grand chose mais je sais que je peux y rajouter du code et des fonctions et les problèmes -- s'il y en a -- seront nécessairement dans ces rajouts et pas dans le squelette. C'est vraiment pratique pour tester de nouvelles fonctionnalités aussi bien que vos fonctions utilisateur.

  • 4) Lisez tous les documents sur Carbon que vous pouvez trouver

    Encore une fois, vous ne pourrez guère tout retenir, mais cela aidera à s'imprégner mentalement des nouvelles possibilités et des endroits où chercher des infos complémentaires. Vous trouverez une liste de liens URL à la fin de ce document.

    Jusqu'ici, tout ceci n'a en rien aidé votre application, mais cela devrait vous permettre de vous familiariser avec Appearance/Carbon/Aqua.

    Si vous souhaitiez commencer un nouveau projet, vous devriez être en train de piaffer d'impatience maintenant. Donc, retournez à votre framework, rajoutez-y des fonctionnalités jusqu'au moment où le résultat s'approche de votre but.


    Si vous cherchez à porter du code vers le runtime Appearance, continuez la lecture.



  • 1) Commencez par effectuer une copie de sauvegarde de votre projet. C'est étonnant le nombre de gens qui commencent une nouvelle session de travail avec leur code d'origine. Si quelque chose va de travers à un moment donné, vous aurez besoin de revenir à une version opérationnelle, n'est-ce pas ? Et n'oubliez pas de faire à chaque étape des sauvegardes régulières, et en lieu sûr.

  • 2) La plupart des applications collectent des données de l'utilisateur [un logiciel de peinture, un traitement de texte, un logiciel de comptabilité...] ou depuis une source extérieure [un navigateur web...] ou encore des deux à la fois [récolter les données météo puis afficher celles relatives à une zone choisie par l'utilisateur...]. Dans votre application, l'organisation de ces données est l'affaire de votre 'moteur'. L'affichage des informations et l'interaction avec l'utilisateur est l'affaire du 'front end'. Il est sage de séparer ces deux parties dans vos programmes [Si vous avez utilisé PG pour faire votre application, alors c'est déjà le cas, Staz a été étonnamment préscient sur ce point]. Vous constaterez que les changements entraînés par Aqua se concentrent sur le front end, dans la collecte des informations auprès de votre utilisateur et dans l'affichage. Le moteur ne changera pas fondamentalement.

  • 3) Une des choses les plus importantes avec Carbon est de ne pas créer ou déplacer un contrôle lors d'un événement de rafraîchissement. Sous Carbon, tout se qui s'affiche est d'abord bufferisé puis transféré à l'écran lors des événements de mise-à-jour. Aqua procède de cette manière afin d'afficher l'ombre des fenêtres ou la transparence des menus lorsqu'ils sont déroulés. Si vous créez un contrôle, par exemple, dans une routine gérant le rafraîchissement, vous risquez de vous piéger dans une boucle sans fin. Alors vérifiez soigneusement que vous avez bien séparé le code du moteur d'avec celui de l'interface. Depuis des années, Staz Software n'a eu de cesse de nous prévenir sur ce point, mais le Standard Runtime faisait un si bon boulot pour nous protéger des conséquences néfastes de nos actions que nous pourrions avoir tendance à ignorer ses avertissements.

  • 4) Faites une liste de toutes les fenêtres et boîtes de dialogue de votre application. Prenez une feuille de papier quadrillée et redessinez-les telles qu'elles doivent apparaître sous Aqua. De nouveaux contrôles peuvent vous permettre de présenter les choses plus efficacement, vous serez étonné des possibilités. Auparavant, il fallait parfois bidouiller, ou créer ses propres CDEFs. Mais attention, les contrôles sous Aqua exigent plus de place. Vos fenêtres devront soit être agrandies, ou contenir moins d'éléments.

    Si vous avez une application conséquente, vous pourriez éventuellement vouloir regrouper les fenêtres, ayant des traits communs, par 'famille'. Dans ce cas, travaillez d'abord sur un membre représentatif de la famille, et faites en sorte qu'il se comporte correctement dans votre squelette de programme. Tout ce que vous aurez à faire ensuite est de dupliquer ces fenêtres et les adapter pour les autres membres de la famille. Quand chaque fenêtre se comporte correctement n'oubliez pas de sauvegarder votre projet.

  • 5) À la fin de cette étape, vous devriez avoir une version alpha fonctionnelle de votre projet. C'est le moment de connecter le moteur avec les autres fonctionnalités... vous serez surpris par les facilités qu'offre le Runtime Appearance: vous avez maintenant des fonctions 'en boîte' qui peuvent s'occuper de détails tels que la lecture ou l'écriture des fichiers de préférences, le balayage des dossiers à la recherche d'un fichier, même l'intégration du nouveau Presse-Papiers pour Carbon est largement une affaire de couper/coller depuis les exemples. Par le passé, tous ces traitements prenaient un temps considérable à intégrer et déboguer.

    Nous prévoyons de mettre en place des ateliers sur la programmation Carbon avec le Runtime Appearance et de préparer d'autres documents. Nous comptons aussi faire des séances de questions/réponses, alors préparez vos questions.



    URLS:


  • [haut de la page]

    Les opinions exprimées et les conseils offerts dans les documents relatifs à Carbon sont ceux de leurs auteurs et n'engagent en rien la responsabilité de STAZ Software. Spécialement lorsqu'ils ont été écrits par les doigts boudinés d'un gnome.

    Bonne programmation.



      © 2000 Pix&Mix  
      Tous droits réservés
    INFO  |  ACQUÉRIR |  PLAN  |  RESSOURCES

      FutureBASIC est une marque déposée appartenant à Staz Software, Inc et utilisée avec permission.