Nous sommes toujours sur notre problème de plantage de Windows. Apparemment le système n'est pas récupérable mais tous nos fichiers de données sont là. Nous avons réussi a démarrer une version d'Ubuntu sur CD et sommes en train de copier toutes les données sur un disque amovible. Quand ce sera fini, nous essaierons de réinstaller Windows....
Sinon, il y a très peu de retours sur les dernières versions publiées et c'est plutôt positif.
Notre intention est de démarrer très vite le chantier de notre nouveau produit : l'intégration de la guitare virtuelle dans Harmony/Melody.
Bon week end ! |
|
|
| by Didier Guillion |  |
|
| |
|
"Pluralitas non est ponenda sine necessitante"
Les multiples ne doivent pas être utilisés sans nécessité.
(Guillaume d'Ockham)
Il y a tous juste 20 ans, en 1991, nous avons commencé le développement de notre librairie Acam (As Clever As Mac). Lassé de devoir recoder une bonne partie de nos programmes sur les différentes machines existantes comme le Mac, le PC, l'Atari ST, nous avons décidé de mettre au point une couche logicielle commune à tous les systèmes. Comme le meilleur système d'interface graphique à l'époque était Mac OS, nous avons donc réécrit celui ci en C.
Depuis, tous nos logiciels utilisent cette librairie, bien que depuis près de 15 ans elle ne tourne plus que sous Windows.
Entretemps, Mac OS est devenu Mac OS X mais la compatibilité a été assuré par la couche logicielle Carbon qui permet de faire tourner les applications utilisant les anciennes API.
Nous craignons qu'un jour, à la faveur d'une mise à jour majeure du système, Apple n'abandonne Carbon. Il est absolument impensable de réécrire tous nos logiciels en Objective-C sous Cocoa en perdant dans le même mouvement ce grand bonus d'avoir des sources compatibles entre Mac OS et Windows ce qui réduit drastiquement nos temps de développement.
Nous avons décidé de passer quelques jours à étudier la possibilité de repasser Acam sous Mac OS. C'est un gros travail car au fil des années, Acam est devenu très lié à Windows.
Mais ce faisant nous allons essayer de le rendre totalement indépendant du système, ce qui, à terme, permettrait d'envisager un portage vers d'autres systèmes comme l'iOS qui équipe les iPod, iPad et autres iPhone, ou même une version Linux qui permettrait d'avoir enfin nos logiciels sur cette plateforme, en mode natif, sans passer par l'émulateur WINE.
A suivre ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous sommes en train d'écrire une couche mannequin qui devrait nous permettre à terme de compiler la librairie Acam sous Mac OS et de la lier avec une de nos applications. Bien sur ce n'est qu'une étape car les différentes entrées de la couche mannequin sont vides, il va falloir les remplir.
Les sources C se compilent sans aucun problème sous XCode, seule une instruction assembleur est mal digérée par XCode. Il va falloir trouver une solution.
Donc pour résumer, quand une de nos applications voudra ouvrir une fenêtre Mac OS X, elle invoquera la fonction Mac OS 9, qui sera émulé par la couche Mac OS 9 d'Acam qui appellera la fonction Windows correspondante qui elle même sera émulée par notre couche mannequin et transformée en appel Mac OS X. Les conversions étant très rapides, nous sommes persuadés que cela sera imperceptible en terme de réactivité pour la plupart des fonctions, les autres seront optimisées pour offrir un accès direct.
La seule question en suspend est de savoir si nous allons pouvoir gérer l'interface graphique Cocoa en C sur Mac OS X puisque le langage officiel reste OBJ-C.... |
|
|
| by Didier Guillion | |
| |
|
Nous avons réussi à lier notre librairie Acam mannequin à un très court projet fonctionnant sous Acam Windows.
Les premières entrées vides ont été implémentées. En premier, les opérations d'entrée/sortie disque. Ainsi, les fichiers ressources sont apparemment correctement lus et les objets extraits.
Les premières fonctions de base ont été écrites : ouverture d'une fenêtre, changement de son titre, redimensionnement.
Il reste maintenant à tracer sur cette fenêtre. D'après la documentation Apple, QuickDraw est indépendant de Carbon et intégré à QuickTime, on devrait pouvoir utiliser soit QuickDraw soit, la nouvelle technologie Quartz 2D.
Nous pencherions plutôt pour la seconde solution (même si le travail est plus important) car elle est annoncée comme plus rapide et offre des possibilités intéressantes comme les courbes de Bézier.
Donc deux objectifs : d'abord définir le remplaçant du GrafPort (le Device Context sous Windows), ensuite arriver à intercepter les évènements qui arrivent sur la fenêtre : mise à jour, click souris, etc et les convertir.
|
|
|
| by Didier Guillion | |
|
| |
|
Nous achevons notre deuxième semaine de développement sur Acam.
En surclassant l'objet Cocoa NSWindow nous avons réussi à intercepter plusieurs évènements sur les fenêtres. Mais pour l'instant, si le clavier, le bouton gauche et la mise à jour graphique de l'aire de la fenêtre ne semblent pas poser de problème, nous ne recevons pas d'évènement bouton droit appuyé mais uniquement, bouton droit relâché, étrange...
La couche bas niveau de manipulation de mémoire (écrite en assembleur) s'est avérée assez difficile à rendre compatible entre Visual C et XCode : le compilateur GCC de XCode fait vraiment des choses pas très nettes, comme par exemple, utiliser des registres processeur sans les préserver. Nous allons donc réécrire ce module en C pour aller plus loin dans nos tests. De toute manière cela pourra servir d'avoir une version d'Acam 100% en C.
Bon week end ! |
|
|
| by Didier Guillion | |
| |
|
Nous avançons pas à pas sur le développement d'Acam sur Mac.
Un point important a été franchi quand nous avons enfin réussi à détourner les évènements système bas niveau vers notre propre système de traitement.
Pour résumer, Cocoa définit des objets qui reçoivent des évènements. Chaque objet traite l'évènement selon ses propres méthodes, qui peuvent être surclassées. Nous, nous fonctionnons "à l'ancienne", c'est l'objet qui envoie une requête à l'interface pour savoir si un évènement est disponible.
La conversion de la couche graphique avance également, nous commençons à afficher des éléments simple en utilisant CoreGraphic.
Comme nous sommes passés d'offscreens QuickTime à des offscreens CoreGraphic (les entrées bas niveau de Mac OS X) il est maintenant possible d'utiliser toutes les fonctions CoreGraphic et en particulier l'affichage des textes.
Nous n'arrivons toujours pas à demander à CoreGraphic de nous dire la taille en pixels X et Y d'un texte, mais apparemment nous ne sommes pas les seuls à rencontrer ce problème...
D'où l'aspect décalé de l'état actuel de notre test :
Mais cela nous satisfait, une vilaine fenêtre Window 95 qui tourne sous Mac OS X...
Il faut également savoir que les origines de tracé ont changé. Carbon et QuickTime considéraient que le point (0,0) était en haut à gauche de l'espace. CoreGraphic le place en bas à gauche. Pas mal de gymnastique arithmétique donc.
Mais nous évoluons dans le bon sens : une uniformisation des fonctions vers une couche système dépendant. Dès que cela sera à peut prêt au point, nous tenterons une compilation sous Linux. |
|
|
| by Didier Guillion | |
| |
|
Pas mal d'avancées satisfaisantes pour finir la semaine.
D'un coté, un gros travail de séparation des fonctions génériques de celles spécifiques à la machine a été fait. Il nous restera donc a remplir les sources mannequins pour obtenir une version d'Acam sur n'importe quel OS.
Pour entrer dans le détail, depuis quelques dizaines d'années, les systèmes d'interface graphique n'ont guère divergés.
Il y un menu, des fenêtres. Chaque fenêtre propose une aire système (titre, marges...) et une aire utilisateur sur laquelle on peut dessiner ce que l'on veut. Alors, pour créer une fenêtre cela peut être NewWindow, CreateWindow, OpenWindow sur les différents OS, le résultat reste le même. Donc, notre entrée AcamCreateWindow devient l'entrée générique pour toutes nos applications.
Ensuite, sur Mac OS X, nous avons réussi à gérer les menus de manière conforme à l'aspect du système :
Au passage, l'appli est un petit éditeur de texte que nous avons écrit il y a une vingtaine d'année pour tester les premières versions d'Acam.
La prochaine étape est l'uniformisation de la gestion des polices de caractères.
Bon week-end ! |
|
|
| by Didier Guillion | |
|
| |
|
Nous avançons lentement mais surement. Nous commençons à comprendre de mieux en mieux comment fonctionne Mac OS X.
En effet, nous devons déconnecter tous les automatismes de Cocoa pour gérer les choses à notre façon : la gestion des allocations mémoires, les objets graphiques, les évènements clavier et souris, etc.
D'abord, l'accès aux fenêtres systèmes de sélection de fichier à charger et à sauver, de paramétrage des imprimantes a été implémenté :
Depuis Myredit, il est donc maintenant possible de charger un fichier de le modifier puis de le sauvegarder sous un autre nom.
A noter que le multi-fenêtrage est opérationnel ainsi que le déplacement et le changement de taille.
Un grand point positif : nous craignions vraiment rencontrer des problèmes en mixant de l'Objective-C et du C, et bien non, avec un peu de discipline les appels de l'un à l'autre se font sans mécanismes compliqués.
Nous avons perdu pas mal de temps avec une réaction étrange de GCC (le compilateur C de XCode). En C, les paramètres des fonctions peuvent être flous. GCC le gère d'une manière un peu particulière puisqu'il refuse les données de moins de 4 octets, affiche juste un avertissement et génère de l'assembleur avec une instruction destinée à faire planter le programme : ud2a.
Nous n'avions jamais vu cela.
La saisie de la position globale du curseur de la souris a également été assez coton. Après plusieurs essais infructueux et plantogènes nous sommes passés par la possibilité qu'offre Mac OS X de détourner les évènements de périphériques à un très bas niveau via CGEventTapCreate. Et cela fonctionne.
Prochaine étape, l'impression, il va y avoir du boulot ! |
|
|
| by Didier Guillion | |
| |
|
Nous avons donc attaqué la partie impression d'Acam. Afin de bien comprendre la charge de travail un petit rappel du mode de fonctionnement est nécessaire. Dans Acam affichage à l'écran et impression ont très vite été séparés.
Pour l'écran, à chaque fenêtre est associé un "offscreen" (une image pixélisé en couleur) sur lequel Acam dessine lui-même quasiment tout. Seul les textes sont affichés par l'OS dans l'offscreen. La gestion des différents types de polices, de modes de transfert, de rotation, serait un vrai casse tête. De fait une normalisation commence à apparaître : l'ATSUI. C'est ce que nous utilisons sur Mac OS X.
Utiliser ce type de fonctionnement pour l'impression est possible, c'est le mode "Imprimer selon une image haute résolution" d'Harmony Assistant. Cependant cela entraîne quelques problèmes.
D'une part, pour avoir une précision suffisante, il faut utiliser un offscreen immense. N'oublions pas que la résolution standard d'un écran est de 72 pixels par pouce (ppp) une imprimante va facilement jusqu'à 2400 ppp.
Le temps de transfert de l'image vers le périphérique va donc être non négligeable.
Ensuite certains types d'imprimantes gèrent eux même les tracés de manière intelligente (par exemple les imprimantes PostScript) et vont se charger de lisser les différents graphismes au mieux de leur capacité.
Donc lorsque nous voulons imprimer une page sous Acam :
Les différents ordres graphiques sont collectés dans une structure très proche du PicHandle de Mac OS 9.
Ces différents ordres sont reinterprétés et traduits dans des commandes dépendantes du système et envoyé au pilote d'impression.
Il est donc nécessaire de traduire toutes les commandes graphiques générique d'Acam: MoveTo, LineTo, Clip, Fill, etc, en commandes spécifiques au système.
Bon week end ! |
|
|
| by Didier Guillion | |
|
| |
|
|
