Un utilisateur nous a signalé un oubli dans notre implémentation de l'interprétation des fichiers PDF : il y a un niveau de protection du chargement via un mot de passe, ce qui nous gérons. Mais, le créateur du document peut permettre la visualisation en interdisant le copier/coller, ce que nous avons passé à la trappe.
Maintenant, il sera possible de gérer ce type de document et un mot de passe sera demandé lorsque un export de document protégé de cette façon est effectué. |
|
|
| by Didier Guillion |  |
| |
|
Le "coeur" d'Acam III est maintenant en place, nous nous attelons maintenant à organiser la couche système dépendante et à la rendre propre. Il faut dire qu'après 20 ans de développement sur ce projet et les passages successifs de nombreuses version de Windows (la première était la v 3.1) qui ont demandé des ajouts spécifiques, notre code source commençait à être truffé de fossiles inutiles...
Un aspect intéressant, que nous ne perdons pas de vue, c'est la possibilité de faire tracer les B-splines par le système lui même, ce qui améliorerait l'aspect graphique, surtout lors de l'impression des coulés entre les notes. |
|
|
| by Didier Guillion | |
| |
|
La hiérarchisation en couches d'Acam est quasiment terminée. Il reste à étudier deux points que nous réservons pour plus tard : tout d'abord la gestion des polices de caractères que nous voudrions rendre plus générique et la collecte des commandes graphiques pour l'impression. Mais cela peut attendre.
Les sources mannequins ont été créées pour Ubuntu GTK+ à partir des sources Mac OS X. Pour rappel les sources mannequins sont des fichiers sources avec toutes les fonctions définies mais vides. Cela doit se compiler et se lier (sans donner aucun résultat bien sur). Une fois cette étape passée, on est sur que toutes les fonctions sont là, que les passages de paramètres sont corrects, que les headers sont bien compris. Il ne "reste" plus alors qu'à remplir le corps des fonctions avec les appels spécifiques au système.
Donc, demain, premiers essais de compilation sous Ubuntu !
|
|
|
| by Didier Guillion | |
|
| |
|
Un grand pas en avant pour finir la semaine.
Nous avons créé un disque virtuel d'Ubuntu 11 via Virtual Box que nous utilisons sur Windows et Mac OS. Les dossiers des fichiers sources sont partagés et donc utilisés simultanément par nos différents compilateurs.
Acam a été compilé avec succès sous Ubuntu avec Code::Blocks. Puis, nous avons compilé notre application de test Myredit et lié celle-ci sans erreur avec Acam.
Nous avons donc aujourd'hui notre première application Macintosh se lançant sous Linux. Bien entendu, elle ne fait strictement rien puisqu'il reste à écrire la partie dépendante du système. Ce que nous avons entamé.
Notre première impression est très favorable. Il semblerait que Linux ait enfin acquis une maturité et une convivialité longtemps attendu.
Bien entendu, nous pouvons encore tomber sur un os. Extrapoler la réussite de compilation d'une application de quelques milliers de lignes à une application de près d'un million comme Harmony Assistant serait un peu présomptueux...
Bon Week End ! |
|
|
| by Didier Guillion | |
| |
|
Le remplissage des sources mannequins sous Linux à commencé. En premier lieu, nous avons travaillé sur la création des fenêtres, la création des offscreens associés à celles ci et la gestion des évènements élémentaires : click souris, update (rafraichissement).
Nous obtenons donc ceci :
Une fenêtre a été à peu près correctement dessinée, elle réagit aux évènements.
Nous attaquons maintenant la gestion de l'affichage des textes. Nous avons d'abord choisi de passer par la couche Cairo de GTK, cela fonctionne mais serait d'après les docs, limité. Nous envisageons donc d'essayer d'utiliser Pango à la place.
Les primitives de balayage de fichiers dans les dossiers et sous dossier est opérationnelle et identique à celle de Mac OSX (qui est aussi basé sur Linux).
Nous avons planché sur la détermination des caractéristiques des polices (ascent, descent, leading), mais que ce soit via Cairo ou Pango, nous avons fait chou blanc. Nous persévèrerons demain... |
|
|
| by Didier Guillion | |
| |
|
L'affichage des textes sur Ubuntu est passé de Cairo à Pango, mais non sans mal. Il est apparemment difficile de trouver des documentations complètes, quand aux exemples d'utilisation n'en parlons pas...
La définition de ces API semble avoir été plutôt anarchique. Par exemple au niveau des fenêtres, on a la fonction
gtk_window_get_position qui permet de connaitre la position d'une fenêtre sur l'écran. On pouvait donc supposer que gtk_window_set_position allait la déplacer. Et bien non. Pas du tout, cela existe mais fait autre chose. C'est gtk_window_move qu'il faut utiliser...
La gestion des polices via Pango fonctionne plutôt bien, avec extraction des caractéristiques et affichage.
Les évènements de clics souris et de clavier sont opérationnels à 80%, pour preuve, une capture de Myredit sous Ubuntu:
Prochain objectif, afficher et gérer la barre de menus... |
|
|
| by Didier Guillion | |
| |
|
Nous progressons dans la compréhension des mécanismes d'impression sous Ubuntu. Les versions récentes de GTK ont introduit une simplification du processus et apparemment, c'était attendu par la communauté car les anciens modes de fonctionnement était assez complexe.
Nous arrivons donc à invoquer les boites de dialogue standard de mise en page et de configuration de l'impression et nos routines de tracés sont correctement appelées.
Il nous reste à écrire la conversion de notre mode de collecte des instructions de tracé (une Picture Macintosh) en commandes Cairo/Pango.
|
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui nous avons travaillé sur la couche logicielle permettant de sélectionner une police de caractère.
Il a fallu tout d'abord énumérer les noms des polices pour pouvoir les présenter dans un menu par exemple.
Que ce soit sur la version Mac OS ou Linux cela s'est plutôt bien passé, même plus facilement du coté Linux.
Content de notre succès nous avons regardé s'il était possible d'invoquer la boîte de sélection de police standard du système.
Et là aussi, peu de problème.
Il nous reste une "to-do lits" plutôt conséquente, mais nous allons passer à l'analyse d'un point important, serons nous capable de compiler une application comme Melody Assistant sous Ubuntu ? |
|
|
| by Didier Guillion | |
| |
|
Ca avance, ça avance, mais c'est encore un peu confus. Melody utilise pas mal de librairies, qui elles mêmes invoquent d'autres librairies, etc. La compilation de l'ensemble des modules se fait maintenant sans erreur, mais il nous reste encore 11 erreurs de links, c'est à dire des appels non résolus entre programme et librairies. Nous sommes dessus. Si nous passons ce cap, demain devrait être un grand jour, et nous allons passer du tapoti tapota sur nos vieux claviers à quelque chose de tangible à nous mettre sous les yeux.
|
|
|
| by Didier Guillion | |
|
| |
|
La progression se fait par à-coups. Nous buttons plusieurs heures sur un problème et la solution trouvée, des pans entiers de l'interface apparaissent.
Il n'est apparemment pas possible de faire travailler Pango/Cairo (le gestionnaire de texte) à partie de polices non installées dans le système (Melody gère normalement les polices de manière embarquée dans l'application). Nous avons donc installé la SToccata à la main, ce que devra faire notre programme d'installation donc. Une fois cela en place nous avons constaté de gros décalages des caractères musicaux. En premier lieu nous avons suspecté un problème intrinsèque à notre police et il s'est avéré en fait que nous avions fait une mauvaise interprétation d'une des entrée Pango.
Les documents musicaux se chargent et s'affichent correctement :
C'est un grand pas en avant !
La gestion des fichiers temporaire a été implémentée ce qui a permis d'accéder à la recherche dans l'interface (qui utilise beaucoup les fichiers temporaires) :
Prochaine étape sur notre cahier de route, corriger les problèmes de focus sur les fenêtres : parfois celle qui est devant se croit derrière.
Puis, nous allons attaquer un module très important, la restitution numérique de la musique !
Nous n'avons aucune idée de la manière dont cela fonctionne sous Ubuntu et allons donc défricher (déchiffrer ?) des territoires inconnus...
|
|
|
| by Didier Guillion | |
|
| |
|
La première étape du jeu de la musique sous Ubuntu a été franchie : il s'agissait de faire fonctionner notre "moteur" qui converti les notes en données numériques.
Cela marche et nous pouvons donc générer des fichiers WAV, AIFF ou OGG à partir de fichier musicaux Harmony. Dans la foulée Virtual Singer a été testé et est opérationnel.
Les fichiers MIDI sont correctement générés également mais les fichiers MP3 semblent vides, à étudier.
Maintenant que les données numériques sont correctes il faut les envoyer sur l'interface de mixage de son d'Ubuntu , nous allons très certainement passer par la couche ALSA. |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons avancé dans l'impression des documents. Pour rappel, les ordres graphiques de chaque page sont collectés dans une Picture Mac. Il faut donc traduire chacun de ses ordres en équivalent Cairo/Pango et les envoyer au pilote d'impression de GTK.
Par exemple, l'option d'impression des diagrammes d'accords fonctionne plutôt bien.
|
|
|
| by Didier Guillion | |
| |
|
|
|
May 26th, 2023 at 06:41pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 et autre étape 82
May 25th, 2023 at 08:02pm
Comment from antoine bautista
à Sylvain
May 25th, 2023 at 06:45pm
Comment from Sylvain
à Antoine
May 25th, 2023 at 06:45pm
Comment from Sylvain
à Antoine
May 25th, 2023 at 04:58pm
Article from Didier Guillion
Digital Piano Daily Practice étape 61
May 25th, 2023 at 02:06pm
Comment from antoine bautista
HA via DPDP
May 25th, 2023 at 02:06pm
Comment from antoine bautista
HA via DPDP
May 24th, 2023 at 05:23pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 et autre étape 81
May 23rd, 2023 at 05:09pm
Article from Didier Guillion
Harmony Assistant 9.9.7 et autre étape 80
May 22nd, 2023 at 05:03pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 et autre étape 79
|
|
|
|
