Par Apple Computer, Inc. © 2003,

Traduit par Mactov, 14/09/2003.

Introduction

Introduction | Graphisme 2D | Graphisme 3D | Multi-processeurs | Réseaux | Texte | Internationalisation | Impression | Interface utilisateur

Apple fournit de nombreuses ressources aux développeurs pour créer des applications pour Mac OS X, et celles que vous choisirez d’écrire dépendront de vos besoins, préférences ou contraintes. Si vous ne connaissez pas bien la plateforme, le démarrage peut être laborieux et coûteux en temps avant de trouver la bonne méthode.

Le but de ce guide est de vous mettre sur les bons rails pour porter une application C/C++ écrite avec l’API Win32 vers Mac OS X. Vous êtes, bien entendu, encouragés à parcourir les différentes API fournies par Apple afin de choisir ce qui correspond le mieux à vos besoins.

La première étape va consister à vous familiariser avec les environnements matériels et logiciels de Mac OS X qui sont très différents de l’environnement Windows. Il y a deux livres que vous devez absolument lire (en anglais) : Inside Mac OS X: System Overview et Inside Mac OS X: Aqua Human Interface Guidelines. Un troisième livre (lui aussi en anglais), Learning Carbon, est aussi tout particulièrement recommandé car il enseigne le développement Mac OS X au moyen d’une simple application en C. Vous trouverez plus de détails sur ces livres à la rubrique “Compléments d’information” au bas de cette page.

Après une courte présentation de différents concepts importants, ce guide vous présentera les API que vous aurez probablement à utiliser dans les domaines suivants :

• Introduction
• Graphisme 2D
• Graphisme 3D
• Multi-processeurs
• Réseaux
• Texte
• Internationalisation
• Impression
• Interface utilisateur

Présentation Générale

Pour bien assimiler les recommandations fournies dans ce guide de portage des applications Win32 vers Mac OS X, vous devez tout d’abord comprendre en quoi les aspects matériel et logiciel de Mac OS X diffèrent de leurs homologues Windows. Les ressources présentées dans l’introduction de ce papier sont votre meilleure source d’information. Néanmoins, les paragraphes suivants présentent les concepts clés de Mac OS X qu’il vous faut connaître avant d’aller plus loin dans ce guide.

Mac OS X

Bien entendu, LA grande nouvelle c’est Mac OS X lui-même et le fait qu’il s’appuie sur Darwin, une version BSD d’Unix. Ce qui implique que Mac OS X tire profit d’un système Unix robuste, incluant mémoire protégée, multi-tâche préemptif, services système BSD et l’ensemble des outils BSD.

Mac OS X implémente la plupart des API POSIX, ce qui vous permet d’accéder à de nombreux outils ou bibliothèques Unix. De plus, vous pouvez même appeler directement des routines POSIX depuis les environnements Carbon et Cocoa (qui sont décrits plus loin) et réciproquement (dans certains cas seulement).

Aqua et le Finder

Au dessus de ses fondations Unix, Mac OS X implémente une couche graphique que l’utilisateur va manipuler dans son activité quotidienne. Celle-ci comprend l’interface graphique Aqua et le Finder, l’application “première” à travers laquelle les utilisateurs trouvent et gérent leurs répertoires, applications et documents. Les utilisateurs Macintosh sont particulièrement sensibles au look et au comportement de leurs applications, vous devez vous assurez que vos applications portées sont conformes à leurs attentes.

Bien que l’interface d’Aqua diffère sensiblement du “look” Windows, les éléments constitutifs des deux plateformes sont très similaires.  Le comportement de certains composants Aqua  diffèrent cependant assez subtilement de leurs homologues Windows aussi vérifiez bien les spécifications décrites dans Inside Mac OS X: Aqua Human Interface Guidelines pour vous assurez que votre programme se comportera bien comme l’attend l’utilisteur Mac.

L’architecture du système de fichiers

Puisque Mac OS X se fonde sur Unix, le système de fichiers est régi par le classique système de permissions Unix propriétaire/groupe/autres. La possibilité pour un utilisateur d’accéder et de modifer un fichier est liée à ses droits et au système de permissions.

En outre, Mac OS X permet d’assurer l’intégrité du système de fichier et sa sécurité au moyen des domaines de systèmes de fichiers multiples. Il y a quatre domaines ur un ordinateur tournant sous Mac OS X: utilisateur, local, système et réseau. Chacun de ces domaines a des besoins différents en terme d’accessibilité et de sécurité. Chaque emplacement sur votre ordinateur ou sur le réseau appartient à un des quatre domaines et Mac OS X affecte automatiquement à un fichier des permissions en fonction du domaine auquel il appartient.

Bien que Mac OS X utilise par défaut le système Apple, Hierarchical File System Plus (HFS+), Mac OS X reconnait aussi le système de fichier standard de BSD (UFS), NFS (un standard de l’industrie pour les systèmes de fichiers en réseau), ISO 9660 (utilisé pour les CD-ROM), MS-DOS, smb (un format de partage avec Windows), AFP (le système de partage de Mac OS), et le format UDF (utilisé sur les DVD).

Un point sur lequel il faut revenir est la sensibilité à la casse du système de fichiers HFS+. Pour des raisons historiques, HFS+ est insensible à la casse mais préserve la casse (par opposition à la plupart des systèmes Unix qui, eux, sont toujours sensibles à la casse). Préserver la casse signifie que le code qui sous-tend le système HFS+ ne changera pas la casse des noms de fichiers mais que les comparaisons de noms se font elles indépendamment de la casse.

Les environnements applicatifs

Mac OS X fournit plusieurs environnements applicatifs c’est à dire plusieurs environnements que vous allez pouvoir utiliser pour développer vos applications. Vous trouverez :

• Cocoa : un ensemble d’API orientées objet implémentées en Objective-C,
• Carbon : un ensemble d’API procédurales issues des interfaces du système classique Mac OS,
• Java : les API de la plateforme du langage de Sun,
• BSD : les API mises à disposition via Darwin, la partie Open Source de Mac OS X,
• Classic : un environnement d’éxécution pour permettre d’accéder aux applications écrites pour Mac OS 9 ou une version précédente

Nous vous recommendons vivement de développer le plus possible dans l’environnement Cocoa. Cependant, Carbon est un bon choix si votre application est déjà écrite en C ou C++ de façon procédurale (par opposition à orienté objet).

La gestion des évènements Carbon

La gestion des évènements dans Carbon devrait être facile à comprendre pour quelqu’un qui connait la programmation d’applications Win32. Et, bien que le modèle d’évènements Carbon utilise un vocabulaire différent et présente de réelles différences par rapport à son équivalent Win32, la structure générale d’une application Carbon est très proche de celle d’une application Win32. Dans les deux cas, le système d’exploitation envoie à l’application les évènements qui lui appartiennent et les dirige vers les cibles appropriées. Chaque cible possède sa propre routine logicielle. Quand une cible reçoit un évènement, sa routine associée traite cet évènement ou le retourne au système qui va le gérer selon une procédure standard.

Les références aux évènements (event reference)

L’équivalent Carbon d’une structure Win32 MSG est un évènement (event) qui est va être manipulé par une type de données appelé une référence à évènement (event reference). Dans Carbon, un évènement est une structure de données opaque (à laquelle on fait référence via un EventRef), tout comme on le fait avec un HANDLE de fenêtre dans Win32. Opaque, parce que l’on ne sait pas comment il est défini en interne, mais le système d’exploitation fournit des moyens pour accéder aux données associées. Carbon vous permet de récupérer certaines données d’un EventRef à savoir :

• La classe de l’évènement, qui définit la source de l’évènement (par exemple, le clavier, un contrôle, ou le menu système)
• Le type d’évènement qui identifie l’évènement dans une liste d’évènements
• Le moment où c’est produit l’évènement
• Des paramètres spécifiques à l’évènement (dont le nombre et la nature sont fonctions de l’évènement)

Carbon propose des fonctions pour récupérer la classe, le type et le moment d’un évènement. De plus, dès que vous connaissez l’évènement auquel vous avez à faire, vous pouvez obtenir la valeur associée à chacun des paramètres associés au moyen de la fonction de Carbon Event Manager GetEventParameter. Vous pouvez vous servir de cette fonction pour obtenir la valeur d’un paramètre en spécifiant (entre autres choses) le nom et le type du paramètre. Avec GetEventParameter, vous connaissez toujours le type de la valeur renvoyée.

Les cibles des évènements

Tout comme dans les applications Win32, diiférents types d’objets d’interface Mac OS X (des fenêtres, des contrôles, des listes déroulantes par exemple) peuvent recevoir des évènements. Ces objets d’interface sont appelés des cibles d’évènement (event targets) Qaund un évènement a lieu, sa référence est adressée à  la plus spécifique des cibles qui puisse traiter cet évènement ou le passer à une cible moins spécifique. Par exemple, un clic de souris sur un bouton dans une fenêtre est passé au bouton et non à la fenêtre qui l’englobe (qui est moins spécifique).

Les descripteurs d’évènements (Event Handlers)

Dans une application Win32, chaque fenêtre a une procédure de fenêtre associée à sa classe fenêtre dès qu’elle est initialisée. Quand un évènement appartenant à cette fenêtre a lieu, le système fournit les données de l’évènement à la procédure, et celle-ci s’éxécute. Si la procédure ne sait pas comment gérer cet évènement, c’est le système qui va s’en charger en éxécutant la procédure DefWindowProc.

L’environnement Win32 manipule les évènements à partir de code situé au niveau de la fenêtre, en d’autres mots, une procédure de fenêtre contient le code qui va gérer les évènements appartenant à cette classe fenêtre. Par opposition, Carbon décrit les évènements au niveau de l’évènement lui-même, ce qui signifie que vous écrivez le code qui va gérer un évènement ou groupe d’évènements, puis vous liez ce code à une cible donnée.

Une partie du travail d’initialisation d’une cible consiste donc à installer tous ses descripteurs d’évènement, en créant ce qu’on appelle une pile de descripteurs (handler stack). Quand un évènement est transmis à sa cible, la cible le passe à sa pile de descripteurs, et le premier descripteur capable de gérer l’évènement s’en charge. Chaque cible d’évènement a un descripteur par défaut (situé au-dessous de la pile) qui représente le comportement par défaut d’une classe donnée de cibles.

Par son utilisation des descripteurs d’évènement, Carbon offre un meilleur niveau de contrôle que ne le fait Win32. Cependant, pour faciliter le portage, vous pouvez adapter vos procédures de fenêtres existantes pour qu’elles fonctionnent dans l’environnement Carbon. Pour cela, vous devez l’installer de telle sorte qu’il manipule tous les évènements de la cible concernée.

Le tableau suivant résume les différences structurelles dans la gestion des évènements entre Win32 et Mac OS X:

	Win32	Mac OS X
Mécanisme  de récupération des évènements	Structure MSG	Référence à un évènement
Nom du descripteur	Procédure de fenêtre	Descripteur d’évènement
La façon d’associer un descripteur à une cible	Spécifié comme paramètre quand une classe de fenêtre est instanciée	InstallEventHandler appelé pendant l’initialisation de la cible (fenêtre, bouton, …)
L’identifiaction d’un évènement spécifique	Champ message de DefWindowProc	sorte d’évènement (dérivé du type d’évènement)
Traitement des évènements non-traités	La procédure de fenêtre appelle DefWindowProc	le descripteur d’évènement renvoie une valeur “non décrit”

Interface Builder et Project Builder

Un bundle d’applications est un ensemble de fichiers hautement structuré qui doit être correctement configuré afin qu’une application fonctionne. Il est recommandé d’utiliser Interface Builder et Project Builder pour développer toutes vos applications Mac OS X. Ces deux applications incluent de nombreux outils qui

• facilitent les processus de conception, développement et compilation, débogage de votre application,
• organisent les fichiers nécessaires à votre application,
• vous permettent de créer des bundles applicatifs en réglant pour vous les détails de bas niveau.

Interface Builder

Cette application fournit une IGU (Interface Graphique Utilisateur) pour les tâches suivantes:

• construction des fenêtres et menus de votre application à partir d’une palette d’éléments d’interface,
• personnalisation de ces éléments selon vos besoins,
• identification de ces éléments pour que votre code puisse leur faire référence.

Vous allez utiliser Interface Builder pour porter l’interface de votre application aux standards d’une application Mac OS X. Interface Builder stocke le résultat de votre travail dans un fichier “nib”. Plus tard, votre application terminée lira ce fichier pour re-créer l’interface de votre application.

Project Builder

Project Builder est l’EDI (Environnement de Développement Intégré) d’Apple pour créer, concevoir, déboguer et déployer toutes sortes d’applications Mac OS X. Pour porter des applications Win32, vous devriez l’utiliser pour créer une application Carbon basée sur un (ou des) fichier(s) nib.

Quand vous créez un nouveau projet, Project Builder crée un dossier pour votre projet et génère automatiquement certains dossiers et fichiers. Ce dossier contient tous les fichiers associés à votre application, afin de vous faciliter les sauvegardes et déplacements de votre projet.

Project Builder utilise le compilateur gcc de la collection de compilateurs GNU, vous pouvez donc utiliser Project Builder pour des projets écrits en C, C++ et Objective-C (tout comme Java et d’autres langages). Project Builder analyse vos fichiers sources à chaque construction et crée le fichier make automatiquement, vous n’aurez donc pas à en créer un ni à le faire évoluer par vous-même.

Une autre étape de la construction consiste pour Project Builder à créer un bundle qui rassemble tous les fichiers associés à votre application. Ainsi, dès que votre projet sera construit avec succès, vous pourrez le déployer instantanément en déplaçant l’icone du bundle à l’endroit désiré.

Les bundles

Un bundle est un répertoire dans le système de fichiers de Mac OS X qui contient à la fois du code éxécutable et des ressources liées à ce code, mais il apparaît dans le Finder comme une icône simple. Il y a différents types de bundles. Vous serez surtout intéressés par le bundle d’application, qui est utilisé pour contenir et distribuer des applications Mac OS X.

Les bundles réduisent les confusions pour l’utilisateur et évitent les amalgames compliqués de fichiers. De plus, ils permettent d’être sûr que l’application utilise toujours la bonne version des bibliothèques nécessaires et rendent possible l’intégration, au sein même de l’application, de plusieurs versions localisées.

Quand les utilisateurs double-cliquent l’icone d’un bundle d’application, Mac OS X éxécute l’application associée. Mac OS X utilise les bundles pour stocker une application et tous les fichiers associés, y compris les chaînes de caractères dans différentes langues, les images, les plug-ins, les librairies partagées, les frameworks et divers fichiers de données (appelés généralement ressources).

Compléments d’information

L’un des buts de ce guide est de vous amenez aussi rapidement que possible vers les ressources qui vous permettront de développer rapidement avec Mac OS X. A moins que vous soyez très familier avec l’architecture de Mac OS X, vous devriez commencer par lire Inside Mac OS X: System Overview. Une version PDF de ce livre est disponible gratuitement sur le site internet d’Apple (en anglais).

Pour finir, vous devriez aussi lire le livre Inside Mac OS X: Aqua Human Interface Guidelines pour comprendre l’interface utilisateur de Mac OS X. Inside Carbon est aussi un bon livre à lire car il vous présente la bonne méthode pour réaliser une application simple pour Mac OS X.

