HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Tuesday, Mar 19th, 2024 at 04:54am 

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
Mood
To be seen
Myriad Life
Technical
Memories
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
Jan 2015
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015
Jul 2015
Aug 2015
Sep 2015
Oct 2015
Nov 2015
Dec 2015
Jan 2016
Feb 2016
Mar 2016
Apr 2016
May 2016
Jun 2016
Jul 2016
Aug 2016
Sep 2016
Oct 2016
Nov 2016
Dec 2016
Jan 2017
Feb 2017
Mar 2017
Apr 2017
May 2017
Jun 2017
Jul 2017
Aug 2017
Sep 2017
Oct 2017
Nov 2017
Dec 2017
Jan 2018
Feb 2018
Mar 2018
Apr 2018
May 2018
Jun 2018
Jul 2018
Aug 2018
Sep 2018
Oct 2018
Nov 2018
Dec 2018
Jan 2019
Feb 2019
Mar 2019
Apr 2019
May 2019
Jun 2019
Jul 2019
Aug 2019
Sep 2019
Oct 2019
Nov 2019
Dec 2019
Jan 2020
Feb 2020
Mar 2020
Apr 2020
May 2020
Jun 2020
Jul 2020
Aug 2020
Sep 2020
Oct 2020
Nov 2020
Dec 2020
Jan 2021
Feb 2021
Mar 2021
Apr 2021
May 2021
Jun 2021
Jul 2021
Aug 2021
Sep 2021
Oct 2021
Nov 2021
Dec 2021
Jan 2022
Feb 2022
Mar 2022
Apr 2022
May 2022
Jun 2022
Jul 2022
Aug 2022
Sep 2022
Oct 2022
Nov 2022
Dec 2022
Jan 2023
Feb 2023
Mar 2023
Apr 2023
May 2023
Jun 2023
Jul 2023
Aug 2023
Sep 2023
Oct 2023
Nov 2023
Dec 2023
Jan 2024
Feb 2024
Mar 2024
Mar 18th, 2024 at 08:14pm 
Comment from Sylvain
Mar 18th, 2024 at 08:13pm 
Comment from Sylvain
@André
Mar 18th, 2024 at 07:28pm 
Comment from Antoine Bautista
Build 82....
Mar 18th, 2024 at 05:02pm 
Article from Didier Guillion
Harmony Assistant 9.9.8  étape 198
Mar 18th, 2024 at 05:02pm 
Article from Didier Guillion
Harmony Assistant 9.9.8  étape 198
Mar 17th, 2024 at 11:40am 
Comment from Antoine Bautista
Frite....
Mar 17th, 2024 at 11:40am 
Comment from Antoine Bautista
Frite....
Mar 16th, 2024 at 09:16am 
Comment from André Baeck
Mar 16th, 2024 at 09:16am 
Comment from André Baeck
Mar 16th, 2024 at 09:13am 
Comment from André Baeck

Top of page
Legal information Cookies Last update:  (c) Myriad