- Un crash nous avait été signalé lors de l'utilisation de certaines boîtes en version Linux. Après deux jours de recherche, nous avons localisé une erreur dans une fonction très bas niveau de nos bibliothèques d'interfaçage : des transferts mémoire erronés qui pouvaient corrompre, dans certains cas, l'intégrité de la zone traitée.
La résolution de ce problème devrait donc améliorer la stabilité générale de la version Linux.
- Sur Linux encore, les polices de caractères musicaux autres que SToccata n'étaient pas gérées correctement.
- Sir Linux toujours, l'ordre des modèles dans la boîte d'ajout d'une nouvelle portée était aléatoire. Cela a été repris pour proposer en premier les portées simples les plus couramment utilisées.
Une nouvelle version beta d'Harmony Assistant pour Linux vient d'être mise à disposition pour pouvoir tester tout cela (5.6.2n beta 5b). |
|
|
| by Olivier Guillion |  |
| |
|
- Si deux croches étaient ligaturées par-dessus un silence, rendre ce silence invisible "cassait" la ligature. L'effet pervers était que la ligature réapparaissait dès qu'on demandait l'affichage des taquets en mode page. En effet dans ce mode, les silences invisibles sont montrés, mais colorés en gris.
- Sur Linux, il semble qu'il ne soit pas possible de débrayer les automatismes du gestionnaire de fenêtres. L'analyse d'autres logiciels sous Linux semble montrer que les programmeurs doivent déployer des trésors d'imagination pour tenter de contourner les limitations imposées par ce systlème. Il nous a donc fallu réécrire à nouveau le module de gestion des fenêtres, et publier une version beta. Il y a encore des problèmes d'ordre de recouvrement, mais au moins, le système ne gèle plus lorsque le nombre de palettes affichées est important. A suivre donc.
- Toujours sur Linux, un crash survient lors de la gestion des fenêtres à rubriques (p.ex. l'aspect graphique de la partition). Parfois, des curseurs d'un ancien onglet restent présents. Nous essayons de comprendre d'où cela peut venir.
- A la demande d'un utilisateur qui enregistrait des données MIDI sur 16 canaux instrumentaux sans portée de batterie, nous avons créé un petit script qui transforme les portées de batterie d'une partition en portées standard. En effet, il n'est pas prévu qu'aucun des 16 canaux MIDI ne corresponde aux instruments de batterie.
Nous avons ainsi créé au cours du temps pas mal de petits scripts spécifiques, avec peu ou pas d'interface graphique, et nous nous demandons si ce serait judicieux de les proposer quelque part plutôt que de ne les donner qu'à la seule personne qui en a fait la demande. D'un autre côté, expliquer précisément ce qu'ils font, dans quel cadre et dans quel but nous prendrait souvent plus de temps que l'écriture du script elle-même (ou "lui-même", comme vous préférez) ... |
|
|
| by Olivier Guillion | |
|
| |
|
Les premiers retours sur la version beta Linux sont encourageants : la réactivité du programme aurait été grandement améliorée. Quelques problèmes d'empilement de fenêtres demeurent cependant : certaines boîtes apparaissent derrière les fenêtres de document au lieu de devant. Elles sont alors invisible, et le programme paraît bloqué.
Il nous reste donc encore du travail sur ce sujet.
Afin de pouvoir tester correctement les prochaines versions, nous avons commencé à reconstituer notre éventail de machines virtuelles. Mais au vu du nombre infini de distributions Linux, multiplié par le nombre de versions de chacune, et tout cela multiplié par deux (version 32 et 64 bits), cela nécessiterait un nombre encore plus infini de machines virtuelles. Nous nous en tiendrons donc au 3 ou 4 distributions les plus courantes, sauf demande particulière. |
|
|
| by Olivier Guillion | |
| |
|
Le problème dans la gestion des fenêtres de la version Linux/GTK ont été identifiés. Nous sommes en train de chercher un contournement, et une version beta sera disponible très prochainement pour le tester.
Depuis nos débuts de développement sur Linux, nous nous heurtons à des problèmes importants liés à la gestion des fenêtres.
Les systèmes de fenêtrage "modernes" que nous avions vu jusqu'alors étaient structurés ainsi :
- Au plus bas niveau, un gestionnaire d'aires traçables à l'écran
Il gère le tracé sur des zones de l'écran
- Au-dessus, le système de fenêtrage proprement dit.
Il gère le tracé des aires système des fenêtres, leur chevauchement et mise à jour
- Au-dessus encore, l'application elle-même, qui a accès aux deux couches basses.
Ainsi l'application a la maîtrise de ses fenêtres. Elle peut y tracer dessus, modifier leur forme, gérer les empilages et chevauchements, et gérer les clics.
Sur Linux, ce n'est pas structuré ainsi.
En couche basse, X-Windows, qui est déjà extrèmement complexe. Il gère les fenêtres, leur empilement, le clic, même le glisser-déposer de fichier.
Au-dessus, GTK qui gère l'apparence des zones système des fenêtres, et se contente essentiellement de rendre accessibles certaines des fonctions X-Windows.
Il n'y a donc plus d'accès aux "couches basses" du système de fenêtrage. Des requètes sont envoyées par l'application à GTK, qui les transmet à X-Window, qui les honorera *peut-être*, dans un délai *indéterminé*.
On se contente donc de suggérer au système de fenêtrage que telle fenêtre devrait être agrandie, devrait passer devant l'autre, etc. De plus, la mise au premier plan de la fenêtre cliquée semble automatique. Elle passe donc devant les palettes, sans qu'il soit possible de définir, comme sur MacOS ou Windows, des classes de fenêtres, chaque classe ayant une priorité d'empilement par rapport aux autres classes, et l'ordre d'empilement des fenêtres dans chaque classe étant géré par le programme.
Nous avons donc galéré, sur Linux, et bricolé une solution. Mais il s'avère que sur certaines versions d'Ubuntu, lorsque beaucoup de palettes sont ouvertes, le programme ralentit considérablement.
Nous avons heureusement trouvé une nouvelle fonction, très peu documentée et ajoutée à GTK en urgence entre 2 versions majeures, qui nous permet d'obtenir un résultat un peu moins agréable graphiquement, mais bien plus rapide. A tester maintenant sur toutes les distrib et leurs diverses versions.
|
|
|
| by Olivier Guillion | |
|
| |
|
Deux utilisateurs de la version Linux nous ont fait part de ralentissements, voire de blocages de l'application, apparemment liés à la gestion des fenêtres. Nous avons réussi à mettre en évidence un tel cas sur notre machine, en espérant qu'il s'agisse bien du même problème. Nous essayons de le résoudre, mais le cas que nous arrivons à reproduire entraîne un blocage total, ce qui nous empêche de voir d'où cela vient.
Des problèmes de mauvaise libération de mémoire ont été détectés dans l'édition des instruments virtuels. Nous travaillons à leur résolution.
La base de données de Kooplet a été détériorée suite à un redémarrage de notre serveur. Nous sommes repartis d'une sauvegarde d'il y a quelques jours et avons, en collaboration avec notre hébergeur, mis en place un système pour éviter ce genre de désagrément à l'avenir.
Les pages de MUSL généraient une erreur HTML non létale dans la console du navigateur de l'utilisateur. Ceci était dû à une réponse non standard d'un script de gestion de la date et heure courante, et a été corrigé.
|
|
|
| by Olivier Guillion | |
| |
|
|