Ce paragraphe, “Compléments d’information”, se trouve à la fin de chaque page de ce guide et fournit des liens vers les principales documentations disponibles pour migrer vos applications Win32 vers Mac OS X. Afin de vous faciliter la prise en main de Mac OS X, Apple fournit cette documentation et ses outils gratuitement. (Apple fait cependant payer l’accès aux conférences filmées de la Conférence Modiale des Développeurs, et les versions imprimées de la documentation sont disponibles à la vente sur le site http://www.vervante.com/apple.)

Inside Mac OS X: System Overview (Nécessaire)	(HTML) http://developer.apple.com/techpubs/macosx/Essentials/ SystemOverview/index.html (PDF) http://developer.apple.com/techpubs/macosx/Essentials/ SystemOverview/SystemOverview.pdf (Version papier) http://catalog.vervante.com/browseGroup.cfm? item_group_id=61316
Inside Mac OS X: Aqua Human Interface Guidelines (Nécessaire)	(HTML) http://developer.apple.com/techpubs/macosx/Essentials/ AquaHIGuidelines/index.html (PDF) http://developer.apple.com/techpubs/macosx/Essentials/ AquaHIGuidelines/AquaHIGuidelines.pdf (Version papier) http://catalog.vervante.com/browseGroup.cfm? item_group_id=61316
Le livre Learning Carbon (Hautement recommandé)	http://www.oreilly.com/catalog/learncarbon/ (publié par O’Reilly)
Apple Developer Connection (le programme de support d’Apple pour les développeurs; inclut un abonnement gratuit et l’accès à la suite d’outils de développement gratuits de Mac OS X)	http://developer.apple.com
La page des Outils de Développement	http://developer.apple.com/tools/index.html
La page pour débuter en programmation Carbon	http://developer.apple.com/techpubs/macosx/Carbon/newtocarbon/newtocarbon.html
Les sessions concernant Mac OS X de la Conférence Modiale des Développeurs (payant)	http://developer.apple.com/adctv/

Graphisme 2D et Mac OS X

Les graphismes 2D sont une partie importante de la plupart des applications. A l’exception des parties dessinées automatiquement de votre fenêtre par l’interface utilisateur, vous êtes chargé de dessiner tout ce qui apparaît dans la fenêtre de votre application. La partie de l’API Win32 dédiée à l’Interface Graphique (que nous appellerons plus simplement Win32/GDI) fournit des routines qui sont comparables à celles fournies par QuickDraw (l’environnement graphique historique d’Apple pour Mac OS), mais elles sont cependant organisées de manière différente.

Puisque ce guide est écrit à destination de programmeurs qui portent du code Win32/GDI existant vers Mac OS X, ce document va se focaliser sur la présentation de l’API QuickDraw, l’API de Mac OS X la plus proche structurellement de votre code existant. Cependant, suivant les cas, vous voudrez peut-être envisager l’utilisation de l’API Quartz 2D qui est beaucoup plus performante. Voyez le paragraphe “Introduction à Quartz 2D”, plus loin dans ce document, pour une courte présentation de Quartz 2D et ses avantages, qui inclut les graphiques vectoriels et indépendants de la résolution, les dessins basés sur des chemins et des transformations complexes et le support intégré de création de documents PDF.

Avertissement

Ce guide traite principalement  des API Win32/GDI et QuickDraw d’Apple qui sont toutes deux agées d’une bonne quinzaine d’années. Pendant ces années, elles ont toutes deux évolué pour fournir des possibilités graphiques en rapport avec les possibilités des ordinateurs de leurs époques. Les capacités des ordinateurs et de leurs cartes vidéos ont été mulitpliées par un facteur 100 (et même plus) depuis que ces deux environnements de dessins ont été créés. Cela implique que les deux API contiennent de vieilles routines obsolètes qui rendent plus compliqué le passage du code graphique de Win32/GDI vers la plateforme Mac OS X.

En raison de ces limitations, ce document fait des impasses sur certains aspects des deux environnements, en particulier, ceux qui ne sont plus d’un usage courant. Par souci de clarté, ce document ignore aussi certaines situations particulières et simplifie certains détails. Par exemple, ce document passe sous silence la notion de couleur indexée, puisque quasiement tous les ordinateurs, aujourd’hui, affichent les couleurs, 16 ou 24 bits, directement. De même, nous ferons référence aux bitmaps dépendant du périphérique (BDP, DDB en anglais) et aux bitmaps indépendants du périphérique (BIP, DIB en anglais) sous le nom unique de “bitmaps”, comme nous ne mentionnerons pas comment chaque plateforme mappe une couleur “pure” dans son équivalent le plus proche en fonction du périphérique d’affichage utilisé.

L’architecture graphique de Mac OS X

Le coeur de l’environnement graphique et de gestion des fenêtres de Mac OS X s’appelle Quartz. Pour atteindre ses différents objectifs (incluant l’implémentation de la compatibilité ascendante), Quartz est écrit en deux parties, une API de rendu (Quartz 2D) et un serveur de fenêtres (Quartz Compositor). Cette modulmarité permet à Quartz 2D de co-exister avec d’autres API, dont une est QuickDraw, l’API que vous utiliserez probablement quand vous porterez votre application Win32 vers Mac OS X.

Quartz 2D et QuickDraw

Le coeur graphique et l’architecture de fenêtres de Mac OS X s’appelle Quartz. Il est constitué de :

• Quartz 2D : une des nombreuses bibliothèques graphiques qui offre des graphiques 2D et des services de rendu graphique.
• Quartz Compositor : le serveur de fenêtres et Quartz Extreme, le composant qui utilise la puce d’accélération graphique de votre ordinateur.

Comme vous pouvez le voir sur le schéma ci-dessous, QuickDraw est une des bibliothèques graphiques que vous pouvez utiliser pour dessiner des graphiques sous Mac OS X.

Sous Mac OS X, QuickDraw donne l’impression de dessiner directement dans la mémoire, comme il le faisait dans les versions précédentes de Mac OS. En fait, il dessine dans un tampon “hors-écran”. Quartz Compositor récupère ensuite ce tampon “hors-écran” et le combine avec d’autres informations graphiques (par exemple, des ombres adoucies et la transparence de la fenêtre) pour produire l’image finale. Quartz Compositor fournit l’image finale au périphérique graphique de manière à réduire au minimum le temps d’affichage des changements, tout en maintenant la plus haute qualité d’image possible (en évitant les clignotements et autres désagréments visuels).

Note: Dans l’ancienne documentation Mac OS X, on présente Quartz 2D comme le composant de rendu graphique de Quartz, alors que Quartz Compositor est présenté comme le composant des services graphiques de Quartz.

QuickDraw et la couleur

Comme l’a fait la plateforme Win32, Mac OS a ajouté de nouvelles possibilités graphiques comme le matériel d’affichage évoluait. La version originale de QuickDraw, qui ne manipulait que des graphiques en noir et blanc codé sur un bit, a été remplacée par Color QuickDraw, plus puissant, qui gère à la fois les graphiques en couleurs indexées et directes. L’API Color QuickDraw est un sur-ensemble quasiment parfait de l’API originale, bien que quelques exceptions existent.

Inside Macintosh: Imaging with QuickDraw est le livre de référence que vous utiliserez pour apprendre à utiliser QuickDraw. Dans celui-ci le paragraphe sur Color QuickDraw et une extension par rapport au paragraphe de la version originale ; ce qui signifie que vous devez lire les deux, même si vous n’êtes intéressé que par Color QuickDraw.

Comparaison de Win32/GDI et de QuickDraw

Les deux problèmes rencontrés par quiconque découvre une nouvelle plateforme sont : Comprendre la philosophie générale que la nouvelle technologie met en oeuvre et les passerelles entre l’ancienne et la nouvelle technologie. Ce chapitre tente de résoudre les deux problèmes en présentant les grandes lignes de l’environnement de dessin QuickDraw et en comparant les deux plateformes dans des tableaux.

Les fenêtres

Quand vous programmez, vous avez besoin d’un moyen pour faire référence à une fenêtre. Sous Win32, vous identifiez une fenêtre par son contexte d’affichage. (Bien entendu vous manipulez parfois le contexte de périphériques de votre périphérique d’affichage mais ce guide, pour simplifier, utilisera systématiquement le terme “contexte d’affichage”). Dans QuickDraw, vous vous réfererez à une fenêtre au moyen de son CGrafPort (un raccourci pour “color graphics port” (qui doit pouvoir traduire en français par port de graphique couleur).

Dans QuickDraw, les instructions de dessin présentent de petites différences par rapport à leurs homologues de Win32. Alors qu’en Win32 les instructions de dessin prennent systématiquement un contexte d’affichage comme premier argument, les instructions QuickDraw ne le font pas. QuickDraw, lui, considère toujours qu’ une instruction de dessin concerne le port graphique courant. Ainsi, pour dessiner dans une fenêtre différente, vous devez d’abord la définir comme le port en cours (c’est à dire définir le CGrafPort de la fenêtre visée comme le port courant) puis éxécuter la commande de dessin pour la nouvelle fenêtre.

Il y a une autre différence de terminologie sur laquelle je dois attirer votre attention. Alors que dans Win32/GDI on ne parle que de bitmaps, qui peuvent être noirs et blancs (1 bit par pixel) ou en couleurs (plusieurs bits par pixel), les anciennes versions, comme l’actuelle d’ailleurs, des systèmes d’exploitaion Mac OS (et leurs documentations) utilisent deux termes distincts: bitmap pour une image noire et blanche, chaque pixel étant codé sur un bit et pixmap pour les images en couleurs.

Le tableau 1 résume les différences relatives aux fenêtres entre les environnments graphiques Win32/GDI et QuickDraw.

Tableau 1. Comparaison des objets courants liés aux fenêtres. Win32/GDI QuickDraw La structure de données permettant de dessiner dans une fenêtre est un contexte d’affichage ou un contexte de périphériques (abrégé ici en CA). La structure de données qui permet de dessiner dans une fenêtre est un port de graphique couleur, aussi appelé un CGrafPort. Un contexte d’affichage (en général) représente la zone cliente d’une fenêtre. un CGrafPort représente la zone cliente d’une fenêtre. Toutes les routines de dessin contiennent le nom du CA dans lequel elles dessinent. Les routines de dessin n’incluent pas de nom du CGrafPort. Au lieu de cela, vous devez définir une fenêtre comme le port graphique en cours et tous les tracés ont lieu dans le port courant. Un contexte de périphrique mémoire est utilisé comme un bitmap hors-écran. Pour dessiner dans un écran virtuel, vous devez créer un “monde graphique” , ou GWorld, et en faire le port courant. Tous les tracés suivants ont alors lieu dans ce “monde” jusqu’à ce que vous changiez le port courant. Il est possible, bien que non recommandé, d’accéder à et de modifier le bitmap associé à un CA. Il est possible d’accéder à et de changer le tableau de pixels associé à un CGrafPort. Voir le texte ci-dessous pour plus de détails.

Si vous êtes intéressé par le fait de modifier le tableau de pixels associé à un CGrafPort, regardez dans la documentation les routines suivantes: GetWindowPort, LockPortBits, GetPortPixMap, LockPixels, GetPixBaseAddr, GetPixRowBytes, UnlockPixels, et UnlockPortBits.

Les systèmes de coordonnées

Apple a toujours contrôlé à la fois le matériel et les systèmes d’exploitation de ses machines, et a donc toujours été en mesure de s’assurer que ses pixels sont “carrés” (c’est à dire que chaque pixel affiché sur l’écran est aussi large que haut). Ainsi, ceux qui conçoivent des interfaces avec QuickDraw n’ont pas à se préoccuper d’un double système de coordonnées logiques et matérielles, qui peuvent (sur certaines machines anciennes) être différents.

Dans QuickDraw il n’y a qu’un seul système de coordonnées et il est très simple. Sauf spécification contraire de votre part, le point (0,0) est le coin en haut à gauche de la zone cliente de la fenêtre (si vous parlez de la zone d’affichage d’une fenêtre spécifique) ou du bureau lui-même.

Une autre petite différence, mais très importante, entre les systèmes de coordonnées de Win32/GDI et QuickDraw est la liaison entre le repère virtuel de coordonnées et les points et droites tracés dans cette grille. Du côté Win32, les pixels (qui ont une taille “mesurable”) sont tracés de telle sorte que leurs centres soient aux abscisses et ordonnées voulues et leurs épaisseurs “recouvrent” leurs coordonnées.

Dans QuickDraw, les pixels et les lignes sont tracés dans les espaces entre les droites de coordoonées. Pour être tout à fait précis, ils sont tracés à droite et en dessous des points qui les définissent. Les ingénieurs à l’origine de QuickDraw pensaient que cette méthode prêterait moins à confusion quand on se pose, par exemple, la question suivante : Un caré de 10 par 10 tracé à partir de son coin en haut à gauche situé en (0,0) contient-il le point (10,10) ? Dans QuickDraw, la réponse est “oui”, alors qu’en Win32 la réponse est “non” et les programmeurs Win32/GDI doivent avoir en tête la règle “borne supérieure non incluse”.

Le tableau 2 résument les différences concernant les systèmes de coordonnées entre les environnements graphiques de Win32 et QuickDraw.

Tableau 2. Comparaison des systèmes de coordonnées. Win32/GDI QuickDraw Les contextes de périphériques peuvent utiliser des coordonnées logiques qui n’entretiennent pas avec leur affichage réel une relation 1:1 (possibilité d’effet de mise à l’échelle). Les coordonnées logiques “programmées” sont en rapport direct avec l’affichage réel. Possède différents types de repères, dans lesquels une valeur croissante de x peut indiquer des mouvements vers la droite ou vers la gauche, et des valeurs croissantes de y des mouvements vers le haut ou vers le bas. Repère fixe: Des valeurs croissantes de x correspondent à un mouvement vers la droite, des valeurs croissantes de y vont vers le bas. (comme dans le mode MM_TEXT de Win32). Les points peuvent être identifiés soit dans le repère local (propre à la fenêtre) soit dans le repère global (du bureau). Les pixels sont tracés à l’intersection des droites imaginaires qui définissent le système de coordonnées logiques. En d’autres mots, les droites imaginaires qui définissent le point (x0,y0) passent par le centre du pixel tracé en (x0,y0). Dans QuickDraw, l’intersection des deux droites imaginaires qui définissent le point (x0,y0) est “idéale” (elle n’a ni hauteur ni profondeur). Les pixels, qui ont une hauteur et une largeur sont dessinés dans les carrés situés entre ces lignes imaginaires. Ainsi, le pixel correspondant au point (x0,y0) est tracé à droite et en dessous du point théorique (x0,y0).

Les stylos

Les stylos de Win32/GDI ont évolué pendant le temps, et plusieurs types sont aujourd’hui disponibles : les stylos de tracé, les stylos logiques, les stylos géométriques, etc … A l’inverse, QuickDraw, lui, n’offre qu’un seul stylo.

Tout comme il ne dessine jamais que sur le port courant, il n’écrit qu’avec le stylo courant et vous devez utiliser l’une des routines PenSize,PenPixPat, et PenMode pour changer la taille, le motif et le mode de tracé du stylo. S’il y a des stylos avec lesquels vous travaillez souvent, vous devrez créer des sous-routines pour les définir. Vous pourrez alors passer d’un stylo à l’autre en appelant simplement la bonne sous-routine.

Dans QuickDraw, un stylo permet d’écrire dans une couleur opaque, qui peut être modifiée par un filtre “un-bit”, ou n’importe quel pixmap (voir plus haut, la définition de pixmap). De plus, le dessin peut être modifié par l’utilisation de différents modes de transfert, bien que ceci ne soit pas très courant.

Le stylo de QuickDraw a toujours un motif, un mode, une couleur d’écriture et une couleur de fond qui tous affectent la façon dont un stylo écrit. Le motif du stylo, au contraire du motif ombré (hatch pattern) de Win32/GDI, est défini par le programmeur et peut prendre n’importe quelle valeur. QuickDraw, par défaut, utilise le motif noir opaque et le mode patCopy , ce qui est assez simple à comprendre, et écrit dans la couleur de tracé du CGrafPort. Le comportement du stylo peut, néanmoins, devenir passablement plus compliqué :

• Si le motif est un bitmap, un pixel “touché” par le stylo peut passer en inversion vidéo (échanger sa couleur de tracé avec sa couleur de fond) ou ne pas changer, selon le mode utilisé.
• Si le motif est un pixmap, c’est le pixmap lui-même qui est utilisé pour tracer ce que la commande de dessin ordonne, que ce soit une ligne ou n’importe quelle forme. Dans ce cas, tout pixel “touché” est remplacé par le pixel défini dans le pixmap.

• Enfin, lorsqu’un stylo est utlisé pour définir une ligne ou tracer les contours d’une forme, le tracé n’est pas effectué avec la largeur du stylo cheminant le long du parcours. Au lieu de cela, c’est le coin en haut à gauche du motif du stylo qui se promène sur le chemin défini, ce qui signifie que “l’encre” est toujours déposée en bas et à droite du point considéré.

Si votre application fait un usage intensif d’outils propres à Win32 introuvables dans QuickDraw, vous devriez porter votre choix vers l’API Quartz 2D pour porter votre application vers Mac OS X. Voir plus loin dans ce document le paragraphe “Utilisation de Quartz 2D” pour plus de détails.

Le tableau 3 résument les principales différences entre Win32/GDI et QuickDraw en ce qui concerne les stylos. Celui-ci devrait vous permettre d’apréhender plus rapidement l’utilisation des stylos de QuickDraw.

Tableau 3. Comparaison des stylos géométriques de Win32 et de QuickDraw. Win32/GDI QuickDraw Un CA contient les attributs qui font référence au stylo et au pinceau en cours (qui sont des strucutres de données distinctes du CA). Un CGrafPort inclus les attributs qui décrivent le stylo en cours et sa couleur ou son motif de tracé. La section d’un stylo géométrique est carrée. La section d’un stylo est rectangulaire, ce qui signifie que l’on peut régler à la fois sa largeur et sa hauteur indépendament. Un stylo géométrique écrit dans une couleur opaque et efface en utilisant la couleur du fond. Un stylo écrit dans une couleur opaque et efface en utilisant la couleur du fond. Un stylo géométrique est défini à partir de sa largeur. La ligne tracée est (en général) centrée sur la ligne théorique définie par l’instruction de tracé. Un stylo est défini par sa hauteur et sa largeur. Le stylo écrit de telle sorte que son coin supérieur gauche décrive le chemin décrit par l’instruction de tracé. Un stylo géométrique utilisant un pinceau à ombre, trace un trait opaque modifié par une ombre prédéfinie. Un stylo peut écrire avec une couleur opaque et n’importe quel motif. Un stylo géométrique peut être utilisé directement pour tracer des pointillés et autres types de lignes. QuickDraw n’a pas d’équivalent, il faut utiliser Quartz 2D qui est un environnement plus avancé. L’utilisation d’un pinceau à motif, permet à un stylo géométrique d’écrire avec n’importe quel bitmap pour “encre”. L’utilisation d’un motif de pixels coloré (PixPat), permet à un stylo d’écrire avec n’importe quel bitmap pour “encre”. La façon de dessiner peut être modifiée en changeant l’attribut “mode de dessin” du CA. La façon de dessiner peut être modifiée en changeant de mode de transfert.

Les formes géométriques

Bien que les deux environnements, Win32/GDI et QuickDraw, offrent sensiblement les mêmes possibilités de tracer des formes géométriques, la méthode de dessin est différente. QuickDraw n’a pas d”équivalent au pinceau de Win32/GDI. Au lieu de cela, vous devez utiliser différentes instructions, quand vous dessinez des formes géométriques, pour définir la façon dont vous voulez remplir l’intérieur, le tracé étant réalisé soit par le stylo soit par n’importe quel bitmap ou pixmap.

Le premier “mot” de chaque instruction de tracé de forme indique la méthode de tracé :

• Les instructions commençant par “Frame” (par exemple, FrameOval) dessine le contour en utilisant le stylo en cours (dont le comportement a été défini avant) et l’intérieur de la forme n’est pas précisé.
• Les instructions commençant par “Paint” (par exemple, PaintOval) remplit l’intérieur de la forme avec le stylo (dont le comportement a été défini avant) mais le contour n’est pas dessiné par le stylo.
• Les intructions commençant par “FillC” (par exemple, FillCOval) remplisse l’intérieur de la forme avec un motif quelconque (pas nécessairement le même que celui du stylo). Chaque pixel atteint par le stylo est remplacé par le pixel coloré adéquat du pixmap. L’instruction servant à définir le motif du pixmap est PenPixPat.

Le tableau 4 résume les principales différences entre Win32/GDI et QuickDraw en ce qui concerne les formes géométriques.

Tableau 4. Comparaison des formes géométriques. Win32/GDI QuickDraw Formes géométriques disponibles : rectangles, ellipses, cordes, “camemberts”, rectangles à angles arrondis. Formes géométriques disponibles : Rectangles, ovales, arcs et secteurs, rectangles à angles arrondis. Pour dessiner une forme géomérique élémentaire (par exemple, une ellipse) sans la remplir, il faut la tracer avec le pinceau du CA chargé de la couleur de fond. Dans ce cas précis, l’instruction est Ellipse. Pour tracer le contour d’une forme géométrique avec QuickDraw, vous avez à votre disposition les instructions commençant par “Frame” (FrameOval dans notre cas). Pour dessiner une ellipse remplie d’une couleur opaque, vous devez utiliser le pinceau du CA avec la couleur voulue et utiliser l’instruction Ellipse. Pour tracer une forme pleine, QuickDraw propose les instructions commençant par “Paint” (dans notre cas PaintOval). Cette instruction peint l’intérieur de l’ellipse avec la couleur de tracé en cours. Si vous spécifiez un motif un-bit et mode de transfert booléen, vous pouvez remplir l’ellipse avec un mélange “pondéré” des couleurs de tracé et de fond. Pour tracer une ellipse remplie d’un bitmap couleur, vous devez utiliser le pinceau du CA avec un motif et utiliser l’instruction Ellipse. QuickDraw propose les instructions commençant par “FillC” (dans notre cas FillCOval). Cette instruction nécessite, outre la description des coordonnées du rectangle contenant la forme, une référence au motif de pixels à utiliser. Win32 offre l’instruction InvertRect, et celle-ci seulement, pour effacer et inverser des formes géométriques. QuickDraw offre des instructions pour effacer et inverser chaque forme géométrique (dans notre cas, EraseOval et InvertOval).

Les polygones

Dans QuickDraw, le tracé des polygones est similaire à celui des formes géométriques dans de nombreux aspects (voir le tableau 5 ci-dessous). Une différence avec le modèle Win32/GDI est que, dans QuickDraw, vous devez explicitement créer le polygone avant de pouvoir le tracer.

Tableau 5. Comparaison des polygones. Win32/GDI QuickDraw Un polygone est défini par un tableau de points, qui est l’un des paramètres de l’instruction Polygon. Dans QuickDraw, vous devez créer une structure de données pour le polygone avant de pouvoir le tracer. Vous faites cela en utilisant l’instruction OpenPoly, suivie des instructions de tracé des lignes, le tout suivi de l’instruction ClosePoly. Comme pour les formes géométriques, vous créez des contours, des formes pleines (couleurs ou motifs) avec la même instruction mais avec des pinceaux différents. Comme pour les formes géométriques, vous avez différentes instructions pour les polygones. FramePoly trace le polygone avec un stylo. PaintPoly trace le contour avec le stylo et remplit l’intérieur avec une couleur opaque. FillCPoly trace le contour avec le stylo et remplit l’intérieur avec un motif (bitmap coloré). Win32/GDI n’a pas de commandes pour effacer ou inverser des polygones. Comme pour les formes géométriques, QuickDraw offre les instructions ErasePoly et InvertPoly.

Les chemins Win32/GDI, les régions Win32/GDI et les régions QuickDraw

Une région QuickDraw remplit le même rôle qu’un chemin Win32/GDI en ce qu’ils permettent tous deux de tracer des lignes et de remplir des formes fondées sur un ensemble d’opérations graphiques pré-enregistré (voir Tableau 6).

Tableau 6.Comparaison des chemins Win32/GDI et des régions QuickDraw. Win32/GDI QuickDraw Un chemin Win32/GDI est un ensemble de formes graphiques quelconques qui peuvent être remplies ou tracées. Une région QuickDraw est une structure de données qui fait la distinction entre tous les points inclus dans la région et ceux qui ne le sont pas. Vous pouvez tracer son contour avec un stylo, peindre son contenu d’une couleur opaque ou un motif, l’utiliser comme masque pour une autre opération graphique ou pour tester la présence d’un clic de souris dans une zone. Vous devez créer un chemin Win32/GDI avant de pouvoir l’utiliser pour dessiner. Pour cela, vous devez utiliser l’instruction BeginPath, suivie d’une série d’instructions de dessin, terminée par l’instruction EndPath. Vous devez créer une région QuickDraw avant de pouvoir l’utiliser pour dessiner. Pour cela, vous devez utiliser l’instruction OpenRgn, suivie d’une série de commandes de dessin, terminée par l’instruction CloseRgn. Utilisez la commande StrokePath pour tracer un contour en utilisant un chemin Win32/GDI et le stylo en cours. Utilisez la commande FrameRgn pour tracer un contour en utlisant une région QuickDraw et le stylo en cours. Utilisez la commande StrokeAndFillPath pour dessiner avec le stylo en cours et remplir le contenu avec une couleur ou un motif. Utilisez la commande PaintRgn pour tracer le contour avec le stylo en cours et le remplir d’une couleur opaque. Utilisez la commande FillRgn pour dessiner avec le stylo en cours et remplir d’un motif. Vous pouvez transformer un chemin Win32/GDI en une zone détachable pour un CA donné. Vous pouvez utiliser une région QuickDraw en tant que zone détachable pour le CGrafPort en cours. Vous n’avez pas besoin de la transformer en quoi que ce soit pour cela. Il n’y a pas d’équivalent Win32/GDI pour les commandes décrites à droite. QuickDraw propose les instructions EraseRgn et InvertRgn.

Les régions QuickDraw peuvent aussi réaliser les mêmes tâches que les régions Win32/GDI (voir Tableau 7). Quand vous créez une région QuickDraw, vous pouvez utiliser certaines instructions de tracé qui sont indisponibles dans une région Win32/GDI. Cette différence est cependant largement compensée par le fait que l’on peut créer un chemin Win32/GDI puis le convertir en une région Win32/GDI.

Tableau 7. Comparaison des régions Win32/GDI et des régions QuickDraw. Win32/GDI QuickDraw Une région Win32/GDI est une structure de données qui sépare les points inclus dans le chemin de ceux qui ne le sont pas. Vous pouvez tracer son contour avec le stylo, peindre l’intérieur avec un pinceau , l’utiliser comme masque pour une opération de dessin ou pour tester la présence d’un clic de souris. Une région QuickDraw est une structure de données qui fait la distinction entre tous les points inclus dans la région et ceux qui ne le sont pas. Vous pouvez tracer son contour avec un stylo, peindre son contenu d’une couleur opaque ou un motif, l’utiliser comme masque pour une autre opération graphique ou pour tester la présence d’un clic de souris dans une zone. Vous créez des régions Win32/GDI tout comme des chemins Win32/GDI, mais vos instructions de dessin sont limitées aux ellipses, polygones, rectangles et rectangles “arrondis”. Vous pouvez aussi transformer un chemin Win32/GDI (qui est plus “souple”) en une région. Comme pour les régions Win32/GDI, les régions QuickDraw sont créées par une suite d’opérations de tracé, mais les régions QuickDraw peuvent être définies à partir de toutes les commandes de tracé. Vous pouvez définir une région comme l’union, l’intersection, la différence ou le XOR de deux régions. Vous pouvez définir une région comme l’union, l’intersection, la différence ou le XOR de deux régions.

Les images hors-écran et les mondes graphiques GWorld

Sur la plupart des systèmes informatiques, si vous utilisez des commandes de dessin qui écrivent directement dans la mémoire vidéo du matériel d’affichage, ces envois vers la mémoire vont se mêler aux appels-mémoire du périphérique. Ce qui va entrainer clignotements et autres effets visuels indésirables. La parade usuelle à ce problème consiste à dessiner dans une image hors-écran puis de transférer l’ensemble de l’image dans la mémoire vidéo en une seule opération rapide appelée un “transfert de blocs de bits” (bit-block transfer), autrement appelé bitblt.

Quand les ingénieurs d’Apple ont créé Color QuickDraw, ils ont implémenté une nouvelle structure de données appelée un GWorld (une version raccourci de l’expression anglaise “graphics world” (ndT: Un monde graphique). Un GWorld se comporte comme un bitmap hors-écran dans Win32/GDI, et, dans Color QuickDraw, vous définissez le port graphique pour les fenêtres (à la fois à l’écran et hors-écran) et les mondes GWorld avec la commande SetGWorld. pour plus de détails sur les mondes graphiques GWorld et la façon de les utiliser, voyez le chapitre “Offscreen Graphics Worlds” de Inside Macintosh: Imaging with QuickDraw. (ndT: En anglais … bien entendu)

En tant que membre de l’architecture d’affichage Quartz, QuickDraw dessine automatiquement dans une image hors-écran ; en fait, on ne peut pas faire autrement. Ainsi, si vous souhaitez juste éviter ces désagréments à l’affichage, vous n’aurez pas à vous soucier des mondes graphiques GWorld. Il y a, cependant, d’autres raisons de se préoccuper des mondes graphiques. Si, par exemple, vous devez desiner une image un peu complexe qui devra être réutilisée, vous pouvez la dessiner dans un monde graphique pour la sauvegarder en vue de ce réemploi.

Les transferts de blocs de bits (Bitblts)

QuickDraw offre une instruction de tracé, CopyBits, qui correspond aux instructions BitBlt et StretchBlt de Win32/GDI. Bien que CopyBits serve principalement à copier un pixmap vers un nouvel endroit, soyez avertis que vous pouvez aussi transformer l’image pendant le transfert ; voyez le chapitre Color QuickDraw de Inside Macintosh: Imaging with QuickDraw pour plus de détails.

Le tableau 8 résume les différences entre Win32/GDI et QuickDraw en ce qui concerne les transferts de blocs de bits.

Tableau 8. Comparaison des instructions de transferts de blocs de bits dans Win32/GDI et QuickDraw. Win32/GDI QuickDraw BitBlt transfère des pixels d’un CA source vers un CA destination, modifiés par l’une des 256 opérations de rastérisation qui combinent chaque bit source, son motif correspondant (selon le pinceau en cours) et le bit destination correspondant. CopyBits transfère des pixels d’un CGrafPort source vers un CGrafPort de destination, modifiés par l’un des 18 modes de transfert qui combinent chaque bit source avec son bit de destination correspondant. Si les zones sources et destination n’ont pas la même taille, CopyBits redimensionne la zone source à la taille de la zone de destination. StretchBlt se comporte comme BitBlt, mais il étire l’image source pour qu’elle ait la même taille que zone de destination. Voir ci-dessus. PatBlt copie un motif 1-Bit (du pinceau en cours) dans un contexte de périphérique de destination, modifé par l’une des 16 opérations de transformation qui combinent chaque bit du motif avec son bit de destination correspondant. Vous pouvez utiliser FillRect pour obtenir le même résultat que PatBlt. MaskBlt (non disponible sur Windows 98 et les versions antérieures) transfère des pixels d’un contexte de périphériques source vers un contexte de destination modifié par un masque 1-bit et un opérateur de transformation ROP4 CopyMask et CopyDeepMask (disponible sur toute version de Mac OS) transfèrent des pixels d’un CGrafPort vers un CGrafPort de destination, modifié par un masque de pixel. Chaque pixel résultant est la combinaison des pixels source et destination selon la valeur du pixel du masque correspondant. Si le masque contient des pixels colorés, le mélange est effectué pour chaque composant de couleur. CopyDeepMask se comporte comme CopyMask, mais en plus, il vous permet de choisir un mode spécial de transfert et de passer un masque de zone détachable (comme avec CopyBits). PlgBlt (non disponible sur Windows 98 et les versions antérieures) transfère des pixels d’un contexte de périphériques source vers un contexte de destination modifié par un masque 1-bit et d’optionnelles opérations de coupe, de rotation et d’image miroir. QuickDraw n’a pas d’équivalent à PlgBlt, mais Quartz 2D (un environnement graphique plus avancé) fournit un grand nombre de transformations 2D sur les pixmaps, y compris certains non disponibles via PlgBlt.

Les méta-fichiers et les fichiers d’image

Tout comme l’environnement de dessin Win32/GDI possède des méta-fichiers permettant de stocker et réemployer des ensemble de commandes graphiques, QuickDraw possède un équivalent : L’enregistrement d’image (aussi appelé image QuickDraw, ou PICT). Et, tout comme le format de fichier .wmf a été largement remplacé par le format amélioré de méta-fichier .emf, la version originale du format PICT a  été largement remplacé par une seconde version colorée du format PICT.

Comme toute chose dans QuickDraw, les objets PICT se mesurent en nombre de pixels, et l’on peut récupérer la taille d’un PICT dans son en-tête. Vous créez des objets PICT en éxécutant l’instruction OpenCPicture, puis, les instructions de dessin, puis enfin, l’instruction CloseCPicture. Plus tard, vous pourrez les tracer dans une partie rectangulaire de fenêtre ou d’un monde graphique en utilisant l’instruction DrawPicture.

Le format PICT est aussi le format standard du presse-papiers. Tout comme du texte simple, chaque application Mac OS X devrait être capable de couper, copier et coller des ressources PICT.

Le texte

Peu de choses à dire quant à l’utilisation de QuickDraw pour afficher du texte, puisque vous utiliserez probablement des fonctions extérieures à QuickDraw pour le faire. Néanmoins, QuickDraw propose l’insruction DrawText pour tracer un simple texte. Tout comme il n’y a qu’un seul stylo associé à un CGrafPort, vous n’avez qu’un seul “outil texte” à votre disposition, mais vous pouvez changer la police, le style, la taille et le mode de tracé du CGrafPort en cours avant d’utiliser la commande DrawText.

Le tableau 9 reprend les différences entre Win32/GDI et QuickDraw en ce qui concerne les textes.

Tableau 9. Comparaison du tracé de textes simples. Win32/GDI QuickDraw TextOut dessine le texte dans la police en cours à l’endroit défini par les arguments de l’instruction. DrawText dessine les textes bruts dans la police en cours à l’endroit où se trouve le stylo (Utilisez MoveTo pour déplacer le stylo à l’endroit souhaité) DrawText dessine le texte dans un rectangle spécifique. Utilisez TXNDrawCFStringTextBox ou TXNDrawUnicodeTextBox dans l’API Moteur de Texte Multilingue (MLTE) pour dessiner un texte dans un rectangle spécifique.

Introduction à Quartz 2D

Quartz 2D est la toute dernière technologie de fenêtrage et de dessin en deux dimensions d’Apple, disponible uniquement sous Mac OS X. Elle utilise le format PDF d’Adobe comme modèle graphique interne, et fournit donc un modèle de graphique 2D performant et simplifie grandement la création de fichiers PDF.

Parmi les dispositifs disponibles dans Quartz 2D et pas dans QuickDraw on trouve:

• des graphiques vectoriels 2D indépendants de la résolution
• les courbes de Bezier
• le tracé de graphiques et de texte basés sur des chemins
• des transformations 2D quelconques des formes vectorielles (aussi appelées chemins), des textes et des pixmaps.
• la transparence comme un attribut de dessin
• les contextes, un concept qui permet à un même code de dessiner à l’écran, sur une imprimante ou dans un fichier PDF.
• des dessins protégés dans un thread par contexte (tout dessin d’un contexte donné doit avoir lieu dans le même thread)

Quartz 2D et votre travail de portage

Porter une application vers une nouvelle plateforme présente toujours des défis particuliers et ceux-ci déterminent les choix de développement que vous avez. Quand vous portez une application Win32 vers Mac OS X, vous avez trois choix:

• porter en utilisant uniquement QuickDraw
• porter en utilisant QuickDraw, avec d’occasionnels appels à Quartz 2D
• porter en utilisant uniquement Quartz 2D

L’implémentation de QuickDraw dans Mac OS X inclut deux routines, QDBeginCGContext et QDEndCGContext, qui permettent de basculer temporairement vers Quartz 2D pour accéder à des instructions qui ne sont pas disponibles dans QuickDraw.

Pour que votre application soit concurrentielle par rapport à d’autres applications similaires sur Mac OS X, vous vous poserez la question de ré-écrire votre application pour qu’elle utilise uniquement Quartz 2D. Si votre planning le permet, vous étudierez peut-être l’option du portage vers Quartz 2D plutôt que QuickDraw. Ceci vous donnera un produit plus robuste et qui sera plus simple à faire évoluer dans le futur.

Notes à l’attention des développeurs Win32

Les points suivants décrivent différents problèmes divers dont vous devez être avertis pour porter vos applications Win32 vers QuickDraw :

• Compte tenu du fait que les graphiques QuickDraw sont toujours tracés hors-écran sous Mac OS X, le processus de dessin seul ne permet pas de maîtriser quand le dessin sera réellement affiché à l’écran. Si vous voulez contrôlez le moment précis où le dessin va s’aficher, tracer, pour commencer, le dessin, puis, faites appel à la routine QDFlushPortBuffer.
• Comme évoqué précédemment, vous n’avez pas besoin d’utiliser de GWorld pour éviter les effets visuels indésirables ; la double-bufferisation intégrée de Mac OS X fait cela automatiquement.
• Les utilisateurs novices de la routine CopyBits auront peut-être des problèmes pour obtenir le résultat souhaité. Si vous utilisez CopyBits pour copier un pixmap source inchangé, vers un pixmap de destination, vous devez vous assurez que la couleur de tracé est fixée à “noir” et celle du fond à “blanc” et que le mode de la source est srcCopy. Pour plus de détails, lisez le texte situé en haut de la page 4-34 du livre Imaging with QuickDraw.
• Parce qu’Apple contrôle le matériel sur lequel Mac OS X va fonctionner, Mac OS X “connait” mieux le matériel d’affichage disponible que ne peuvent le faire les systèmes d’exploitation Win32. Mac OS X n’a ainsi pas besoin de se préoccuper des bitmaps dépendants ou indépendants du périphérique.
• Certains programmeurs Win32 ont rapportés que CopyBits, quand elle utilisée pour étirer une image, produit des résultats visiblement différents de ceux produits par StretchBlt. Cette différence d’aspect vient de la différence des algorithmes employés pour étirer l’image. Si vous utilisez StretchBlt dans votre code Win32, assurez de bien contrôler l’apparence du résultat du code porté utilisant CopyBits.
• Dans les modes à couleurs indexées sous Mac OS X, les positions dans les palettes du noir et du blanc sont fixes et ne peuvent être changées. Malheuresement, ces positions sont inverses de celles utilisées sous Win32. Si c’est votre cas, vous allez devoir changer votre application pour qu’elle affiche le noir et le blanc correctement dans sa version Mac OS X.
• Bien que les routines de QuickDraw determinent les coordonnées des points avec l’abscisse en premier (c’est à dire avec le composant x en premier), les points QuickDraw sont stockés en mémoire avec leur ordonnée en premier (c’est à dire avec le composant y situé plus bas en mémoire que les x). De toute façon, vous ne devriez pas accéder directement à la mémoire.

Compléments d’information

Votre principale référence pour QuickDraw est Inside Macintosh: Imaging with QuickDraw. En complément du lien vers ce livre, vous trouverez certains des liens ci-dessous bien utiles.

La page de documentation de QuickDraw (inclut des liens vers Imaging with QuickDraw et la documentation de l’API QuickDraw)	http://developer.apple.com/techpubs/macos8/MultimediaGraphics/ QuickDraw/quickdraw.html
Le livre QuickDraw Text	http://developer.apple.com/techpubs/macosx/Carbon/text/QuickDrawText/ QuickDraw_Text/index.html
Les liens vers la documentation de QDBeginCGContext et QDEndCGContext	http://developer.apple.com/techpubs/macosx/Carbon/graphics/QuickDraw/ QuickDraw_Manager/Functions/Miscellaneous2.html
L’anti-aliasing des textes dans QuickDraw via Quartz 2D	http://developer.apple.com/qa/qa2001/qa1193.html
Les liens vers Quartz Primer, dessiner avec Quartz 2D (HTML et PDF), la référence de l’API Quartz 2D	http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/ Quartz2D/quartz2d.html
Les liens vers les nouveautés de la documentation de Quartz 2D, de l’information sur Quartz Extreme	http://developer.apple.com/quartz/

Graphisme 3D et Mac OS X

Les graphismes 3D font partie intégrante de nombreux jeux, produits d’animation et autres produits de modelage, et Mac OS X fournit un support de très bonne qualité à la 3D sous la forme de l’environnement graphique multi-plateforme OpenGL. Se reposant sur le matériel d’accélération graphique embarqué, Mac OS X fournit le support complet d’OpenGL version 1.3 (OpenGL v1.2 pour Mac OS X version 10.1.x et précédentes). Si votre application se base sur OpenGL vous ne devriez rencontrer aucun problème pour porter votre code OpenGL vers Mac OS X. Maya, un logiciel d’animation 3D photo-réaliste de haut vol et Quake III, l’un des jeux les plus populaires actuellement disponibles, sont deux exemples de programmes OpenGL marquants qui ont été portés sur l’implémentation d’Apple d’OpenGL.

L’implémentation d’Apple

OpenGL en lui-même est une API indépendante du matériel qui ne fournit pas de gestionnaire de fenêtres ni d’interface avec l’utilisateur. L’implémentation d’Apple contient quatre API pour communiquer avec OpenGL:

• NSGL, pour l’utilisation avec l’environnement de développement d’application orienté objet Cocoa
• la bibliothèque AppleGL (AGL), pour l’utilisation avec l’environnement procédural Carbon
• CGL (l’API au coeur d’ OpenGL), pour l’utilisation avec les applications de graphismes en plein écran
• La boîte à outils utilitaire d’OpenGL (GLUT), pour l’utlisation avec le code dédié GLUT

Puisque vous êtes en train de porter du code procédural C ou C++ vers Mac OS X, vous allez probablement vous tourner vers AGL. C’est une API des couches supérieures qui vous permet de faire du rendu de graphisme à l’intérieur d’une fenêtre. AGL charge automatiquement les bibliothèques nécessaires aux routines que votre application utilise, de même qu’elle vous permet de choisir le meilleur outil de rendu pour un format de pixel donné. Si vous le souhaitez, vous pouvez sélectionner des moteurs de rendu spécifiques, ou définir des critères selon lesquels le moteur de rendu sera choisi. AGL gère aussi le choix des moteurs de rendu lorsque l’image graphique se répartit sur différents moniteurs.

Notes de portage

Vous devez savoir que OpenGL ne permet pas l’accès direct à ses tampons de cadres (frame buffers). Au lieu de cela, vous devez utiliser les fonctions appropriées d’OpenGL, comme glReadPixels, pour lire le tampon de cadres dans la mémoire du système. Apple a optimisé les routines d’accès et de travail avec OpenGL et ces routines offrent de meilleures performances que celles que pourraient atteindre la plupart des programmeurs qui accèderaient directement aux tampons de cadres directement dans la mémoire.

OpenGL est un standard multi-plateforme, mais vous devez savoir que tous les moteurs de rendu matériels n’offrent pas le support des extensions OpenGL. Au moment de l’éxécution, les applications doivent contrôler la version d’OpenGL en cours ou sa chaîne d’extensions pour que le moteur de rendu puisse déterminer quels mécanismes le moteur de rendu va pouvoir utliser.

Mac OS X version 10.2 (Jaguar) supporte 33 nouvelles extensions OpenGL et inclut nombre d’autres améliorations. Vous pourrez peut-être vouloir que vos clients utilisent Jaguar ou une version plus récente de Mac OS X pour pouvoir utliser votre application.

Puisque vous voulez rendre votre application multi-plateforme, vous pourrez aussi penser à utliser QuickTime pour simplifier les parties communes de code entre Win32 et Mac OS X. QuickTime inclut des fonctions qui permettent d’ouvrir des dizaines de formats graphiques différents. Vous pouvez simplifier grandement votre code sur les deux plateformes en utilisant QuickTime pour ouvrir vos fichiers de texture.

Compléments d’information

OpenGL est un standard graphique ouvert implémenté sur les plateformes Windows, Mac OS, Linux, et même d’autres. Le meilleur site web pour trouver des liens vers la documentation est le site d’OpenGL dont l’adresse est http://www.opengl.org. En outre, vous devriez jeter un oeil aux ressources citées ci-dessous pour démarrer avec OpenGL sur Mac OS X.

Le livre OpenGL for Mac OS	http://developer.apple.com/techpubs/macosx/Carbon/ graphics/OpenGL/OpenGL/index.html
La référence à l’API AGL	http://developer.apple.com/techpubs/macosx/Carbon/ graphics/OpenGL/ AGL_OpenGL/index.html
Le guide des extensions OpenGL	http://developer.apple.com/opengl/extensions.html
La liste des extensions OpenGL supportées par Mac OS X v10.2	http://developer.apple.com/opengl/jaguar.html
Des exemples de code OpenGL tirées de la suite d’Outis de Développement Mac OS X	Situés sur le disque dur d’un système Mac OS X dans le fichier /Developer/Examples/OpenGL/GLUT
Les outils OpenGL Shader Builder et OpenGL Profiler	Sur le disque dur Mac OS X dans le répertoire /Developer/Applications
Les pages de man OpenGL	Tapez “man <nomDeLaCommande>” dans une fenêtre de Terminal (par ex. “man glClear” (voir le fichier “gl.h” pour la liste des noms des commandes)
Les fichiers d’en-têtes OpenGL	Situés sur le disque dur Mac OS X dans /System/Library/Frameworks/OpenGL.framework et /System/Library/Frameworks/AGL.framework. En particulier, regardez agl.h (qui inclut gl.h), glu.h, glut.h, OpenGL.h (pour les graphiques plein écran), glext.h (pour les extensions OpenGL)
Les sessions OpenGL de la WWDC 2002	* session 504–OpenGL: Graphics Programmability * session 505–OpenGL: Integrated Graphics 1 * session 506–OpenGL: Integrated Graphics 2 * session 513–OpenGL: Advanced 3D qu’on peut acheter à l’adresse http://developer.apple.com/adctv/ * session 514–OpenGL: Performance and Optimization

Note: Comme sur tout système UNIX, vous pouvez accéder aux pages de manuel en tapant man nomdecommand dans une fenêtre de Terminal. Les fichiers d’en-tête sont situés en différents endroits, et le meilleur moyen de les trouver est de taper locate nomdufichier dans une fenêtre de Terminal. Si cette commande ne fonctionne pas vous devez construire la base de données de recherche sous-jacente. Allez voir la page http://osxfaq.com/Tutorials/LearningCenter/UnixTutorials/WorkingWithUnix/page2.ws pour savoir comment faire cela.

Programmation pour plusieurs processeurs

Les ordinateurs bi-processeurs sont maintenant un élément important du catalogue de produits Apple et Mac OS X est conçu pour en tirer profit. Si votre application Win32 utilise les threads (n.d.T : parfois appelés processus simplifiés mais généralement connus sous leur nom anglais même dans notre langue) pour tirer parti de multiples processeurs, vous obtiendrez le même type de performance sur Mac OS X. Ce chapitre vous montrera comment mettre cela en place.

Pour votre information, Mac OS X est compatible avec différents packages de threading, en particulier les threads POSIX. (Voir le  chapitre 14 de Inside Mac OS X: System Overview pour plus de détails). Si votre application Win32 est déjà écrite en utilisant les threads, l’API Mac OS X qui correspond à votre code doit être l’API Services Multiprocesseurs (n.d.T. : Multiprocessing Services API en v.o.) qui sera décrite dans cette partie.

Les similitudes entre Mac OS X et Win32

Les plateformes Mac OS X et Win32 ont des approches similaires dans leurs utilisations de multiples processeurs, et les API en jeu sont semblables dans leur structure et leur conception. Voici les principlales similtudes:

• Toutes deux voient la création d’applications utilisant de multiples processeurs en “éclatant” l’application dans plusieurs threads indépendants (appelés tasks dans l’API Multiprocessing Services de Mac OS X), que le système d’exploitation sous-jacent va planifier pour qu’elles tournent sur les différents processeurs.
• Toutes deux implémentent le multiprocessing symétrique (SMP).
• Toutes deux assignent automatiquement les threads aux processeurs disponibles pour optimiser la vitesse globale d’éxécution du programme.
• Sur les deux plateformes, les applications s’appuyant sur les threads fonctionnent correctement sur les machines mono-processeurs  comme celles possédant plusieurs processeurs.
• Toutes deux utilisent les sections critiques (appelées régions critiques sur Mac OS X) pour limiter l’accès à une zone de mémoire partagée à un thread à la fois.
• Toutes deux fournissent les sémaphores pour faciliter la synchronisation entre des threads coopératifs.

Les méthodes de portage

Il y a trois façons possibles de porter votre code Win32 vers Mac OS X en utilisant l’API Multiprocessing Services:

• écrire du code “à la colle”.
• modifier votre code existant pour utiliser les routines de l’API.
• réécrire votre code pour le rendre plus performant.

Vous choisirez votre méthode selon les priorités et contraintes de votre situation particulière, bien entendu.

Avant que vous ne décidiez quelle approche vous choisissez, vous devrez vous familiariser avec l’API Mac OS X que vous utiliserez. Comme c’est le cas sur Win32, certaines API fonctionnent en environnement multi-processus, d’autres pas et d’autres, enfin, ne fonctionnent que sous certaines restrictions. Le problème du multi-processus pourrait vous contraindre à modifier votre approche de portage vers Mac OS X.

Ecrire du code “à la colle”

Dans cette approche, vous laissez votre code source inchangé et vous vous focalisez sur l’écriture d’un code le plus proche possible de l’existant en utilisant les routines de l’API Multiprocessing Services. De cette manière, votre code continue à tourner en “croyant” qu’il tourne sur une plateforme Win32.

Le principal avantage de cette méthode est que, si elle implémentée correctement, vous n’aurez pas à modifier ou à re-tester le code de l’application qui utilise les threads, les sémaphores et autres sections critiques. De plus, lorsque votre code “à la colle” fonctionnera correctement, vous pourrez porter d’autres applications Win32 vers Mac OS X sans trop d’efforts.

Il y a cependant plusieurs inconvénients majeurs induits par cette méthode. Premièrement, le code “à la colle” va nécessiter d’écrire des “émulateurs” en sur-couche et l’application portée pourrait être beaucoup trop lente pour être utilisable. Deuxièmement, écrire ce code “à la colle” n’est pas chose aisée et votre planning pourrait ne pas inclure le temps nécessaire à concevoir, implémenter et déboguer ce code.

Modifier votre code Win32

Cette approche consiste à conserver la logique de votre programme et à remplacer le code spécifque Win32 par l’équivalent Mac OS X.

Le principal avantage de cette méthode par rapport à la méthode précédente, est que le code produit sera beaucoup plus rapide qu’avec la première méthode. Selon la complexité et la longueur de votre code initial, le processus pourrait même être plus rapide et plus simple.

Cette approche a deux inconvénients principaux. Premièrement, vous devrez tester à nouveau le code produit. Deuxièment, cette approche vous contraindra à maintenir et améliorer deux versions distinctes de code séparément.

Réécrire votre code Win32

Du côté Win32, le paradigme dominant dans les applications multi-processus, consiste à suspendre les threads qui tournent trop longtemps et à les tuer quand cela s’avère nécessaire. Ces méthodes consomment du temps processeur de manière inopportune. Les applications bâties autour du modèle producteur/consommateur sont plus performantes qu’elle que soit la plateforme, et vous devriez considérer la réécriture de votre code selon ce modèle.

Autre avantage à passer à ce modèle producteur/consommateur est que Mac OS X est conçu pour travailler de façon optimale avec lui. Quand une tâche (thread) se bloque, Mac OS X la suspend automatiquement et rapidement sans quasiment aucune surcharge du processeur ou de la mémoire. Lorsque cette tâche se débloque, Mac OS X la réactive automatiquement. La création et la destruction de tâche, néanmoins, entraine une surcharge plus importante.

Les tâches sont suspendues et reprises des millions de fois durant leurs “vies”, donc ces opérations doivent être optimisées. Le modèle producteur/consommateur, de façon générale, n’a pas besoin de tuer un thread implémentant un producteur ou un consommateur prématurément, bien qu’il passe de l’un à l’autre très souvent. ces deux choses combinées expliquent pourquoi Mac OS X et le modèle producteur/consommateur fonctionnent si bien ensemble.

L’avantage de convertir votre programme de manière à utiliser le modèle producteur/consommateur est que votre application tournera plus vite et sera plus simple à maintenir sur les deux plateformes. L’inconvénient est, bien sûr, le temps nécessaire à la réécriture et au débogage d’une portion importante de votre code.

L’API Multiprocessing Services

Une tâche selon les termes de l’API est un thread préemptif situé dans la couche supérieure d’un thread POSIX. L’API fournit le support des services suivants:

• Tâches : création, fin et mise en place des ordres de priorité.
• Régions critiques : création, suppression, sortie  et tentative d’entrée dans une zone critique.
• Sémaphores : création, suppression, signalisation et attente d’un sémaphore.
• Allocation mémoire : création et manipulation d’un bloc de mémoire non-reallouable uniquement pour les processus en cours dans l’application.
• Files de messages : création, suppression et manipulation de files de messages FIFO (utilisées en autre pour implémenter les programmes producteur/consommateur).
• Chronomètres (timers) : création, démarrage, annulation et suppression; blocage d’une tâche jusqu’à un instant spécifié.
• Variables de stockage par tâche : initialisation et recherche de la valeur à partir d’un index et d’une tâche courante.
• Disponibilité du processeur : recherche du nombre de processeurs disponibles et de leurs disponibilités.
• Groupes d’évènements : création, suppression et travail avec les groupes d’évènements (voir ci-dessous).

Les groupes d’évènements vous aident à construire du code qui bloque un thread jusqu’à ce qu’un ou plusieurs évènements ne se produisent. C’est une amélioration de la routine Win32 WaitForMultipleObjects dans la mesure où, avec un groupe d’évènements, vous savez quels évènements ont eu lieu et pouvez tirer partie de cette information.

Compléments d’information

Vous trouverez le lien vers la documentaion de l’API Multiprocessing Services API sur la page des développeurs Carbon qui se trouve à l’adresse http://developer.apple.com/techpubs/macosx/Carbon/carbon.html. Afin de faciliter la recherche un lien vers cette page est listé ci-dessous.

Multiprocessing Services	http://developer.apple.com/techpubs/macosx/Carbon/oss/MultiPServices/ Multiprocessing_Services/index.html
livres sur les pthreads	Programming with POSIX Threads, par David R. Butenhof (Addison Wesley, 1977) POSIX 4: Programming for the Real World, par Bill O. Gallmeister et Mike Loukides (O’Reilly, 1994)

Travailler en réseau avec Mac OS X

Dans la majorité des cas, travailler en réseau signifie communiquer avec des postes distants via internet, et c’est ce dont nous allons vous parler ici. Si ce n’est pas ce que vous cherchez, allez voir à la rubrique “Sujets connexes” vers la fin de ce document.

Le reste de ce document va évoquer les différentes API qui vous permettent de vous connecter et de communiquer avec des sites distants à travers internet:

• l’API pour manipuler les sockets BSD qui vous offre l’accès complet aux sockets type UNIX pour un accès de bas niveau aux fonctions réseaux.
• CFSocket, une API Apple qui utilise les sockets BSD mais permet de manipuler différentes connexions à une socket dans un même thread.
• CFNetwork, une API Apple qui simplifie le processus de transmission et de réception de messages HTTP.

Avant d’explorer ces API, vous devez tout d’abord comprendre un concept appelé boucles d’exécution (ndt. run loops en v.o.).

Threads contre boucles d’exécution

Beaucoup de programmes basés sur les sockets sont conçus utiliser les threads. Pour ces programmes, Apple offre une fonction similaire pour faciliter le portage versMac OS  X. Du code utilisant les sockets BSD ne devrait pas demander beaucoup de changement pour fonctionner sous Mac OS X.

L’une des difficultés rencontrées dans l’utiliation des sockets est la nécessité d’utiliser plusieurs threads distincts pour gérer l’échange de données. Dans un environnement serveur, où plusieurs centaines de sockets peuvent être ouverts simultanément, le code qui vérifie l’activté de ces threads peut sérieusement réduire la performance du serveur. De plus, la synchronisation des données est souvent un gros problème et des verrous sont généralement mis en place pour s’assurer qu’un seul thread à accès à une variable globale à la fois.

Pour ces situations, Apple fournit les boucles d’exécution, qui fonctionnent comme la boucle de messages (message loop) des applications Win32. Vous pouvez utiliser ces boucles pour gérer différentes sources d’entrée y compris les sockets. Chaque thread d’exécution a une et une seule boucle d’exécution, qui peut gérer différentes sources de données. Lorsque vous ajoutez une source de données (une socket par exemple) dans une boucle d’exécution, vous devez aussi lui adjoindre une fonction d’interrogation qui sera appelée à chaque fois que la source doit être “observée”.

Le code régi par des évènements est plus complexe à écrire que du code avec des blocs de threads, mais il fournira les meilleures performances sur le réseau. Quand vous utilisez une boucle d’exécution pour gérer différentes sockets dans le même thread, vous évitez tout problème de synchronisation engendré par une solution multi-threads. L’API CFSocket inclut les routines qui permettent de lier les services d’une socket à la boucle d’exécution d’un thread.

Les API réseaux de Mac OS X

Le chapitre suivant décrit les trois API réseaux disponibles pour vous. Les deux API de plus haut niveau, CFNetwork et CFSocket, sont toutes deux construites sur la troisième, BSD Sockets. Selon les situations, une API ou une autre sera la plus adaptée, et il vous faudra choisir celle que vous voulez utiliser. La documentation de ces API se trouve en différents endroits ; pour plus de détails reportez vous au paragraphe “Compléments d’information” situé au bas de cette page.

BSD Sockets

BSD Sockets est l’API “classique” UNIX pour se connecter à d’autres processus ou ressources distants via internet. Si votre application Win32 utilise l’API Winsock (qui elle-même repose sur BSD Sockets) pour les communications synchrones, vous devriez avoir peu de problèmes à porter votre application vers l’implémentation Mac OS X des BSD Sockets. L’API BSD Sockets inclut des procedures telles que socket, bind, listen, accept, connect, read, write et close.

CFSocket

CFSocket offre une API de haute qualité qui utilise les sockets BSD pour communiquer avec une machine distante sur internet et qui offre aussi un mécanisme configurable (routines de retour et boucle d’exécution du thread) pour manipuler automatiquement les données émises par la machine internet distante. Ainsi, vous pourrez notamment :

• configurer une CFSocket pour lire de façon automatique les données entrantes ou appeler la routine de rappel quand des données seront disponibles à la lecture,
• configurer une routine de rappel (ndt: callback en anglais) pour pouvoir l’interrompre ou la redémarrer automatiquement quand elle a été interrompue,
• actionner manuellement (arrêt ou lancement) une routine de rappel,
• se connecter au réseau en tâche de fond,

Vous aurez probablement usage de l’API CFSocket si votre code actuel est basé sur le mode asynchrone de Winsock.

CFNetwork

CFNetwork est une API réseau de haut niveau qui permet de créer, envoyer et recevoir différents types de messages généralement échangés entre clients et serveurs. Il offre actuellement le support des messages HTTP ; il est aussi prévu de suporter d’autres protocoles (notamment SMTP, LDAP et FTP) dans un proche futur.

CFNetwork offre des fonctions pour :

• envoyer et recevoir des requêtes et des réponses HTTP.
• récupérer ou définir les différents composants d’un message HTTP (comme par exemple CFHTTPMessageSetBody,CFHTTPMessageGetResponseStatusCode).
• récupérer les informations sur le message lui-même (comme par exemple, récupérer la version du HTTP du message).
• créer des flux HTTP pour transmettre des messages HTTP et recevoir les réponses correspondantes.

La liste ci-dessous vous permettra d’avoir une idée de la façon dont vous pourriez utiliser CFNetwork et les routines à utiliser pour créer et envoyer une requête HHTP.

• création des messages
  • créez une requête HTTP avec CFHTTPMessageCreateRequest
  • définissez le corps du message avec CFHTTPMessageSetBody
  • définissez l’en-tête avec CFHTTPMessageSetHeaderFieldValue
  • vérifiez que l’en-tête est correctement rédigée en appelant CFHTTPMessageIsHeaderComplete
  • sérialisez le message en appelant CFHTTPMessageCopySerializedMessage
• envoi des messages
  • utilisez CFReadStreamCreateForHTTPRequest pour créer un flux HTTP pour transmettre une requête déjà construite
  • A noter : vous pouvez aussi transmettre un message en utilisant une CFSocket ou une socket BSD (voir ci-dessus)
• nettoyage du message
  • utilisez CFRelease pour éliminer le message original et sa version sérialisée
• nettoyage du flux
  • fermez le flux en utilisant CFReadStreamClose
  • assurez vous que le flux ne fera pas de rappel en appelant CFReadStreamSetClient avec des arguments NULL
  • empêchez le flux d’appeler le rappel existant en utilsant CFReadStreamUnscheduleFromRunLoop
  • libérez la référence au flux en utilsant CFRelease

Sujets connexes

Le réseau peut signifer différentes choses selon les personnes. Les paragraphes suivants présentent deux ressources liées aux réseaux dont vous pourriez avoir besoin. Des liens vers une documentation plus fournie seront donnés dans le paragraphe “Compléments d’information” plus bas.

Le framework de configuration système

Ce framework est utilisé partout dans le système pour permettre de configurer différentes ressources système par programmation. Dans le contexte du travail en réseau, vous pourriez avoir à utiliser ce framework pour configurer les paramètres réseaux pour l’utilisateur et les changer automatiquement quand des services en ligne sont ajoutés ou retirés.

Les services réseaux

La technologie RendezVous d’Apple, disponible sous Mac OS Xdepuis la version 10.2 (Jaguar), permet aux ordinateurs, aux périphériques et autres accessoires, reliés ou pas par un fil, de se connecter à un réseau ad hoc. Si vous êtes intéressés par la mise en oeuvre de ces technologies dans votre application, CFNetwork inclut une API de services réseaux, CFNetServices, pour faire cela.

Les services réseaux (aussi appelés CFNetServices) vous permettent d’enregistrer votre propre service ainsi qu’un nom parlant pour un humain et toutes les informations nécessaires pour s’y connecter. Vous pouvez aussi créez un navigateur de services en ligne qui vous permet de balayer tous les services enregistrés auxquels vous pouvez vous connecter.

Le kit I/O

Si vous êtes intéressés par l’écriture de programmes de communication avec des matériels en réseau (comme par exemple des pilotes de cartes réseaux) vous devrez connaître le kit I/O. Cette une collection de frameworks, de bibliothèques, d’outils et autres ressources pour créer des pilotes de périphériques pour Mac OS X. Le kit I/O utilise une approche orientée objet et a été conçu pour rendre la création de pilotes plus rapide et plus simple.

Compléments d’information

La plupart de la documentation sur les API réseaux de Mac OS X est contenu dans les fichiers d’en-tête, les pages de man et les livres sur la programmation réseaux UNIX. Voyez la note ci-dessous pour l’accès à ces formes de documentation.

la documentation de CFRunLoop  dans un fichier d’en-tête	CFRunLoop.h
les Sockets BSD	Voyez les pages de man pour les commandes individuelles ; de même, un livre très recommandé sur le sujet est (en anglais) UNIX Network Programming, Network APIs: Sockets and XTI, Volume 1, 2nd Edition, par W. Richard Stevens, publié par  Prentice Hall, ISBN 0-13-490012-X.
La documenation sur l’API Microsoft Winsock 2.2  (y compris un chapitre “Déviation vers les  sockets BSD”)	ftp://ftp.microsoft.com/bussys/winsock/winsock2/WSAPI22.DOC
CFSocket documentation in header file	CFSocket.h
CFNetwork documentation	http://developer.apple.com/techpubs/macosx/Networking/ CFNetwork/CFNetwork.pdf
la documentation sur CFNetwork dans les fichiers d’en-tête	CFNetwork.h, CFHTTPMessage.h, CFHTTPStream.h, CFSocketStream.h, and CFNetServices.h
les notes de version de CFNetwork et de CFNetServices dans Mac OS X v10.2	http://developer.apple.com/techpubs/macosx/ReleaseNotes/CFNetwork.html
liens vers la documentation du kit I/O	http://developer.apple.com/hardware/iokit/
un livre sur les fondamentaux du kit I/O	(HTML): http://developer.apple.com/techpubs/macosx/Darwin/IOKit/ IOKitFundamentals/index.html (PDF): http://developer.apple.com/techpubs/macosx/Darwin/IOKit/ IOKitFundamentals/ IOKitFundamentals.pdf
Les sesions Réseaux du WWDC 2002	* session 808–Managing I/O: CFRunLoop and CFStream * session 803–Mac OS X Networking Overview * session 805–Introducing CFNetwork disponible à l’achat sur http://developer.apple.com/adctv/

Note: Comme sur n’importe quel système UNIX, vous pouvez accéder aux commandes des sockets BSD en ouvrant un terminal et en tapant “man <nomdecommande>”. Les fichiers d’en-tête sont situés en différents endroits et le meilleur moyen de les trouver et de taper “locate <nomdefichier>” dans une fenêtre de terminal. Si la commande ne fonctionne pas, c’est que vous avez à construire la base de données de recherche sous-jacente ; voyez http://osxfaq.com/Tutorials/LearningCenter/UnixTutorials/WorkingWithUnix/page2.ws pour savoir comment faire cela.

Le texte dans Mac OS X

Compte tenu des rapports forts que Macintosh a toujours entrenus avec le monde de la publication, personne ne doit être surpris en apprenant que Mac OS X fournit des API puissantes pour manipuler et afficher du texte en différentes langues, différents styles qu’ils soient statique ou modifiable. Certes, puisque vous portez une application Win32 existante vers Mac OS X, vous ne serez peut-être pas concernés par les outils de manipulation du texte les plus avancés de Mac OS X. Il est cependant intéressant de savoir tout ce qu’il est possible de faire, et c’est ce dont nous allons parler ici.

Selon votre situation, vous n’aurez peut-être pas du tout besoin de connaître quoi que ce soit au sujet des API texte de Mac OS X. Si votre utilisation du texte se limite à proposer des champs de texte de saisie et à afficher des étiquettes sur les éléments de l’interface utilisateur, vous pourrez faire cela grâce à Interface Builder. Si votre application se sert du texte de manière plus avancée, alors vous devez lire cette page.

Comparaison avec Win32

La princiaple chose que vous devez connaître sur l’utilisation du texte dans Mac OS X est que, comme la plateforme Win32, Mac OS X stocke systématiquement ses chaînes de caractères au format Unicode. Puisque votre application utilise probablement Unicode pour l’encodage du texte, vous devriez être plutôt à l’aise avec l’usage que fait Mac OS X du standard Unicode.

Comme Win32, Mac OS X propose différentes API pour les textes statiques et modifiables. Si vos besoins sont simples, Mac OS X offre des routines simples à utiliser pour faire ce que vous souhaitez. D’autes API, plus complexes, vous donnent des possibilités supplémentaires et un meilleur contrôle. Vous devriez donc pouvoir trouver, quelque part dans cette hiérarchie, une routine qui correspond grosso modo à celle que vous utilisez dans votre code original.

Généralités

Bien que certaines fonctions Mac OS X prennent des chaînes Unciode comme arguments, la plupart manipulent le texte comme CFString (”CF” est l’abbréviation de Core Foundation (ndt : le noyau central), qui est la partie de Mac OS X où sont définies les structures et les types de données fondamentaux utilisés par Carbon et Cocoa). Voici quelques choses à retenir concernant les CFStrings:

• Une CFString est une chaîne “brute”, ce qui signifie qu’elle ne contient aucun style ni formatage.
• Un “objet” CFString est un type de données opaque qui représente une chaîne comme un tableau de caractères Unicode. La majorité des API de manipulation de texte de Mac OS X utilisent les CFStrings.
• L’API String Services (qui fait partie du module Core Foundation) comprend les routines qui gèrent la conversion entre les CFStrings et l’Unicode pur, mais aussi la comparaison et la recherche de CFStrings, la manipulation de CFStrings, et autres fonctions liées.

Mac OS X offre le support en natif de textes multilingues et notamment :

• de multiples langues dans le même document sans contrainte sur le mélange de celles-ci
• la mise en valeur du texte fonctionnant correctement y compris dans les situations les plus complexes impliquant plusieurs langues de natures différentes
• le support automatique des langues romanes, japonaises, sémitiques, chinoises, indiennes et d’autres encore.

Ecrire du texte statique

Si vous n’avez besoin que d’écrire du texte statique (c’est à dire ne pouvant être modifié), votre choix devrait se porter sur  DrawThemeTextBox, qui fait partie de l’API Gestionnaire d’apparence. Cette routine ne peut que dessiner du texte sans style, mais le texte est tracé dans une police qui correspond à un thème choisi. Lisez la documentation sur cette fonction et celles qui lui sont connexes dans le fichier appearance.h. Si le texte que vous devez dessiner fait partie de votre interface utilisateur, utilisez le contrôle Texte Statique du panneau de contrôles Carbon dans la palette d’Interface Builder.

Le moteur de texte multilingue (MLTE pour Multilingual Text Engine en anglais) contient des routines plus performantes pour le tracé de texte. Sa routine de base est TXNDrawCFStringTextBox, qui prend une CFString en entrée. Puisque vous utiliserez probablement du texte Unicode dans votre application, vous préférerez probablement utliser TXNDrawUnicodeTextBox, qui prend une chaîne Unicode pure comme paramètre d’entrée.

Pour avoir accès à des routines plus performantes encore, vous devrez utliser les Services d’Ecriture Apple pour l’affichage Unicode  (ATSUI pour Apple Type Services for Unicode Imaging en anglais). La routine de tracé est ATSUDrawText, mais devrez utiliser d’autres fonctions ATSUI avant celle-ci pour mettre en place l’opération de tracé.

Ecrire du texte modifiable

Mac OS X inclut trois API que vous pourrez utiliser pour fournir du texte modifiable dans vos applications. La plus simple, EditUnicodeTextControl (ndt. : que nous pourrions traduire par contrôle de texte Unicode modifiable mais nous garderons le nom anglais dans la suite de ce document), est suffisante pour la pluaprt des situations. La deuxième, MLTE, offre toutes les fonctionnalités dont la grande majorité des développeurs aura besoin. Quelques rares développeurs devront utiliser la troisième, ATSUI. Les paragraphes suivants décrivent ces trois API.

EditUnicodeTextControl

EditUnicodeTextControl est l’outil le plus simple pour fournir du texte Unicode éditable. (Souvenez-vous que Mac OS X n’utilise que des chaînes Unicode, donc vous devez vous assurez que vous capturez tout texte saisi par l’utilisateur dans ce format). La routine utilisée pour créer un EditUnicodeTextControl s’appelle CreateEditUnicodeTextControl; vous pouvez la trouver dans le fichier ControlDefinitions.h.

Si la zone de texte dont vous avez besoin fait partie de votre interface utilisateur, utilisez le contrôle Texte modifiable du panneau de contrôles Carbon de la palette Interface builder. Dans le panneau des attributs dans la fenêtre d’information, assurez-vous d’avoir coché l’option “Unicode Edit Text.”

MLTE, le moteur de texte multilingue

MLTE offre une interface directement utilisable pour fournir du texte Unicode stylisé et modifiable dans vos applications. Construit à partir de ATSUI, MLTE offre le support pour :

• les tabulations, justification et marges
• la manipulation de texte de toute longueur (dans les limites de la mémoire tout de même !)
• l’affichage de texte dans toutes les langues supportées par Mac OS X
• l’édition de texte et le glisser-déposer tel que défini dans les directives d’interface utilisateur d’Apple
• la saisie en ligne du japonais et du chinois ainsi que d’autres langages
• l’insertion de sons, images et vidéos dans un champ texte
• la manipulation d’ascenseur et l’impression
• des polices avancées
• 32 niveaux d’annulation et de répétition

Les Services d’écriture Apple pour l’affichage Unicode (ATSUI)

ATSUI est la technologie d’écriture qui sous-tend tous les tracés de texte dans Mac OS X. Bien que d’autres API, construites à partir de ATSUI, offrent des fonctions plus simples de tracés de textes, ATSUI offre un très haut niveau de contrôle typographique.

ATSUI permet le rendu sophistiqué de texte encodé en Unicode 32 (avec notamment des options comme le crénage, les ligatures et l’alignement optique). Il gère automatiquement de nombreuses difficultés liées à l’affichage du texte, comme le rendu de texte bidirectionnel ou vertical de certains systèmes d’écriture.

ATSUI introduit de nouveaux objets qui permettent d’obtenir de meilleurs niveaux de contrôle et de flexibilité. Par exemple :

• des objets style, qui sont des ensembles de caractéristiques liées à des polices (appelés attributs de style de séquence ou style run attributes en anglais) qui s’appliquent à des séquences de texte.
• des objets de présentation de texte, qui sont associés aux styles de séquence, un tampon de texte et d’autres valeurs par défaut pour former un objet informatique que vous pourrez manipuler avec d’autres routines d’ATSUI.

ATSUI inclut des routines qui vous permettent d’utiliser différentes polices, styles de texte et des fonctions d’affichage. Parmi celles-ci citons :

• tracé et mise en relief de texte selon les typographies (polices et conventions de langues) impliquées
• recherche de polices disponibles et de celle qui correspond le mieux à un ensemble de contraintes
• obtention d’informations au sujet d’une police et des glyphes individuels au sein d’une police
• création et manipulation des objets style et des objets de présentation du texte
• manipulation des attributs de style de séquence et association de ceux-ci avec des séquences de texte
• déterminination des points d’insertion corrects selon l’endroit où le texte a été cliqué
• obtention des dimensions spatiales d’une ligne de texte imprimée
• calcul des lignes de rupture dans un corps de texte

Parce qu’ATSUI utilise Quartz, le moteur graphique 2D de Mac OS X, les utilisateurs d’ATSUI peuvent avoir accès, grâce à Quartz, au  redimensionnement des images, rotations et autes options de transformation.

Une note technique : En réallouant et en réutilisant les enregistrements ATSUStyle, vous pouvez augmenter la vitesse d’affichage des textes basés sur ATSUI. Voyez “Augmentez la performance de tracé de texte ATSUI” pour plus de détails.

Les autres API

Mac OS X inclut un certain nombre d’autres API liées au texte, aux polices et aux chaînes. En plus de celles évoquées jusqu’alors, voici celles dont vous aurez peut-être à vous servir :

• Les Services Texte Apple pour les Fontes (dont l’acronyme anglais est ATS) : Utilisés pour déterminer quelles polices sont disponibles sur l’ordinateur utilisé.
• Le Gestionnaire de conversion d’encodage des textes : Utilisés pour convertir des textes non-Unicode en Unicode.
• Les utilitaires Unicode : Utilisés pour déterminer les limites du texte dans une chaîne Unicode, convertir les touches frappées en texte Unicode et déterminer l’ordre alphabétique de deux chaînes Unicode (en prenant en compte les règles d’alphabet locales selon les préférences définies par l’utilisateur).

Compléments d’information

Vous trouverez toutes les API évoquéees ici sur la page de documentation des Développeurs Carbon qui se trouve à l’adresse http://developer.apple.com/techpubs/macosx/Carbon/carbon.html.

Gestionnaire d’apparence	http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/ AppManager/appearancemanager.html
Services Texte Apple pour les Fontes (ATS)	http://developer.apple.com/techpubs/macosx/Carbon/text/ATSTypes/atstypes.html
Services d’Ecriture Apple pour l’affichage Unicode (ATSUI)	http://developer.apple.com/techpubs/macosx/Carbon/text/ATSUI/atsui.html
Note technique “Augmentez la performance de tracé de texte ATSUI”	http://developer.apple.com/qa/qa2001/qa1027.html
Moteur de Texte Multilingue (MLTE)	http://developer.apple.com/techpubs/macosx/Carbon/text/MultilingualTextEngine/ multilingualtextengine.html
String Services (CFStrings)	http://developer.apple.com/techpubs/macosx/CoreFoundation/StringServices/ stringservices_carbon.html
Gestionnaire de conversion d’encodage des textes	http://developer.apple.com/techpubs/macosx/Carbon/text/ TextEncodConversionMgr/tecmgr.html
appearance.h (DrawnThemeTextBox)	situé sur le disque dur principal d’un ordinateur fonctionnant sous Mac OS X dans le chemin  /System/Library/Frameworks/Carbon.framework/Frameworks/ HIToolbox.framework/Headers/appearance.h
ControlDefinitions.h	situé sur le disque dur principal d’un ordinateur fonctionnant sous Mac OS X dans le chemin /System/Library/Frameworks/Carbon.framework/Frameworks/ HIToolbox.framework/Headers/ControlDefinitions.h
Exemples	http://developer.apple.com/samplecode/Sample_Code/Text.htm
Utilitaires Unicode	http://developer.apple.com/techpubs/macosx/Carbon/text/ UnicodeUtilities/unicodeutil.html

Internationalisation

Mac OS X est totalement internationalisé, il intègre nativement le support de fonctions d’entrée, d’affichage et de manipulations de textes d’une grande variété de langues. Mac OS X permet aussi aux applications tierces de participer facilement au grand concert des applications internationalisées. Ainsi, ce guide vous recommande, même si votre application n’est pas initialement prévue pour être multilingue, voire de supporter les locales (ensemble de paramètres liés aux cultures des différentes régions géographiques), de concevoir votre application pour pouvoir ajouter d’autres langues plus tard. Faire ceci ne coûte presque rien au moment du développement et vous facilitera la vie plus tard.

Présentation générale

Depuis l’apparition du premier Mac en 1984, Apple s’est efforcé de créer des ordinateurs capables de traiter toutes les principales langues du monde et leurs diférentes variantes locales (ainsi d’ailleurs que de nombreuses langues plus rares). Dès l’environnement de développement Carbon, qui encourageait les développeurs Mac OS 9 à créer des logiciels de telle façon à pouvoir être portés vers Mac OS X, Apple fournissait une architecture logicielle qui permettait le support approfondi de logiciels localisés.

Ce paragraphe présente différents termes et technologies relatifs à l’internationalisation de Mac OS X. C’est un préambule nécessaire pour apprendre à internationaliser vos applications Win32 tout en les portant vers Mac OS X.

Qu’est-ce que l’internationalisation ?

Afin d’être clairs nous ferons la distinction entre localisation et internationalisation comme ceci:

La localisation est le procédé qui consiste à changer un logiciel existant pour qu’il puisse être utilisé par un utilisateur d’une autre langue ou d’une autre variante de cette langue. Ce qui inclut de modifier tous les textes visibles, de remplacer toutes les images et sons inadéquats, de changer différents formats, unités de mesure pour ceux utilisés localement. Si l’utilisateur se sent à l’aise dans l’utilisation de votre version du logiciel parce qu’elle correspond à ses attentes linguistiques, culturelles ou en terme de format des données, alors c’est que vous avez réussi votre localisation.

L’Internationalisation (qui est le sujet de cette page) est le procédé qui consiste à concevoir et impléménter un nouveau logiciel de telle façon qu’il sera très simple à localiser. Ce qui signifie, tirer profit des facilités qu’offre le système d’exploitaiton plutôt que de coder “en dur” un produit pour une variante de langue.

Les ressources

Les ressources de Mac OS X, comme leurs homologues Windows, contiennent les données nécessaires à un logiciel, comme les textes, les icônes, les images, les listes de propriétés et les fichiers de données. Contrairement aux applications Win32, qui stockent leurs ressources dans une ou plusieurs bibliothèques liées dynamiquement (les DLL), Mac OS X stocke ses ressources individuellement, par exemple dans des fichiers son ou image, ou des fichiers conteneurs, par exemple tous les textes d’une application pour une langue donnée.

Comme vous le verrez au paragraphe suivant, les fichiers ressources doivent être stockés à des endroits bien précis. de plus, Mac OS X impose certaines contraintes sur certaines ressources, en particulier sur la nature, le nom et l’emplacement des fichiers contenant les ressources.

Les bundles

La page d’introduction de ce guide présentait un bundle comme un répertoire du système de fichiers contenant du code exécutable et les ressources liées. Mac OS X offre plusieurs types de bundles. Celui qui nous intéresse ici est appelé bundle d’application, qui contient le code exécutable et les ressources nécessaires pour implémenter une apllication. Pour simplifier les choses pour l’utilisateur, le Finder traite un bundle d’application comme un éxécutable et non comme un dossier. Et donc, quand il double-clique le dossier il exécute l’application plutôt que d’ouvrir le dossier.

Une chose importante à retenir est que la suite d’outil de développement d’Apple considère que votre bundle d’application est structuré selon quelques règles précises. Le fait de suivre ces règles simplifie votre code et le rend automatiquement internationalisé et donc facilement localisable en d’autres langues ou variantes locales de votre langue.

L’exemple ci-dessous montre la structure de répertoire d’un bundle d’application type:

MyApp/

MyApp /* alias to Contents/MacOS/MyApp */

Contents/

. MacOS/

. . MyApp

. . Helper Tool

. Info.plist

. PkgInfo

. Resources/

. . MyApp.icns

. . Hand.tiff

. . Horse.jpg

. . WaterSounds/

. . en_US.lproj/

. . . MyApp.nib

. . . bird.tiff

. . . Bye.txt

. . . house.jpg

. . . house-macos.jpg

. . . house-macosclassic.jpg

. . . InfoPlist.strings

. . . Localizable.strings

. . . CitySounds/

. . en_GB.lproj

. . . MyApp.nib

. . . bird.tiff

. . . Bye.txt

. . . house.jpg

. . . house-macos.jpg

. . . house-macosclassic.jpg

. . . InfoPlist.strings

. . . Localizable.strings

. . . CitySounds/

. . Japanese.lproj/

. . . MyApp.nib

. . . bird.tiff

. . . Bye.txt

. . . house.jpg

. . . house-macos.jpg

. . . house-macosclassic.jpg

. . . InfoPlist.strings

. . . Localizable.strings

. . . CitySounds/

. Frameworks/

. PlugIns/

. SharedFrameworks/

. SharedSupport/

L’éxécutable en cours est situé dans Contents/MacOS/MyApp, alors que toutes les autres ressources sont situées dans le dossier Content/Resources.

Dans un bundle d’application, toutes les ressources associées à une langue ou une variante de langue sont stockées dans un unique répertoire nommé <nom du langage ou pays ou abbréviation du langage>.lproj, dans le réperoire des ressources. Par exemple, le répertoire des ressources japonaises s’appelle Japanese.lproj (Japanese est le nom de la langue (japonais en anglais), alors que le répertoire contenant les ressources spécifiques à l’anglais brittanique s’appelle en_GB.lproj (en_GB est une abbréviation de la variante locale, comme décrit par la norme ISO 3166). Un troisième façon de spécifier un répertoire localisé consiste à utiliser l’abbréviation sur deux lettres de la langue, comme décrit par la norme ISO 639, par exemple,  en pour l’anglais.

Bien entendu, chaque fichier d’un répertoire  .lproj a son équivalent (portant le même nom) dans chaque autre répertoire .lproj. Chacun de ces fichiers est spécifique au langage concerné mais il doit avoir nécessairement le même nom que son homologue “original”.

Perspectives pour l’utilisateur et le développeur

Avant de connaître comment ajouter le support de nouvelles langues à votre application, vous devez d’abord comprendre comment Mac OS X présente le problème de l’internationalisation à la fois aux utilisateurs et aux développeurs.

Le point de vue de l’utilisateur

Les utilisateurs expriment leurs préférences en terme de langues grâce au module International de l’application Préférences Système. Dans le panneau Langues de ce module (voir ci-après), les utilisateurs peuvent glisser-déposer les noms des langues dans la liste déroulante pour indiquer quelles langues ils préfèrent utiliser (leur préférée est en haut de la liste) et, si la langue choisie n’est pas disponible, quelles autres langues ils préfèrent utiliser.

Par exemple, avec les réglages ci-dessus, l’utilisateur a exprimé son désir de voir tous les textes affichés par les logiciels, les nombres, et les données selon les habitudes des gens parlant la variante suisse du français. Si ce n’est pas possible, elle préfère utiliser son logiciel selon les conventions françaises. Si cela n’est pas non plus possible, elle préfère ensuite et dans cet ordre, l’anglais, l’espagnol, l’allemand, le hollandais, … et ainsi de suite jusqu’au bas de la liste.

Mac OS X fait en sorte que chaque application satisfasse au mieux aux préférences de langue de chacun selon les possibilités offertes par l’application en question. Une applicaion, par exemple, pourra présenter textes et menus en Français suisse parce qu’elle contient les ressources en français suisse. Une autre (qui ne contient ni français suisse, ni français, ni espagnol) s’affichera en anglais puisque c’est la langue la plus proche du haut de la liste des préférences qui soit disponible.

Il est important de noter que les utilisateurs de Mac OS X partent du principe que tout ce qu’ils doivent faire et de définir leurs préférences dans ce seul endroit. Dès qu’ils ont fait cela, chaque fois qu’un utilisateur ouvre une application, Mac OS X cherche automatiquement dans les ressources disponibles de cette application, celles qui conviennent le mieux aux préférences de l’utilisateur.

Le point de vue du développeur

Tout comme l’utilisateur, vous avez aussi un certain nombre de responsabilités qui, dès que vous les aurez remplies, vous offrirons certains avantages. Le bénéfice pour vous est le même que pour l’utilisateur : Mac OS X utilisera automatiquement les ressources les plus adéquates pour afficher les textes et données de votre application selon vos préférences de langue.

Pour vous donner un exemple concret, vous n’aurez jamais à écrire de code pour contrôler les variables des préférences de langue et définir en conséquence le bon texte à afficher dans un bouton. Au lieu de celà, vous n’avez qu’à éxécuter une procédure qui demande à Mac OS X de retrouver le texte du bouton. Mac OS X examine les préférences de langue de l’utilisateur en cours et renvoie la valeur du texte du bouton qui correspond le mieux aux préférences de l’utilisateur.

De part la façon dont Mac OS X traite les problèmes liés aux langues, les applications Mac OS X sont à la fois “neutre” et “transparente” vis-à-vis du langage. Être neutre signife ici, être capable d’afficher n’importe quelle langue de la même manière. Être transparent signifie que l’application ne s’occupe jamais de la langue dans laquelle elle sera utilisée. Cela signifie aussi que votre application ne contient aucun code conditionné par une langue donnée.

Unicode

Bien que le sujet d’Unicode ait été traité dans la page “Utilisation du texte dans Mac OS X” de ce guide, certains points méritent d’être répétés ici : Unicode est la base de toute manipulation ou stockage de texte dans Mac OS X. Unicode rend possible le fait d’utiliser un même système, un même code pour afficher des écritures aussi différentes que celles employées par l’arabe, le chinois traditionnel, l’italien ou le russe.

Création d’une application internationalisée

Ce paragraphe explique comment internationaliser vos applications, c’est-à-dire les concevoir et les écrire pour qu’elles soient neutres vis-à-vis des langues. (La localisation, le procédé par lequel on modifie une application pour qu’elle soit acceptable par les personnes d’une variante de langue donnée, est un procédé compexe qui ne sera pas décrit ici). Ce guide recommende que vous internationalisiez votre application en suivant les étapes suivantes, même si votre application ne supporte au départ qu’une seule langue ou variante de langue donnée.

Vous devez suivre les étapes suivantes pour internationaliser vos applications:

• Internationaliser les ressources d’interface statique.
• Internationaliser les ressources d’interface dynamique.
• Ecrire un code qui retrouve les ressources localisées.

Internationalisation des ressources d’interface statique

Les ressources d’interface statique sont simples à trouver, ce sont celles qui sont créées dans Interface Builder. Le résultat du travail d’Interface Builder est un fichier d’extension .nib.

Si un élément d’interface utilisateur contient des images ou des textes qui sont spécifiques à un variante locale de langue, le fichier .nib qui les contient doit être placé dans le dossier .lproj adéquat, et vous devez créer un fichier .nib distinct pour chaque variante de langue dont vous allez assurer le support. Vous utiliserez Interface Builder pour créer chaque version de .nib tandis que vous avancerez. Pour des raisons de performance et de facilité de localisation, Apple recommande que vous sauvegardiez tous vos menus dans un fichier .nib et que sauvegardiez chaque fenêtre ou boîte de dialogue dans son propre fichier .nib.

Selon les langues, la taille occupée à l’écran par une même phrase peut varier jusqu’à 30% quand elle est affichée. Quand vous localisez l’interface de votre application, utilisez autant que possible Interface Builder. En faisant ainsi, vous pouvez changer la taille et la position d’un élément pour l’adapter au besoin.

Certaines ressources, en général les images et les sons, sont les mêmes pour toutes les langues mais elles ne peuvent être manipulées au moyen de Interface Builder pour être insérées dans votre application. Dans ce cas, vous devez les stocker directement dans le dossier Ressources du bundle d’application.

Internationalisation des ressources d’interface dynamique

Si le texte visible par l’utilisateur n’a pas été défini directement dans Interface Builder, c’est votre code qui doit le générer dynamiquement pour l’afficher. Mac OS X offre le possibilité de n’écrire qu’un seul jeu de code et qui retrouvera automatiquement la chaîne localisée pour vos utilisateurs. Pour faire cela, vous devrez mettre toutes les chaînes visibles par l’utilisateur final dans un fichier formaté d’une façon précise et portant l’extenstion .strings. Vous devrez placer ce fichier dans le dossier .lproj approprié, avec évidemment une version spécifique à chaque variante de langue. Vous pouvez légèrement simplifier votre code en appelant votre fichier Localizable.strings. Un fichier .strings stocke les chaînes de caractères dans des paires clé/valeur, où la clé est une chaîne utilisée pour accéder à la valeur associée de cette chaîne, généralement la chaîne à afficher.

La plupart des ressources non-textuelles ont une signification pour l’utilisateur (par exemple, le fichier house.jpg dans le bundle d’application vu plus tôt) qui sera différente pour chaque culture. Ce qui signifie qu’elles doivent être placées dans des dossiers .lproj distincts. Ce guide recommande, sauf si vous êtes absolument certains qu’une ressource sera toujours la même partout dans le monde, de placer toutes les ressources non-textuelles dans des dossiers .lproj distincts.

Accéder aux ressources localisées

Pour accéder aux ressources localisées à utiliser dans votre application, vous utiliserez les fonctions contenues dans l’API CFBundle. La structure des bundles peut évoluer à l’avenir. Pour cela, il est important d’utiliser les fonctions de CFBundle pour accéder aux ressources localisées plutôt que de coder les chemins d’accès directement dans le code de votre application.

Accéder aux chaînes localisées

L’API CFBundle fait appel à la fonction CFBundleCopyLocalizedString pour accéder aux chaînes localisées d’un fichier .strings, mais il est plus simple d’utiliser la macro CFLocalizedString, qui s’appuie sur CFBundleCopyLocalizedString. CFLocalizedString extrait les chaînes de la version appropriée de  Localizable.strings du bundle de version en cours. Des variantes de cette macro peuvent accéder à des chaînes d’autres fichiers .strings et d’autres bundles.

quand vous passez à CFLocalizedString la chaîne-clé appropriée, elle vous renvoie la chaîne-valeur correspondante. Par exemple, la version italienne de Localizable.strings dans l’application Apple TextEdit contient les lignes suivantes:

/* Message indicating file couldn’t be opened; %@ is the filename. */
” Could not open file %@.” = “Non posso aprire il documento %@.”;

De même, la version française de Localizable.strings de TextEdit contient:

/* Message indicating file couldn’t be opened; %@ is the filename. */
” Could not open file %@.” = “Impossible d’ouvrir le fichier %@.”;

Quand l’application TextEdit veut afficher un dialogue à l’utilisateur pour lui indiquer que le fichier toto.txt ne peut être ouvert, il appelle CFLocalizedString en lui passant la chaîne-clé Could not open file %@. comme argument. Si la préférence de l’utilisateur va à l’italien,  CFLocalizedString renvoie la chaîne Non posso aprire il documento toto.txt. Si, en revanche, sa préférence va au français,  CFLocalizedString renvoie la chaîne Impossible d’ouvrir le fichier toto.txt.

Accéder à d’autres ressources localisées

Puisqu’il y a de nombreux types de ressources non-textuelles, l’API CFBundle fournit différentes fonctions retournant l’emplacement des ressources voulues. Dès que votre application connaît l’emplacement d’une ressource, elle peut prendre les mesures nécessaires pour afficher correctement la ressource.

Les fonctions que vous utiliserez la plupart du temps sont CFBundleCopyResourceURL et CFBundleCopyResourceURLsOfType. La première fonction renvoie l’emplacement d’une ressource spécifique. Ainsi, en utilisant le bundle  MyApp, en appelant CFBundleCopyResourceURL et en recherchant la ressource de type jpg nommée house la fonction retournera le chemin d’accès à la bonne version localisée de  house.jpg. La seconde fonction renvoie un tableau contenant toutes les ressources localisées d’un certain type (par exemple, toutes les ressources JPEG localisées). A nouveau, en utilisant le bundle MyApp par exemple, l’appel à CFBundleCopyResourceURLsOfType et la recherche de toutes les ressources de type jpg fait que la fonction retourne un tableau contenant les chemins d’accès vers les ressources localisées house.jpg et house-macos.jpg.

Outils

La traduction de tous les textes visibles par l’utilisateur est l’une des tâches principales de la localisation d’une application. Puisque les traducteurs ne sont pas des informaticiens et que le processus de changement “manuel” des textes peut entraîner des erreurs, des outils ont été développés pour aider les différentes parties intervenants dans la localisation. Deux de ses outils sont AppleGlot, d’Apple Computer, et PolyGlot, un produit d’une entreprise tierce.

AppleGlot peut extraire d’un logiciel Mac OS X les informations nécessitant une traduction et les stocker dans un fichier texte, ce qui permet aux traducteurs de traduire facilement les chaînes de caractères en utilisant un simple éditeur de texte. AppleGlot est aussi capable de réinsérer les chaînes traduites dans l’application.

AppleGlot gère aussi les mises à jour de localisation. En d’autre mots, quand un logiciel qui a déjà été localisé grâce à AppleGlot est modifié ou amélioré et que l’on relance l’extraction des chaînes dans AppleGlot, celui-ci mettra en évidence les chaînes qui ont été modifiées ou ajoutées et qui nécessitent d’être retravaillées. AppleGlot est compatible avec les applications Carbon, Cocoa, les librairies partagées et les frameworks.

Mac OS X s’attend à voir tous les textes Unicode encodés au format UTF-16. Certains éditeurs de texte sauvegardent le texte Unicode au format UTF-8 donc soyez attentifs au fait que votre éditeur peut être paramétré pour enregistrer le texte au format UTF-16. Sur Mac OS X, TextEdit d’Apple est capable de faire cela.

Notes à l’attention des développeurs Win32

Sur la plateforme Windows, on enregistre le texte Unciode au format “little-endian” (ndT: jeu de mot intraduisible, désolé !), ce qui signifie, que l’octet de poids faible est situé dans la partie basse de la mémoire. Sur les plateformes Mac OS X et Unix, on enregistre ces textes au format “big-endian”, qui stocke l’octet de poids fort en partie basse de la mémoire. Donc, si vous avez du texte Uniocde sous Win32, vous devrez d’abord le convertir au format “big-endian” pour le porter vers Mac OS X.

Certaines applications Win32 intègrent leur propre support des multiples langages. Si c’est le cas de votre application, Apple recommande que vous le transformiez au format des ressources localisées .nib et .strings. Cependant, si vous n’avez pas la possibilité de le faire, vous voudrez probablement porter votre méthode vers Mac OS X dans la première version de votre produit, puis ajouter le support international au format Mac OS X pour la version suivante.

Compléments d’information

Les liens ci-dessous pointent vers la documentation dont vous aurez besoin pour démarrer l’internationalisation de votre application.

La page de Localisation de Mac OS X (y compris un lien vers AppleGlot)	http://developer.apple.com/intl/localization.html
Inside Mac OS X: System Overview (voir le chapitre “Internationalisation”)	(HTML) http://developer.apple.com/techpubs/macosx/Essentials/ SystemOverview/index.html (PDF) http://developer.apple.com/techpubs/macosx/Essentials/ SystemOverview/SystemOverview.pdf (version papier) http://catalog.vervante.com/browseGroup.cfm? item_group_id=61316
Bundle Services Concepts and Tasks	http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/ Bundle_Services_Concepts/index.html
la documentation sur l’API  des Services Bundle	http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/ Bundle_Services/index.html
PowerGlot	http://www.powerglot.com

L’impression dans les applications Carbon

L’impression sous Mac OS X et Carbon est très similaire à l’impression sous Win32. En plus d’avoir des tâches distinctes de réglages avant l’impression et des tâches de nettoyage après celle-ci, la boucle principale d’impression des deux plateformes est quasiment identique:

1. Déclaration du début de la tâche d’impression (StartDoc pour Win32, PMSessionBeginDocument pour Mac OS X).
2. Déclaration du début d’une page (StartPage pour Win32, PMSessionBeginPage pour Mac OS X).
3. Propose (sensiblement) les mêmes commandes de tracé à l’écran que sur une imprimante.
4. Déclaration de la fin de page (EndPage pour Win32, PMSessionEndPage pour Mac OS X).
5. Déclaration de la fin de la tâche d’impression (EndDoc pour Win32, PMSessionEndDocument pour Mac OS X).

En outre, vous devez créer les routines de gestion des erreurs qui peuvent intervenir lors de l’impression.

L’interface utilisateur d’impression

Les trois dialogues et fenêtres qui sont utilisées lors de l’impresion sous Mac OS X ne sont pas très différentes de leurs équivalents Windows. Ce sont les dialogues d’impression, le dialogue de mise en page et la fenêtre du centre d’impression.

Le premier, le dialogue d’impression, permet à l’utilisateur de définir les différents paramètres associés au document qui doit être imprimé. Ce dialogue peut afficher différents panneaux selon les choix faits par l’utilisateur dans la pop-up d’options. Certains panneaux sont standards pour tous les dialogues d’impresion alors que d’autres sont spécifiques à une imprimante ou à une application. Vous pouvez ajouter vos propres panneaux en les définissant comme des extensions de dialogues d’impression (PDE en anglais); allez jeter un oeil dans les livres Extending Printing Dialogs et Printing Plug-In Interfaces Reference pour plus de détails.

les utilisateurs ne font appel au dialogue de mise ne page que s’ils ont besoin de modifier les valeurs par défauts de certaines propriétés d’impression. Comme pour le dialogue d’impression, vous pouvez ajouter des panneaux spécifiques à votre application au dialogue de mise en page.

Le centre d’impression est un utilitaire fourni avec Mac OS X. Sa fonction est de permettre à l’utilisateur de gérer les imprimantes et leurs travaux d’impression. Cet utilitaire affiche une unique fenêtre qui s’appelle Liste des Imprimantes (vois ci-dessous). Les utilisateurs peuvent voir les travaux en cours d’une imprimante et les suspendre, les annuler ou changer l’ordre dans lequel ils vont être imprimés.

Le gestionnaire d’impression de Carbon

Le gestionnaire d’impression carbon est l’API que vous devez utiliser pour implémenter l’impresion lorsque vous portez vos applications Win32 vers Mac OS X et le livre Supporting Printing in Your Carbon Application est le meilleur point de départ pour comprendre comment faire. Les sous-chapitres suivants donnent un aperçu des actions que votre application devra mettre en oeuvre pour se préparer et réussir ses impressions. Les noms entre parenthèses sont ceux des routines du gestionnaire d’impression Carbon qui vous utiliserez. Vous verrez que le processus est le même que celui utilisé pour l’impression dans une application procédurale Win32.

Définition du format de la page

Quand l’utilisateur clique sur le menu de mise en page, votre application doit faire les choses suivantes:

1. Créer un objet session d’impression (PMCreateSession).
2. Obtenir un objet de format de page valide pour le document (routine personnalisée de votre application).
3. Spécifier que le dialogue doit s’afficher lui-même comme une page (PMSessionUseSheets).
4. Afficher le dialogue de mise en page (PMSessionPageSetupDialog).
5. Enregistrer les valeurs pour une utilisation future.
6. Libérer l’objet session d’impression (PMRelease) et gérer toute erreur.

Exécution de la commande d’impression

Quand l’utilisateur clique sur le menu d’impression, votre apllication doit faire les choses suivantes:

1. Créer un objet session d’impression (PMCreateSession).
2. Créer un objet format de page valide (PMCreatePageFormat), si aucun n’existe.
3. Créer un objet paramètres d’impression (PMCreatePrintSettings).
4. Afficher le dialogue d’impression. (Ici l’utilisateur clique sur les boutons Imprimer ou Annuler et l’action appropriée a lieu).
5. Libérer l’objet session d’impression (PMRelease), remettre les paramètres d’impression à NULL et gérer toute erreur.

Quand l’utilisateur clique sur le bouton Impression, votre application doit exécuter le code de sa boucle d’impression.

La boucle d’impression

Le code de votre boucle d’impression doit faire les choses suivantes:

1. Déterminer le nombre maximum de pages pouvant être imprimées puis donner cette information à l’ordinateur.
2. Calculer les numéros des premières et dernières pages à imprimer à partir des données du dialogue d’impresion (PMGetFirstPage,PMGetLastPage), puis donner cette information à l’ordinateur.
3. Créer un nouveau travail d’impression (PMSessionBeginDocument).
4. Mettre en place une boucle pour tracer chaque page dans la fourchette spécifiée. (Les étapes 5 à 12 sont répétées pour chaque page)
5. Indiquer au système d’impression que le code qui suit marque le début d’une nouvelle page (PMSessionBeginPage).
6. Enregistrer le port graphique en cours (GetPort).
7. Récupérer le port d’impression graphique pour la page devant être imprimée (PMSessionGetGraphicsContext).
8. Définir le port graphique en cours comme étant le port graphique QuickDraw en cours (SetPort).
9. Récupérer le rectangle qui définit la zone dans laquelle le tracé peut être effectué (GetPortBounds).
10. Appeler le code qui dessine la page en cours
11. Restaurer le précédent port graphique (SetPort, en utilisant la valeur enregistrée à l’étape 6).
12. Fermer la page en cours (PMSessionEndPage).
13. Quand les étapes 5 à 12 ont été effectuées pour toutes les pages souhaitées, signaler la fin du travail d’impression (PMSessionEndDocument).

La gestion des erreurs

Vous devez écrire le code qui gère toutes les erreurs pouvant survenir pendant l’impression. Une partie de ce support inclut une procédure permettant l’affichage de messages d’alertes dans la langue préférée de l’utiliateur. Voyez la  page d’internationalisation de ce guide pour des détails sur la manière de faire cela propremement.

L’enregistrement au format PDF

Mac OS X enregistrant les pages de ses documents au format PDF pendant le processus de mise en tampon, il est très simple d’ajouter le support pour l’enregistrement au format PDF. Vous pouvez faire cela comme décrit ci-dessous :

1. Diriger votre code d’impression vers un fichier d’impression plutôt que vers une imprimante.
2. Ajouter le code qui permet de demander à l’utilisateur le nom de fichier désiré et son emplacement.
3. Décider si oui ou non les dialogues de mise en page et d’impression doivent faire partie du processus d’enregistrement au format PDF. Si vous décidez qu’elles ne doivent pas en faire partie (le cas le plus courant), vous devez ajouter le code qui ajoute automatiquement les valeurs “raisonnables” liées à la page à la place de celles transmises par les deux dialogues.
4. Lancer le processus d’impression.

En ajoutant ces quelques changements, vous pouvez utiliser le même code pour imprimer un document ou l’enregistrer en tant que fichier PDF.

Compléments d’information

Les liens ci-dessous pointent vers la documentation dont vous aurez besoin pour débuter l’implémentation de l’impression avec le gestionnaire d’impression Carbon.

La page d’impression de Mac OS X	http://developer.apple.com/printing
La page de documentation sur l’impression dans Mac OS X	http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/printing.html
La page de documentation du gestionnaire d’impression Carbon	http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager/ carbonprintingmgr.html
Inside Mac OS X: Supporting Printing in a Carbon Application	(HTML) http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager/ CPM_Concepts/index.html (PDF) http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager/ CPM_Concepts/SupportingPrinting.pdf
Inside Mac OS X: Carbon Printing Manager Reference	(HTML) http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager/ CarbonPrintingManager_Ref/index.html (PDF) http://developer.apple.com/techpubs/macosx/Carbon/graphics/CarbonPrintingManager/ CarbonPrintingManager_Ref/cpmref.pdf
Extending Printing Dialogs	(HTML) http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/ ExtPrintingDialogs/index.html (PDF) http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/ ExtPrintingDialogs/ExtPrintingDialogs.pdf
Printing Plug-In Interfaces Reference	(HTML) http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/ PrintingPlugin_Ref/index.html (PDF) http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/ PrintingPlugin_Ref/ppiref.pdf
Les fichiers d’en-tête du gestionnaire d’impression Carbon	PMApplication.h, PMCore.h, PMDefinitions.h (voir la note ci-dessous)
des exemples de code implémentant une simple boucle d’impression	http://developer.apple.com/samplecode/Sample_Code/Printing/CarbonQuartzDrawingWPrinti_.htm; aussi installé avec les Outils de Développement Apple dans le chemin /Developer/Examples/Printing/App/BasicPrintLoop
des exemples de code implémentant  des dialogues utilisant des feuilles	http://developer.apple.com/samplecode/Sample_Code/Printing/AppUsingSheets.htm; aussi installé avec les Outils de Développement Apple dans le chemin /Developer/Examples/Printing/App/AppUsingSheets
des exemples de code d’impression (inclut des exemples pour des versions antérieures à Mac OS X)	http://developer.apple.com/samplecode/Sample_Code/Printing.htm

Note: Les fichiers d’en-tête sont situés en différents endroits et le meilleur moyen de les trouver et de taper “locate <nomdefichier>” dans une fenêtre de terminal. Si la commande ne fonctionne pas, c’est que vous avez à construire la base de données de recherche sous-jacente ; voyez http://osxfaq.com/Tutorials/LearningCenter/UnixTutorials/WorkingWithUnix/page2.ws pour savoir comment faire cela.

L’interface utilisateur de Mac OS X

L’interface utilisateur est l’un des aspects les plus importants de votre application. Que vous aimiez cette idée ou pas, l’apparence visuelle de votre application donne à l’utilisateur une première impression de sa qualité et de votre compétence de programmeur. Alors que les utilisateurs continueront à travailler avec votre application, sa facilité d’utilisation, d’une manière ou d’autre, influera sur ce que les gens diront non seulement de votre application mais aussi de votre entreprise.

Les utilisateurs Macintosh sont habitués à des logiciels ayant une interface harmonieuse, familière et “faisant Mac”. Votre application a-t-elle l’aspect auquel vos clients Mac s’attendent ? Les éléments de l’interface fonctionnent-ils correctement ? Sont-ils à la bonne place ? Vos utilisateurs Mac seront-ils immédiatement à l’aise avec votre application ou seront-ils perturbés et irrités par son aspect inhabituel ? Une chose est sûre : Si vous faites un portage élément par élément de l’interface utilisateur de votre  application Win32, vous perdrez de nombreux utilisateurs potentiels.

Ce document vous donnera les informations clés que vous devez connaître pour porter l’interface utilisateur de votre application vers Mac OS X. Suite à celà, LE livre que vous devez lire, d’un bout à l’autre, est  Inside Macintosh OS X: Aqua Human Interface Guidelines.

Mais tout d’abord, vous devez en apprendre un peu plus sur vos nouveaux clients.

Les utilisateurs Macintosh

Les utilisateurs Mac sont habitués à des interfaces qui sont esthétiquement agréables, faciles à comprendre et à utiliser. Vous devez garder cela en mémoire pour concevoir votre application et la rendre attractive pour le public Mac. Apple fournit de nombreuses ressources concernant la conception des interfaces utilisateurs sur le site de retour d’expérience des utilisateurs à l’adresse http://developer.apple.com/ue/. Vous devriez jeter un oeil au contenu de ce site et aux règles à suivre présentées en détail sur ce site avant de vous lancer dans la conception de vos interfaces.

Que pouvez-vous faire pour faire de votre application portée sur Mac OS X un gagnant sur le plan de l’interface utilisateur ? Apprenez à connaître votre nouveau public et embauchez des gens qui peuvent vous aider. Voici quelques idées pour démarrer:

• Faites appel à un consultant qui possède l’expérience de la conception d’interface utilisateur pour Mac OS X. (Souvenez-vous que Mac OS X est complétement différent des anciens systèmes Mac, une expérience récente est donc nécessaire).
• Etudiez les applications Mac OS X concurrentes de la votre.
• Etudiez les applications intégrées à Mac OS X, comme par exemple, TextEdit et iTunes.
• Lisez un livre de formation à Mac OS X. (C’est une bonne manière de connaître les fondamentaux que tout utilisateur Mac considère comme des évidences).
• Lisez les magazines MacAddict et Macworld, en particulier les articles sur les logiciels (ndt : Ces magazines sont américains mais il existe aussi une presse Mac francophone disponible dans tous les kiosques)
• Allez rendre visite à un groupe d’utilisateurs Macintosh et discutez avec les gens que vous rencontrez.

Construire une application Mac OS X

Bien qu’il soit possible de construire une application Mac OS X en utilisant simplement un compilateur et un éditeur de texte, ce n’est assurément pas la meilleure façon de faire. Apple propose gratuitement une suite logicielle d’outils puissants de développement pour Mac OS X. Les deux principaux programmes de cette suite sont Interface Builder, pour la création de l’interface utilisateur et Project Builder, pour l’écriture, la compilation et le débogage de votre application. (D’autres environnements de développements sont disponibles pour Mac OS X : CodeWarrior de MetroWerks est un de ces IDE.)

Puisque ce document concerne les interfaces utilisateurs de Mac OS X, l’introduction au développement d’une application mettra en exergue l’utilisation d’Interface Builder, même si vous passerez beaucoup plus de temps dans Project Builder. Mais une introduction se doit d’être brève.

Avant de vous lancer dans un travail assidu avec Interface Builder ou Project Builder, vous devriez étudier au moins l’un de ces deux livres : Learning Carbon, disponible chez l’éditeur O’Reilly, ou Converter: Creating a User Interface with Interface Builder, un petit livre disponible sur le site web d’Apple. Chacune de ces ressources vous présente le processus de développement sur Mac OS X en créant une petite application simple.

Voici les étapes à suivre pour créer une nouvelle application Mac OS X :

1. Créez un nouveau projet dans Project Builder. Le système de développement de Mac OS X organise tous les composants liés à une application donnée dans ce qu’il est convenu d’appeler un projet. Commencez par choisir le menu “Nouveau Projet …” puis choisissez un modèle de projet dans la liste présentée. Vous choisirez probablement le modèle de projet “application Carbon basée sur nib”. (Dans une prochaine étape, vous utiliserez Interface Builder pour fabriquer votre interface utilisateur et la sauvegarderez en tant que fichier nib. Plus tard, votre application utilisera les données contenues dans ce fichier pour créer son interface utilisateur).
2. Ouvrez le fichier nib associé à ce projet. Vous faites cela en double-cliquant sur le fichier main.nib dans la fenêtre principale du projet qui apparaît quand vous avez créer le nouveau projet. Ceci lance Interface Builder.
3. Faites glisser les contrôles dans la fenêtre de votre application. Interface Builder affiche une fenêtre vide par défaut ainsi qu’une barre de  menus préfabriquée. Vous commencez votre interface en faisant glisser des éléments d’interface appelés contrôles de la palette jusque dans la fenêtre. (Une application peut, bien entendu, avoir plusieurs fenêtres, mais cette présentation évoque une application n’en ayant qu’une).
4. Définissez les attributs de chaque contrôle dans sa fenêtre d’information. Ce procédé configure le contrôle, paramètre son apparence et quelques comportements. De plus, vous définissez les informations spécifiques qui vosu permettront d’accéder à vos contrôles depuis le code de votre application.
5. Configurez la barre de menus et ses éléments de menu. Vous pouvez ajouter et supprimer des menus tout comme des éléments de menu  de la barre de menus proposée. Vous utilisez aussi la fenêtre d’information pour définir les propriétés des éléments de menus.
6. Depuis Project Builder, construisez et lancez l’application. La première fois que vous construisez l’application, Project Builder génère le bundle qui forme la base de votre application. Bien que cette application n’ait pas de contenu ni de comportement particulier, elle implémente des comportements par défaut de Mac OS X. Les contrôles et les menus génèrent des évènements (messages dans la terminologie Windows) quand vous interagissez avec eux.
7. Ecrivez le code des descripteurs d’évènements. Vous devez écrire un descripteur d’évènements pour chaque contrôle et chaque élément de menu spécifique à votre application.
8. Ecrivez le code pour implémenter le descripteur d’évènement de la fenêtre princiaple. Ceci permet aux contrôles de ne recevoir que les évènements qui les concernent.
9. Déboguez votre application. Project Builder inclut une interface visuelle à gdb, le débogueur GNU.

Un point important : La meilleure façon de porter votre interface utilisateur vers Mac OS X est de la re-créer selon le procédé de développement du couple Project Builder/Interface Builder. Heureusement, Interface Builder inclue des accessoires qui vous montre où placer les éléments de l’interface pour respecter les règles de placement et d’espacement édictées par Apple. De même, l’interface Aqua inclue deux tailles différentes pour certains éléments d’interface (champs textes et boutons notamment). Ces deux choses rendent la conception des fenêtres et dialogues plus simple et plus rapide.

Différences entre Aqua et Win32

Aqua est le nom de l’interface distinctive de Mac OS X. Bien que son apparence soit strictement “21ème siècle” (ndt : je ne fais que traduire les propos de l’auteur !!), elle offre tous les éléments caractéristiques d’une interface utilisateur moderne. Il y a quelques éléments d’interface Win32 qui n’existent pas dans Aqua, et réciproquement, mais Aqua fournit toute une gamme complète d’éléments pour n’importe quel projet.

Il est important de connaître les différences existant entre votre plateforme actuelle et Mac OS X. Ce chapitre résume ces différences, ce qui vous permettra d’être plus efficace plus rapidement.

Différences de terminologie

La première différence dont vous devez avoir conscience est celle de la terminologie. Certains éléments ont les mêmes fonctions (ou à peu près) sur les deux plateformes mais portent des noms différents. Le tableau 1, ci-dessous, fait la liste de ces différences d’appellation.

Tableau 1. Différences de terminologie entre les éléments d’interface utilisateur Win32 et Mac OS X Win32 Mac OS X Bureau et Icônes barre de tâches Dock barre de lancement rapide Dock raccourci (icône) alias bouton de fenêtre (dans la barre de tâches) tuile (dans le Dock) Fenêtres et dialogues Boutons Réduire, Agrandir/Restaurer et Fermer Boutons Fermer, Réduire et Zoom boîte de déroulement (scroll box) dérouleur (scroller) poignée de taille (size grip) contrôle de taille (resize control) boîte de dialogue dialogue boîte de message alerte fenêtre secondaire (un terme qui inclut les les feuilles de propriétés, les inspecteurs, les boîtes de dialogue, les fenêtres de palettes, les boîtes de message et les pop-ups) fenêtre utilitaire (une fenêtre flottante sans barre de titre utilisée pour les feuilles de propriétés, les inspecteurs, les palettes et autres usages mais pas les dialogues) Fenêtres de propriétés (pour les répertoires et les fichiers) Fenêtre d’informations (pour les dossiers et les fichiers) Boîte de dialogue d’ouverture (utilisée pour parcourir le système de fichiers) Dialogue d’ouverture Boîte de dialogue “Enregistrer sous” Dialogue de sauvegarde panneau de contrôle panneau de préférences (un panneau de l’application Préférences Sytème utilisé pour définir les préférences liées à un service spécifique) Contrôles bouton de commande bouton poussoir bouton d’option bouton radio case à cocher (check box) case à cocher (checkbox) boîte de liste liste déroulante (scrolling list) liste déroulante (drop-down listbox) menu de commandes déroulant (command pop-down menu) boîte de texte (edit control) champ de saisie de texte liste déroulante (drop-down combo box) liste déroulante (combo box) glissoir (slider  ou trackbar control) contrôle glissant (slider control) contrôle de vue hiérarchique (tree view control) navigateur de données (data browser  ou list view) bouton “+/-” dans une vue arborescente triangle de fermeture Divers Info-bulle balise d’aide

La principale ambiguïté que vous rencontrerez dana la terminologie est le mot évènement. Dans la terminologie Mac OS X, un évènement Carbon est exactement ce que Win32 appelle un message, la donnée que reçoit un contrôle lorsqu’une action système ou utilisateur a lieu. (A cause de sa nature orientée objet, l’environnement applicatif Cocoa gère les évènements de manière similaire mais non identique).

Différences dans l’interface utilisateur

Comme vous pouvez le constater dans les tableaux 2 et 3 (ci-dessous), Win32 et Mac O X possèdent chacun des éléments d’interface que l’autre n’a pas. Les différences sont cependant mineures. Vous devriez pouvoir adapter votre interface utilisateur Win32 à Mac OS X sans trop d’effort supplémentaire. Et qui sait, peut-être trouverez certains éléments propres à MAc OS X très utiles dans votre application portée.

Tableau 2. Eléments d’IU Win32 sans équivalent Mac OS X. Win32 Notes Fenêtres barre de menus La barre de menus en haut du Bureau de Mac OS X remplit la même fonction. Icônes de menu de la barre de titres Le menu de l’application de Mac OS X contient des éléments similaires Contrôles Contrôle vue de liste (list view control) Peut être créé à partir d’un gestionnaire de liste contrôle de vue hiérarchique (tree view control) Le contrôle navigateur de données n’est pas l’équivalent parfait mais vous pouvez l’utiliser dans le même but. boîte de texte riche (rich-text box) Utilisez la boîte de texte riche éditable de l’API MLTE. boîte tournante (spin box) Vous pouvez utiliser un champ de saisie de texte ou une liste déroulante avec un menu pop-up calendrier (date-picker control) Peut être créé manuellement contrôle navigateur web Dans la plupart des cas, le visualiseur d’aide existant remplit les mêmes fonctions barre d’outils/ barre de statut Vous pouvez créer la barre d’outils dans la fenêtre ou utiliser une fenêtre utilitaire. Aide balloon tip Utilisez soit les balise d’aide (help tag) soit les alertes selon la situation.

Table 3. Eléments d’IU Mac OS X UI sans équivalent Win32 Mac OS X Description Fenêtres icône proxy Il s’agit de l’icône située juste à gauche du titre de la fenêtre. Il représente le contenu de la fenêtre dans les glisser-déposer. Contrôles navigateur de données en colonnes (column-view data browser) Un contrôle qui permet de naviguer dans une structure hiérarchique affichée sous forme de colonnes et où les éléments d’une colonne sont le contenu de l’élément mis en valeur dans la colonne de gauche (voir la seconde capture d’écran de la partie “contrôles” ci-dessous). Le Finder Mac OS X utilise ce contrôle comme un des moyens de visualiser le contenu de votre disque dur. menu pop-up Identique à une liste déroulante (drop-down combo box) qui permet uniquement des entrées présentes dans la liste. placard Petit panneau d’information, souvent placé à la gauche d’une barre de défilement horizontale ; peut contenir un menu pop-up. bouton biseauté (bevel button) Un gros bouton poussoir qui peut se comporter comme un bouton radio ou une case à cocher; il peut aussi avoir un menu pop-up. bouton icône pop-up Une variation du bouton biseauté avec menu pop-up. puits d’image Une zone rectangulaire qui permet d’afficher une icône ou une image et qui sert de cible dans une opération de glisser-déposer. L’apparence d’un puits d’image est l’image dans un plan légèrement en retrait du plan de son entourage. bouton de fermeture (disclosure button) Utilisé dans les fenêtres ou les dialogues pour afficher ou masquer des informations complémentaires dont seuls quelques utilisateurs auront besoin. contrôle d’adéquation (relevance control) Utilisé pour indiquer l’adéquation du résultat d’une requête avec la requête originale. Divers Touche de commande (sur le clavier) La touche utilisée pour le raccourci (différente de la touche de contrôle).

Présentation des éléments d’interface utilisateur par catéorie

Après une discussion générale sur les adeptes de Mac, Aqua et le processus de développement Mac OS X, il est temps de regarder de plus près les éléments de l’interface Mac OS X et en quoi elle diffère de celle d’une application Win32. Les paragraphes qui suivent, complétés par une lecture assidue de Inside Macintosh OS X: Aqua Human Interface Guidelines, vous donneront le fonds de connaissances nécessaire pour une bonne approche de l’interface Mac OS X.

Les sujets traités dans cette partie seront :

• le bureau
• le Dock
• les icônes
• les menus
• les fenêtres
• les dialogues
• les contrôles
• la souris
• le clavier
• l’aide
• un paragraphe “divers”

Le bureau

Dans son rôle de surface idéalisée sur laquelle viennent s’afficher les fenêtres, les dialogues et les fenêtres utilitaires (palettes), le bureau est familier à la fois aux utilisateurs de Mac et de Windows. Comme c’est le cas de certains ordinateurs fonctionnant sous Windows, nombre de machines Apple peuvent être reliées à plusieurs écrans d’affichage ; dans ces cas, on dit que le bureau “porte” sur plusieurs moniteurs.

L’une des principales différences entre Windows et les systèmes Mac (historiquement et dans Mac OS X) est la relation sur le bureau entre l’application et les documents qui lui sont rattachés. Dès le départ, les règles de conduite pour les interfaces utilisateurs Apple insistèrent sur l’importance d’utiliser des comparaisons avec des objets matériels de notre quotidien pour permettre aux utilisateurs de mieux comprendre le fonctionnement d’applications qu’ils découvraient. En conséquence, la plupart des applications affichent leurs documents dans une fenêtre distincte que les utilisateurs apprécient parce qu’elle leur rappelle ce qu’ils faisaient avec leurs documents papier. On insiste sur le document et l’application sous-jacente est en grande partie invisible. L’application en elle-même n’a pas de fenêtre et sa présence n’est perceptible par l’utilisateur qu’à travers les menus et leurs contenus.

Par opposition, Microsoft a développé l’Interface à Documents Multiples (MDI) pour les applications pouvant manipuler plusieurs documents simultanément. Dans cette interface, l’application a sa propre fenêtre et ses documents peuvent être visibles ou pas dans la zone client de la fenêtre de l’application.

Quelles sont les conséquences pour vous, en tant que développeur souhaitant porter votre application vers Mac OS X ? Bien entendu, cette approche rend les applications Mac OS X plus simples à comprendre et à utiliser. Mais d’un point de vue programmation, cette différence ne change pas grand’chose. Les deux plateformes se basent sur les mêmes concepts : une application gérant plusieurs documents simultanément ouverts avec des évènements transmis à la fenêtre destinée à les recevoir. A cause de cela, le principe d’architecture n’aura pas à être bouleversé pour porter votre application vers Mac OS X.

Si vous avez une application MDI, il ya une simplification structurelle que vous pourrez faire. Puisque du côté Mac OS X, il n’y a pas de fenêtre parent englobant les fenêtres des documents, vous devrez éliminer de votre code les éléments de menus qui s’occupent de gérer la visibilité et la position des documents au sein de la fenêtre parent (comme par exemple, les éléments de menus pour fractionner l’affichage et afficher en cascade les documents).

Le Dock

En tant que développeur Win32, vous ne devez pas être familiarisé avec l’objet du bureau Mac OS X appelé Dock, qui est plutôt une “étagère” (généralement au bas de l’écran) sur laquelle sont posées de grandes icônes d’applications appelées “tuiles”. Le Dock contient obligatoirement les icônes des applications en cours d’exécution. Mais il contient aussi les icônes d’applications que l’utilisateur souhaite conserver à portée de main. L’utilisateur peut facilement savoir quelles applications sont en cours d’exécution car celles-ci ont un petit triangle noir près de leur tuile. Les tuiles sont placées dans le Dock par Apple mais aussi par l’utilisateur (les tuiles du Finder et de la corbeille sont néanmoins des occupants permanents du Dock).

En tant que développeur, vous ne pouvez agir sur le contenu du Dock. Vous pouvez, cependant, ajouter des éléments de menus au menu pop-up qui apparaît quand vous pressez et maintenez le bouton gauche de la souris tout en pointant sur la tuile de votre application dans le Dock.

Pour plus d’information concernant le Dock, y compris d’importants comportements à implémenter, rendez vous sur la page web du Dock.

Les icônes

Aucun élément visuel de Mac OS X n’est plus frappant que ses icônes photos-réalistes. Les icônes de Mac OS X ont une taille de 128  pixels par 128, avec anti-aliasing, canaux alpha et effets de transparence possibles pour améliorer l’apparence de l’icône. Bien que ce ne soient, en fait, que des illustrations, elles ressemblent à de véritables photos.

Mac OS X aide les utilisateurs à reconnaître la fonction d’une icône donnée en spécifiant que chaque icône doit appartenir à l’un des différents genres d’icône:

• Application utilisateur
• Utilitaire
• Visualiseur/Lecteur/Accessoire
• Document
• Préférence
• Plug-in
• Matériel
• Support amovible

De plus, Apple encourage l’utilisation des familles d’icônes, c’est à dire d’icônes assoicées à une même application. Chaque application devrait avoir, en plus de l’icône de l’application elle-même, des icônes pour quelques unes des catégories suivantes: Document, préférences, plug-in et peut-être d’autres spécifiques à votre application. Toutes les icônes d’une famille devraient être conformes à une même charte (par exemple, les icones des documents sont rectangulaires et ont leur coin supérieur droit recourbé vers l’intérieur en triangle) et doivent être visuellement liées par un élément graphique commun.

Pour plus d’information concernant les icônes, y compris d’importants comportements à implémenter, rendez vous sur la page web des icônes.

Les menus

Une grosse différence entre les deux plateformes et l’utilisation par Mac OS X d’une seule barre de menus en haut de l’écran, plutôt qu’une barre de menus par fenêtre d’application comme c’est le cas avec Windows. Bien que l’effet visuel soit différent, il y a peu de différences fonctionnellement. Dans les deux cas, l’utilisateur voit la barre de menu associée au document en cours de traitement, la seule différence étant l’emplacement de cette barre de menus. Dans Mac OS X, lorsque l’utlisateur passe d’un document à un autre ouvert dans une autre application, le système bascule automatiquement vers le menu et les éléments associés de l’application désormais active.

Informatiquement, vous créez vos menus et éléments de menus sous Mac OS X de la même façon que sous Windows en utilisant Interface Builder ou un autre IDE.

Voici quelques remarques concernant les menus dans Mac OS X:

• Parce qu’une fenêtre Mac OS X n’a pas de barre de menus, elle n’a pas non plus de menu de document ou de menu d’application (les menus sur les icônes des barres de menus d’un document ou d’une application MDI). La plupart des fonctions contenues dans ces menus se retrouvent dans le menu Pomme et le menu Application (voir plus loin).
• Le menu Pomme (ndt. certains l’appellent ainsi, d’autres gardent le nom américain Apple), celui marqué par le logo bleu d’Apple tout à gauche de la barre de menus, est commun à toutes les applications et est systématiquement disponible. Son contenu est défini par Apple, vous ne pouvez pas le modifier.
• Le menu Application apparaît directement à droite du menu Pomme. Son nom est celui de l’application active. (Par exemple, si TextEdit est l’application active, le menu immédiatement à droite du menu Pomme s’appelle “TextEdit”). Le menu Application contient les éléments “A propos de” et “Préférences” ainsi que “Services” et “Quitter”. Votre application pourra utiliser les services fournis par le système du sous-menu Services ou bien elle pourra fournir ses propres services aux autres applications. Pour plus de détails sur ce point, voyez Inside Mac OS X: Setting up Your Application to Use the Services Menu.
• Vous devriez inclure dans votre application, les menus Fichier, Edition, Fenêtre et Aide. De façon générale, les menus spécifiques à votre application devrez apparaître à droite du menu avant le menu Fenêtre.
• A l’extrême droite de la barre de menus, Apple fait apparaître différents éléments (qui ne sont pas des menus) appelés “éléments de statut de la barre de menus”. Ces éléments sont des rappels de certains réglages matériels ou réseaux. Vous ne devriez pas placer d’éléments de statut à cet endroit mais plutôt dans la tuile du Dock représentant votre application.

Pour plus d’information concernant les menus, voyez la page web des menus.

Fenêtres

Il est généralement acquis que différents types visuels de fenêtres facilite la lecture de l’utilisateur. Mac OS X utilise les types de fenêtres suivants :

• fenêtres de document
• tiroirs
• fenêtres utilitaires (palettes)
• dialogues

Les dialogues sont, techniquement parlant, des fenêtres. Néanmoins, parce que leur fonction est radicalement différente de celle des autres fenêtres, ils seront présentés à part.

Les fenêtres Mac OS X ont de nombreux comportements précis que l’utilisateur s’attend à retrouver. Certains de ces comportements sont fournis automatiquement par le système d’exploitation lui-même, comme par exemple ce qui permet de déplacer ou redimensionner les fenêtres. Vous devez implémenter certains comportements et décider, dans certains cas, ceux qui doivent être impléméntés. Voici quelques exemples :

• la taille et l’emplacement de nouvelles fenêtres
• les conditions dans lesquelles les barres de défilement apparaissent et leur comportements de défilement
• le défilement automatique du contenu d’une fenêtre sous certaines conditions
• le “clic à travers” (ce qui se passe lorsque vous cliquez sur un contrôle d’une fenêtre inactive)
• le comportement du bouton de zoom

Pour plus d’information concernant les fenêtres et les tiroirs, voyez la page web des fenêtres et tiroirs.

Fenêtres de document

Les fenêtres de document offre le cadre de la représentation visuelle des données utilisateur. Si votre application n’a pas de document en tant que tel, vous voudrez probablement utiliser une fenêtre de document pour représenter l’application en elle-même.

Tiroirs

Un tirroir est une fenêtre enfant qui glisse hors d’une fenêtre parent. L’utilisateur peut l’ouvrir ou la fermer tant que la fenêtre parent est ouverte. Vous emploierez généralement un tiroir pour afficher les contrôles les plus courants et qui n’ont pas besoin d’être affichés en permanence. (Si des contrôles doivent être visibles en permanance, vous devriez les placer dans une fenêtre utilitaire ou dans une barre d’outils au style Mac OS X).

Pour voir un bon exemple de tiroir, ouvrez l’application Mail de Mac OS X (dans le dossier Applications). Cliquez sur l’icône Boîtes en haut de la fenêtre Mail pour voir le tiroir, qui contient les icônes Boîte de Réception, boîte d’envoi, Poubelles ainsi que les boîtes créées par l’utilisateur.

Fenêtres utilitaires

Les fenêtres utilitaires (aussi appelées palettes) flottent au-dessus des fenêtres de document. Elles fournissent en général des outils, des contrôles ou des réglages qui affectent la fenêtre document active. Il est de votre responsabilité de les créer et de les faire vivre.

Les fenêtres utilitaires de Mac OS X diffèrent de leurs équivalents Windows sur plusieurs points importants:

• Elles ont une bande de tirage pour permettre à l’utilisateur de les reposisitionner sur le bureau, mais cette bande n’a en général pas de titre.
• Quand votre application est en arrière-plan (c’est à dire, que ses fenêtres sont inactives mais visibles) ses fenêtres utilitaires devraient être cachées. (Vous êtes responsable de l’implémentation de ce comportement).
• En plus des fenêtres utilitaires propres à chaque application, Mac OS X offre aussi la possibilité d’utiliser des palettes valables dans tout le système qui restent visibles même si l’application parent est invisible.

Dialogues

Les dialogues sont des fenêtres que votre application utilise pour récupérer des informations de l’utilisateur. Les dialogues qui afichent de l’information vers l’utilisateur sans attendre de retour sont appelées alertes (dans la terminologie Windows ce sont les boîtes de messages). La plateforme Windows peut afficher deux types de dialogues, modal et non-modal. Mac OS X fait la distinction entre deux types de fenêtres modales :

• les dialogues modaux d’application. Ceux-ci sont très similaires aux dialogues modaux de Windows en ce qu’aucun travail ne peut être acompli dans l’application avant que ce dialogue ne soit fermé.
• les dialogues modaux de document. Ces dialogues doivent être fermés avant que l’utilisateur ne puisse continuer à travailler sur le document auquel est attaché le dialogue. L’utilisateur peut cependant continuer à travailler sur d’autres documents appartenant à la même application.

Les dialogues modaux de document ont une apparence différente ; dans la terminologie Apple, ils s’appellent feuilles. Une feuille semble pousser de la barre de titre de la fenêtre de document, et lorsqu’elle se ferme, elle disparaît de la même manière.

Pour plus d’information concernant les dialogues et les feuilles, voyez la page web des dialogues et des feuilles.

Naviguer dans le système de fichiers et sauvergarder des fichiers sont deux activités importantes pour l’utilisateur et Mac OS X propose les dialogues d’ouverture et de sauvegarde dans ce but. Vous utiliserez l’API Services de Navigation pour créer les dialogues d’ouverture et de sauvegarde. Alors que nous écrivons, la version actuelle de l’API Services de Navigation est la 3.0, soyez donc sûrs de ne pas tenir compte de versions plus anciennes de documentation Apple des services de navigation. Mac OS X propose aussi des dialogues qui aide l’utilisateur à choisir une imprimante, mettre en page un travail d’impression et imprimer un document.

Contrôles

Comme évoqué précédemment, Mac OS X inclut un ensemble complet de contrôles pour construire votre interface utilisateur. La plupart des contrôles auxquels vous êtes habitués ont leurs équivalents dans Mac OS X. Dans les cas où il n’y a pas d’équivalent (voir le tableau 2 ci-dessus), il y a toujours un moyen de fournir un comportement équivalent quand vous portez votre application vers Mac OS X.

Depusi la version 10.2 de Mac OS X (Jauguar), Apple utilise une nouvelle API pour tracer les contrôles appelée HIView. Cette méthode, qui est très comparable à l’implémentation Win32 de contrôles comme des fenêtres enfants, remplace largement l’acienne API Gestionnaire de contrôle utilisée dans les versions précédentes de l’OS. Il est à noter cependant que vous devrez toujours utliser l’API Gestionnaire de contrôle pour certains contrôles, comme par exemple la boîte de liste, le champ texte déroulant et les contrôles de navigation de données.

HIView est une API orientée objet qui ofre nombre d’avantages par rapport au Gestionnaire de contrôle. Grâce au procédé appelé composition, HIView peut tracer des contrôles complexes plus rapidement. De plus, vous pouvez tirer partie de l’héritage en sous-classant des contrôle HIView pour créer des contrôles aux comportements personnalisés. HIView est une API basée sur Quartz-2D, mais vous pouvez toujours l’utiliser à partir d’appels QuickDraw.

Vous devriez vous familiariser avec un contrôle très utile et très puissant de Mac OS X qui n’est pas disponible dans Windows, le navigateur de données. Il peut prendre deux formes : Une vue en liste (présentée ci-dessus pour afficher et modifier les données présentées en lignes et colonnes) et une vue en colonnes (présentée ci-dessous, que Mac OS X utilise comme un des moyens de présenter une hiérarchie de fichier dans le Finder).

La souris

Si vous avez conçu votre produit pour qu’il fonctionne avec une souris à deux boutons, vous devez vous faire du souci au sujet des souris à bouton unique qui accompagne chaque ordinateur Macintosh. Mac OS X fournit le support complet pour les souris à boutons multiples y compris pour les souris à roulette.

Il est vrai que chaque Mac est accompagné d’une souris à un bouton ; mais ce n’est pas un problème que vous devrez gérer. De nombreux utilisateurs Mac savent que l’on affiche le menu contextuel Mac (un menu pop-up) en appuyant sur la touche Contrôle et en cliquant sur le bouton de la souris. Mac OS X a été conçu de telle sorte que cliquer sur le bouton droit affiche le menu contextuel. Ce qui signifie que le comportement du bouton droit de votre application Win32 correspond naturellement dans Mac OS X. Mais, parce que certains utilisateurs n’utilsent pas le menu contextuel, Apple recommande fortement que tous les éléments de menus accessibles par les boutons droit et du centre soient aussi disponibles dans les menus de votre application.

Quelques remarques techniques : Mac OS X supporte les souris à trois boutons grâce au paramètre kEventParamMouseButton, qui est fournit comme un sous-ensemble de l’évènement souris-appuyée (mouse-down) ou souris-relevée (mouse-up). De même, Mac OS X supporte la roulette de défilement grâce à l’évènement kEventMouseWheelMoved, qui est envoyé à la file d’évènements système dès que la roulette de la souris est déplacée. Voyez le chapitre “Evenements de la souris” de Inside Mac OS X: Handling Carbon Events pour plus de détails.

Le clavier

Apple a toujours préféré la manipulation directe à la frappe, avec pour conséquence que les utilisateurs Mac ne s’attendent pas à avoir des raccourcis-clavier pour tous les éléments de menus. Pour ceux qui ont des difficultés à utiliser la souris, Apple a inclus une option d’Accès Total par le Clavier, qui permet aux utilisateurs d’accéder aux menus, aux contrôles et au Dock depuis le clavier.

Les équivalents clavier de Mac OS X sont caractérisés par l’utilisation de la touche Commande (ndt. la fameuse touche “Pomme”), une touche supplémentaire qui n’a pas d’équivalent sur les claviers Windows. (Les claviers Apple ont aussi une touche Contrôle et une touche Option qui est le pendant de la touche Alt). Apple a des standards pour ces équivalents clavier, le plus souvent la touche Commande et une lettre minuscule, pour les éléments de menus communs à toues les applications (par exemple, Commande plus les lettres z,x,c et v pour Annuler, Couper, Copier et Coller). Mac OS X indique qu’un élément de menu a un raccourci clavier en affichant le raccourci à droite du menu concerné (voir la copie d’écran au chapitre “Menu” ci-dessus).

Vous trouverez les listes des équivalents clavier recommandés par Apple au chapitre “Equivalents clavier” de Inside Mac OS X: Aqua Human Interface Guidelines. Si vous souhaitez ajouter vos propres équivalents clavier pour des opérations non-listées, Apple recommande que vous ne le fassiez que pour des opérations qui seront utilisées fréquemment par l’utilisateur.

Peu d’applications Mac OS X utilisent les touches de fonction, et la majorité des utilisateurs Mac OS X n’associe pas à ces touches des comportements spécifiques (par opposition aux utilisateurs Windows qui associent génralement la touche F1 avec l’appel de l’aide en ligne de l’application). Pour ces raisons, vous ne devriez pas associer de fonctions à ces touches mais plutôt à des combinaisons de la touche Commande avec d’autres touches.

L’aide Apple

La philosophie Apple en matière d’aide est que les utilisateurs ne se tournent vers elle que lorsque tout le reste a échoué. Ils savent ce qu’ils veulent faire mais ne savent pas comment le faire et ils sont frustrés. Vous devriez concevoir votre système d’aide à partir des tâches, pour que les utilisateurs puissent trouver rapidement l’aide dont ils ont besoin. De même, en limitant vos pages d’aide à une  seule tâche élémentaire et en écrivant des titres de page explicites, vous devriez augmenter la probabilité que vos utilisateurs trouvent exactement ce qu’ils cherchent.

Comment les utilisateurs accèdent à l’aide

Le menu d’aide est une partie importante de l’interface utilisateur de Mac OS X. Quand vous écrivez votre documentation d’aide (sous la forme d’un livret d’aide), Mac OS X ajoute automatiquement le menu Aide et sous celui-ci un élément de menu intitulé “Aide <le-nom-de-votre-application>”. Quand l’utilisateur choisit cet élément de menu, Mac OS X ouvre votre documentaion d’aide.

Il y a deux façons d’invoquer votre fonction d’aide depuis l’application elle-même. Tout d’abord, vous pouvez concevoir votre application de telle sorte que, quand les utilisateurs pointent sur certains éléments d’interface et évoquent le menu contextuel, le premier élément de menu ouvre une page de votre livret d’aide. Ou aussi, vous pouvez ajouter des boutons d’aide aux fenêtres ou dialogues de votre application. Quand l’utilisateur clique sur un de ces boutons, le système affiche une des pages de votre livret d’aide.

Visualisateur d’aide

Le visualisateur d’aide est la partie de l’aide d’Apple qui permet d’afficher les livrets d’aide, qui contient la documentation d’aide en HTML (compatible avec le format HTML 3.2). Outre l’affichage des livrets d’aide, le visualisateur d’aide intègre un moteur de recherche qui aide l’utilisateur à trouver des pages spécifiques et renvoie une liste de pages possibles classées selon leur pertinence.

L’aide Apple vous permet d’offrir à vos clients une expérience riche et agréable quand ils ont besoin d’aide dans votre application. Pour voir le meilleur de l’aide d’Apple, jetez un oeil aux premières pages d’aide des applications fournies avec Mac OS X. Vous verrez qu’elles offrent une introduction sophistiquée et agréable à toutes les fonctions de l’application. En particulier, depuis le Finder, invoquez le menu d’aide Apple, allez voir le centre d’aide et regardez les pages d’aide d’AppleScript, d’AirPort, de iMovie et de iTunes. Chacune a une personnalité et une structure différente ; toutes contiennent des idées que vous voudrez probablement réutiliser dans vos propres pages de documentation d’aide.

Création de votre livret d’aide

Il y a cinq étapes à suivre pour créer le livret d’aide de votre documentation :

1. Définissez la structure de votre livret d’aide.
2. Ecrivez les pages en HTML.
3. Ajoutez des améliorations pour augmenter la facilité d’utilisation de votre livret d’aide.
4. Indexez votre livret d’aide en utilisant l’outil d’indexation d’aide Apple.
5. Enregistrez votre livret d’aide pour qu’il s’intègre au système d’aide Mac OS X et placez les fichiers au bon endroit.

Vous trouverez les détails sur comment faire tout cela dans Providing User Assistance with Apple Help.

Amélioration du livret d’aide

Il y a plusieurs façons d’améliorer votre livret d’aide pour le rendre plus utile. Le visulisateur d’aide offre ces possibilités non-HTML:

• lancer une autre application depuis un hyperlien dans votre texte d’aide
• afficher des images, des sons et des films dans QuickTime
• ajouter des actions “fais le pour moi” à vos pages d’aide en utilsant le langage de script AppleScript

Vous pouvez ajouter les éléments suivants pour rendre votre livret d’aide plus utile:

• Balises d’ancrage HTML : Elles permettent d’ouvrir l’Aide Apple à une page spécifique sous le contrôle d’un programme.
• Balises de description: Quand l’aide Apple affiche les résultats d’une recherche, ces balises sont une information complémentaire sur chaque élément trouvé.
• Mots-clés : Vous pouvez définir des listes de mots-clés synonymes. Le Visualisateur d’aide élargit sa recherche en ajoutant les synonymes aux mots spécifiés par l’utilisateur. Ceci augmente la pertinence des recherches de l’utilisateur, puisqu’il sera dirigé vers la bonne page d’aide quelle que soit la façon dont il aura exprimé sa requête.
• Balises meta des robots: Vous pouvez ajouter ces balises pour agir sur la façon dont l’outil d’indexation d’aide Apple va indexer votre livret d’aide. En faisant ainsi, vous augmenterez la pertinence de l’index lors d’une recherche.
• URL d’aide : Ces URL spéciales, visibles par les utilisateurs sous forme d’hyperliens, permettent à l’utilisateur d’ouvrir d’autres livrets d’aide, des pages HTML ou des fichiers texte. De plus, vous pouvez créer des URL d’aide qui ouvrent la page d’aide principale Apple ou qui lancent une recherche automatiquement à partir de paramètres que vous spécifiez.

Enfin, vous pouvez améliorer votre livret d’aide en gardant à jour certaines pages sur un serveur distant quelque part sur Internet. De cette manière, vous aurez toujours les informations principales au dernier cri tout en les intégrant à votre livret d’aide (à condition, bien sûr, que l’utilisateur ait accès à Internet). Voyez le chapitre “Préparation d’un index pour pages distantes” du livre Providing User Assistance with Apple Help pour plus de détails.

Sujets divers

Voici quelques points divers relatifs à l’interface utilisateur :

• Facilité d’utilisation, personnalisation et WYSIWYG (acronyme anglais pour : “Ce que vous voyez est ce que vous obtiendrez”) sont des éléments-clés de l’expérience des utilisateurs Mac OS X. Les utilisateurs Mac attendent des objets du bureau qu’ils réagissent de façon prévisible et constante. En particulier, ils s’attendent à pouvoir changer les noms ou les emplacements d’applications ou de dossiers sans que cela cause, directement ou indirectement, l’arrêt d’un service ou d’une fonction de leur ordinateur. Pour cette raison, votre application est supposée s’y retrouver sans souci si les utilisateurs font de tels changements.
• Dans certains cas, la structure de Mac OS X isole votre application des effets des changements effectués par l’utilisateur. Par exemple, changer le nom d’une icône d’application ou le dossier la contenant ne l’empêche pas de fonctionner. Dans d’autres cas, vous devrez penser la robustesse de votre application. Si possible, évitez de coder en dur les chemins absolus dans votre application. Les alternatives peuvent être des chemins relatifs, la recherche d’un fichier en plusieurs endroits ou demander à l’utilisateur de retrouver le fichier perdu (et de mémoriser le nouvel emplacement).
• Le bon endroit pour stocker des paramétrages propres à l’application et à l’utilisateur qui doivent être mémorisés est une liste de propriétés qui sera gérée par Mac OS X. En utilisant les routines décrites dans CFPreferences.h, vous pouvez définir et retrouver ces valeurs.
• Un bon moyen de stocker des pointeurs ou d’autres données relatives à une fenêtre donnée est d’utiliser les routines SetWindowProperty et GetWindowProperty pour lier un nombre “raisonnable” de valeurs à cette fenêtre. Vous trouverez ces routines dans le fichier MacWindows.h dans le framework HIToolbox (utilisez la commande UNIX locate pour trouver ce fichier).
• Les applications Mac OS X seront utilisées dans différents lieux de la planète, et votre application devrait être neutre vis-à-vis de la langue, c’est-à-dire, ne devrait pas s’occuper de la langue dans laquelle elle sera affichée. Les utilisateurs définissent, par ordre décroissant de préférence, les langues qu’ils veulent voir utiliser dans les menus et les dialogues et Mac OS X utilise le langage le plus approprié en fonction de ces préférences. Si vous créez votre application selon les règles générales de Mac OS X, celle-ci utilisera automatiquement la langue préférée de votre utilisateur sans que vous ayez à garder une trace des langues disponibles et des préférences de chaque utilisateur. Pour implémenter ceci, il vous faudra placer toutes les chaînes affichables dans un fichier appelé Localizable.strings, comme décrit dans le chapitre “Internationalisation” de Inside Mac OS X: System Overview.
• Mac OS X ne comprend pas de technologie pour inclure des objets de différentes applications dans un même document (comme les objets OLE de Microsoft). Si votre application Win32 utilise des objets OLE, vous devrez décider si oui ou non, vous souhaitez offrir de telles possibilités dasn la version Mac OS X de votre application, et, dans l’affirmative, comment les implémenter. D’un point de vue interface utilisateur, l’absence de tels objets dans Mac OS X est une simplification de l’interface et du code sous-jacent.
• Les règles d’interface Apple n’encourage pas à l’utilisation de boîtes de groupage (des rectangles regroupant des contrôles de même nature). Au lieu de cela, elles préconisent plutôt l’emploi d’espaces ou de lignes de séparation pour obtenir le même effet tout en limitant l’impact visuel.
• Mac OS X fournit deux moyens standards d’annuler une opération en cours à partir du clavier : Appuyer sur la touche Escape (ndt. Echappement sur certains claviers peut-être) et la combinaison Commande-. (point). Ces deux méthodes devraient faire appel à la même fonctionnalité.

Compléments d’information

Votre principale référence en matière d’interface utilisateur Mac OS X est Inside Mac OS X: Aqua Human Interface Guidelines. En complément aux liens de ce livre, vous trouverez peut-être certains des liens ci-dessous utiles.

Inside Mac OS X: Aqua Human Interface Guidelines	(HTML) http://developer.apple.com/techpubs/macosx/Essentials/ AquaHIGuidelines/index.html, (PDF) http://developer.apple.com/techpubs/macosx/Essentials/ AquaHIGuidelines/AquaHIGuidelines.pdf
Converter: Creating a User Interface with Interface Builder	http://developer.apple.com/techpubs/macosx/DeveloperTools/ InterfaceBuilder/Converter.pdf
Les différences clés entre Windows et Mac OS X rapportées par les utilisateurs	http://developer.apple.com/ue/switch/windows.html
La page d’expérience des utilisateurs Apple	http://developer.apple.com/ue/
la page Aqua d’Apple	http://developer.apple.com/ue/aqua/
Les pages des expériences utilisateurs Apple pour : * le Dock * les menus * les dialogues et feuilles * les fenêtres et tiroirs * le comportement du glisser-déposer * l’aide Apple	http://developer.apple.com/ue/aqua/dock.html http://developer.apple.com/ue/aqua/icons.html http://developer.apple.com/ue/aqua/menus.html http://developer.apple.com/ue/aqua/windows.html http://developer.apple.com/ue/aqua/draganddrop.html http://developer.apple.com/ue/help/
des liens vers la documentation de l’aide Apple, y compris Providing User Assistance with Apple Help	http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/ AppleHelp/applehelp.html
Introducing HIView	http://developer.apple.com/techpubs/macosx/Carbon/ HumanInterfaceToolbox/HIToolbox/HIViewDoc/HIView.pdf
la documentation de HIView	http://developer.apple.com/techpubs/macosx/Carbon/ HumanInterfaceToolbox/HIToolbox/HIViewReference/
Inside Mac OS X: Handling Carbon Events	(HTML) http://developer.apple.com/techpubs/macosx/Carbon/ oss/CarbonEventManager/Carbon_Event_Manager/index.html, (PDF) http://developer.apple.com/techpubs/macosx/Carbon/ oss/CarbonEventManager/Carbon_Event_Manager/CarbonEvents.pdf
Handling Carbon Windows and Controls	(HTML) http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/WindowManager/HandlingWindowsControls/index.html, (PDF) http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/WindowManager/HandlingWindowsControls/ windowscontrols.pdf
Les Services de Navigation (dialogues Ouvrir  et Sauver)	http://developer.apple.com/techpubs/macosx/Carbon/Files/NavigationServices/ navigationservices.html
la documentation du Gestionnaire de listes	http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/ ListManager/List_Manager/index.html
Une note technique au sujet du contrôle Navigateur de Données	http://developer.apple.com/technotes/tn/tn2009.html
les listes de propriétés et les préférences	situé sur un disque Mac OS X dans /System/Library/Frameworks/ CoreFoundation.framework/Headers/CFPreferences.h
Inside Mac OS X: Setting up Your Application to Use the Services Menu	http://developer.apple.com/techpubs/macosx/Carbon/HumanInterfaceToolbox/ MenuManager/appservices/appservices.pdf
la page des Outils de Développement	http://developer.apple.com/tools/index.html

Textes originaux en anglais sur ADC : Win32 Porting

mactov Portage d'applications vers Mac OS X Mac OS X, Portage, Windows