Myriad Blog 1.3.0 Sunday, Dec 21st, 2014 at 10:57am 

Dev News Saturday, Apr 30th, 2011 at 06:32am
Acam III étape 13

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
 1 comment.

Dev News Thursday, Apr 28th, 2011 at 04:57pm
Acam III étape 12

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

Dev News Friday, Apr 22nd, 2011 at 04:59pm
Acam III étape 9

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
 6 comments.

Dev News Wednesday, Apr 20th, 2011 at 05:15pm
Acam III étape 7

 
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

Dev News Friday, Apr 15th, 2011 at 04:58pm
Acam III étape 4

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

Dev News Wednesday, Apr 13th, 2011 at 05:01pm
Acam III étape 3

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
 1 comment.

Dev News Thursday, Apr 7th, 2011 at 05:00pm
Acam III étape 2

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

Dev News Tuesday, Apr 5th, 2011 at 05:00pm
Acam III étape 1

"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
 5 comments.

Dev News Friday, Apr 1st, 2011 at 04:58pm
Harmony 9.6 et autre étape 190

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
 3 comments.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Aug 2014
Sep 2014
Oct 2014
Nov 2014
Dec 2014
Dec 21st, 2014 at 07:53am 
Comment from Antoine Bautista
Et le Printemps....?
Dec 19th, 2014 at 05:03pm 
Article from Olivier Guillion
Acam Winter étape 24
Dec 19th, 2014 at 05:03pm 
Article from Olivier Guillion
Acam Winter étape 24
Dec 18th, 2014 at 04:49pm 
Article from Didier Guillion
ACAM sur Mac étape 7
Dec 17th, 2014 at 05:04pm 
Article from Olivier Guillion
Acam Winter étape 23
Dec 16th, 2014 at 04:55pm 
Article from Didier Guillion
ACAM sur Mac étape 6
Dec 15th, 2014 at 05:08pm 
Article from Olivier Guillion
Acam Winter étape 22
Dec 13th, 2014 at 09:33am 
Comment from Antoine Bautista
0 + Album...
Dec 12th, 2014 at 05:00pm 
Article from Didier Guillion
ACAM sur Mac étape 5
Dec 12th, 2014 at 05:00pm 
Article from Didier Guillion
ACAM sur Mac étape 5

Top of page
Last update:  (c) Myriad