Nous avons poursuivi la mise au point de l'installation de Melody Assistant sous Linux, avec l'association des types de documents (myr, mus,..) à l'application, l'icône spécifique au document, etc.
Cela s'est bien passé sur certains points, alors que d'autres ne fonctionnent pas. Cette partie du système semble plutôt bancale, avec plusieurs méthodes pour arriver au même résultat, chacune "coiffant" l'autre dans un ordre indéterminé.
Dans le programme lui-même, certaines choses qui fonctionnaient sur nos versions de développement se sont mises à réagir différemment sur la version beta que nous préparions. Cela va donc être assez difficile à corriger. De plus, nous nous sommes dits qu'il serait judicieux de détourner les crashes de l'application vers une de nos fonctions, afin de nous permettre une recherche et une résolution plus faciles des problèmes rencontrés.
C'est pourquoi nous allons vraisemblablement attendre encore quelques jours avant de proposer une version beta (ou alpha), afin d'être prêts à gérer les retours dans de bonnes conditions. Déjà que nous ne sommes pas spécialistes de Linux, si en plus nous n'avions pas toutes les informations possibles sur un dysfonctionnement, les corrections s'avéreraient vite compliqiuées. |
|
|
| by Olivier Guillion |  |
| |
|
Les dernières imperfections graphiques flagrantes ont été corrigées, notamment lors du redimensionnement de fenêtres. Des irrégularités dans l'appel aux fonctions d'impression de GTK ont également été corrigées.
Nous avons ensuite mis en place la gestion des numéros de série pour Linux de Melody Assistant et Virtual Singer, ainsi que les diverses autres protections du logiciel.
Outre Acam et Linux, nous avons par ailleurs été pas mal occupés par un problème sur notre serveur de mails, qui a duré près d'une journée entre dimanche soir et lundi. Certains messages de spam, contenant une très grosse liste de de destinataires (plusieurs dizaines de milliers) occupaient notre filtre anti-spam suffisamment longtemps pour empêcher une relève correcte de nos e-mails. Nous avons donc "patché" le programme de filtrage, écrit en Perl, pour ignorer les listes trop longues. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons travaillé sur plusieurs points :
- D'abord, la gestion du clavier, avec la prise en compte des touches mortes telles que l'accent circonflexe qui ne montre rien jusqu'à ce qu'on tape une voyelle. En théorie, le programme gère aussi les IME, méthodes de saisie au clavier destinées aux langues à la graphie complexe (Chinois, Japonais...), mais nous n'avons pas réussi à configurer le système Ubuntu pour le tester. Il ne subsiste que quelques problèmes dans la gestion des raccourcis clavier de Melody.
- Ensuite, nous avons complété les trous dans les fonctions d'affichage des textes, avec la prise en compte des styles souligné, relief, ombré, condensé et étendu :
- Nous avons à nouveau cherché vainement le moyen d'utiliser une police de caractères sans l'installer préalablement dans le système. Il est extrêmement étonnant que cette fonctionnalité n'existe pas, car cela empêcherait d'envisager des applications portables (utilisables sans installation depuis une clé USB) qui embarqueraient leurs propres polices. Mais on a pourtant bien cherché...
L'un dans l'autre, il commence tout de même à y avoir de moins en moins de problèmes visibles, la version beta approche à grands pas.
Sur ce, bon week-end à tous !
|
|
|
| by Olivier Guillion | |
| |
|
Quelques fonctionnalités ont été mises en place ou améliorées:
- la couleur de certaines icônes (par exemple, l'icône du chanteur dans la palette VS) était erronée. Cela a été corrigé.
- Les textes n'étaient pas affichés exactement au bon endroit. Cela a été amélioré.
- Les textes en rotation n'étaient pas bien gérés.
- Enfin, nous avons mis en place un système permettant à l'application d'être mono-instance. Cela signifie que lorsque l'application est lancée, et que vous double-cliquez à nouveau dessus, elle n'est pas lancée une seconde fois. Ou, si vous double-cliquez sur un fichier musical, il s'ouvre dans l'application déjà lancée, sans démarrer une deuxième copie du programme.
Ce type de comportement d'application n'était pas prévu dans les versions précédentes de GTK. Des librairies avaient été écrites pour gérer cela, puis elles ont été remplacées par des appels dédiés dans le système. Il nous a été impossible de les faire fonctionner l'un ou l'autre correctement. Nous avons donc dû nous résoudre à mettre en place notre propre système, qui passe par des communications inter-processus bas niveau de Linux.
|
|
|
| by Olivier Guillion | |
| |
|
Un peu lassés de buter pendant des jours sur quelques points critiques (synchros MIDI, saisies complexes au clavier, etc), nous nous sommes un peu détendus en s'attaquant à d'autres fonctions pas encore écrite ou pas complètement fonctionnelles.
Ainsi, nous avons finalisé la gestion des pointeurs souris, la vérification des périphériques de sortie utilisés par une partition, avons géré le presse-papier, qui permet de coller dans Melody des textes copiés depuis une autre application Linux (et vice-versa), et avons arrangé l'export MP3.
Au sujet de cet export, justement, en tant que programmeurs assez expérimentés, nous sommes restés bouche bée devant le comportement de certaines fonctions C sur Linux.
Le C, qui est destiné à être portable, utilise en interne le point décimal (.) pour séparer la partie entière de la partie à virgule des nombres. Ainsi, 4 et demi s'écrit 4.5
Plusieurs des fichiers de données de Melody (tables MP3, voix Virtual Singer, etc) sont en fait des fichiers au format texte contenant de telles valeurs.
Lors de la lecture de ces fichiers, le programme tronquait des valeurs, puis plantait lamentablement. Ce n'est qu'après quelques heures de recherche que nous nous sommes rendu compte que le programme attendait comme séparateur une virgule et non un point, puisque notre système est en français. Il a fallu explicitement fixer le séparateur à "." pour que cela fonctionne ! Du jamais vu, sur aucun des systèmes que nous ayons pu rencontrer ces 20 dernières années.
Cela a sans doute des conséquences sur le fonctionnement de pas mal de programmes. Si un programmeur américain écrit, dans un programme GTK, quelque chose d'aussi basique que :
Code:| if(atof("4.5")>4.0) printf("All right"); |
|
son programme fonctionnera chez lui mais pas en France... Si nous avions été anglophones, nous ne nous en serions probablement aperçus que lors du signalement de problèmes de quelques clients étrangers. Rassurez-moi, il y en a d'autres, des monstruosités comme celles-là?
|
|
|
| by Olivier Guillion | |
|
| |
|
Côté synchronisation des envois de données MIDI, les choses se présentent mal. Contrairement à MacOS ou à Windows, Linux ne semble pas prévu en standard pour effectuer des tâches temps réel, nécessitant une synchronisation précise. Il semblerait que pour cela, il faille travailler à un niveau beaucoup plus bas, ce qui compliquerait beaucoup trop l'application et son installation.
Donc, nous avons essayé de faire avec ce que nous avions, notamment les "timers" d'Alsa. Grâce à eux, il est possible de définir qu'une partie de notre programme (celle qui envoie les données MIDI) soit appelée régulièrement, toutes les millisecondes, par exemple. Cela a d'abord plutôt bien fonctionné, et nous avons pu tester la régularité des appels et la fiabilité de ce système, puis avons tout mis au propre, croyant que notre problème était résolu.
Malheureusement, il semble que, dans la pratique, cette fonctionnalité ne soit pas gérable. Elle perturbe gravement tous les timings du reste du programme, en rendant inutilisables les fonctions système telles que "sleep" ou "usleep", et en induisant des ralentissements sensibles dans la gestion des événements de l'interface graphique.
Croyant que nous avions commis une erreur dans l'écriture du code, nous avons compilé l'exemple "timer.c" livré avec ALSA et l'avons essayé sur une vraie machine Linux. Même résultat. C'est donc bien un problème inhérent aux timers ALSA, et nous en sommes revenus au point de départ, avec de moins en moins d'espoir de pouvoir faire fonctionner la sortie MIDI correctement dans la version Linux.  |
|
|
| by Olivier Guillion | |
|
| |
|
La gestion des entrées-sorties MIDI a été implémentée sans trop de difficultés. Nous avons pu trouver les fonctions très bas niveau (choix de l'interface MIDI, envoi des données MIDI brutes) dont nous avions besoin.
On peut donc maintenant sélectionner une interface MIDI dans la boîte de configuration matérielle, et appuyer sur le bouton "Test" pour entendre des notes se jouer sur la MIDI.
Nous avons ensuite essayé de passer à l'étape suivante, jouer la musique sur une sortie MIDI. Et là, nous nous heurtons à un problème ardu : la difficulté (l'impossibilité?) sur Linux de définir qu'une fonction est appelée à intervalle régulier, et très souvent, par exemple à chaque millième de seconde.
Cela nous est nécessaire pour obtenir une sortie MIDI bien régulière et synchronisée, et, pour l'instant, nous n'avons pas réussi à trouver une manière de faire cela. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, nous avons momentanément laissé tomber les problèmes d'ordre d'empilage des fenêtres (sous Unity, il faut cliquer 2 fois sur un document pour faire passer sa fenêtre à l'avant-plan) afin d'avoir l'impression d'avancer un peu.
Nous avons donc implémenté:
- Les clics et double-clics souris avec les deux boutons (en fait, jusqu'à 5 boutons)
- Les défilements rapides avec la molette de la souris
- Les touches du clavier "modifiers" (Ctrl, Maj, Alt, etc)
- Les raccourcis clavier dans les menus (Ctrl N pour "Nouveau", etc)
- L'entrée de textes au clavier. Pour l'instant, c'est une version très simplifiée, qui ne permet pas d'entrer les caractères accentués sur deux touches (ê, ï, etc) ni les langues complexes (japonais, arabe,...), mais c'est déjà suffisant pour tester en profondeur.
- Les touches fléchées, page précédente, page suivante, suppressions, tabulations, etc dans l'édition des textes
Maintenant, nous essayons, au sens propre, d'arrondir les angles de nos fenêtres, en bataillant avec les documentations incomplètes, obsolètes ou même trop à jour, Ubuntu n'intégrant pas encore la dernière version de GTK. |
|
|
| by Olivier Guillion | |
|
| |
|
Nous continuons à progresser, parfois pas aussi vite que nous le voudrions, principalement en raison du manque de documentation complète de chacun des modules du système.
Mais bon, nous avons pu mettre en place:
- La gestion de la forme du curseur de la souris, ceci incluant les formes définies par l'application
- Les processus permettant à l'application de prendre en compte les mouvements et redimensionnements de fenêtres que le système n'a pas pu mener à bien
- L'ordre d'empilage des fenêtres, notre petite astuce (voir étape 34) ne fonctionnant pas sur Unity. Nous avons trouvé une parade, mais nous ne pouvons pas être certain qu'elle fonctionnera sur les prochaines versions...
Dès que nous aurons une version de Melody qui tourne de manière à peu près satisfaisante, nous ferons bien entendu appel aux Linuxiens parmi vous pour démarrer une session d'alpha-test. Mais, à l'heure actuelle, c'est encore un peu prématuré : les problèmes de fonctionnement sont encore nombreux, et nous les détectons aisément. Des rapports de problème ne nous seraient donc pas utiles à ce stade. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons résolu une partie des problèmes liés au système de fenêtrage, abordés dans le billet de l'étape 31.
N'ayant pas trouvé de solution "propre", nous avons exploité une fonction a priori pas destinée à cela, mais qui nous permet de réaliser ce que l'on désire, c'est-à-dire positionner les fenêtres les unes au-dessus des autres dans l'ordre voulu.
Nous espérons seulement que cela fonctionnera de la même façon dans les autres versions de Gnome, et les futures versions d'Ubuntu.
Reste un problème inhérent au système, qui est le délai entre les ordres donnés au gestionnaire de fenêtres et leur résultat effectif. En résumé, cela veut dire que notre programme positionne une fenêtre sur l'écran, lui donne une taille, mais cette position et cette taille ne seront réellement appliquées qu'au bout d'un certain temps, et encore, peut-être pas avec les valeurs demandées.
Cela a donc nécessité de mettre en place un système de feedback qui réajuste les valeurs internes à ACAM par rapport à ce qui s'est véritablement passé sur l'écran. Il y a encore quelques ratés, mais globalement ça fonctionne plutôt bien.
Nous implémentons maintenant les curseurs souris définis par l'application. En effet, en leur absence, la forme du curseur reste fixée sur un rond avec des points qui tournent, équivalent Ubuntu du sablier de Windows.
Cela nous gène pour voir ce qu'il y a sous la souris, et pour cliquer précisément sur les icônes ou sur la partition. |
|
|
| by Olivier Guillion | |
|
| |
|
|
