Pour terminer l'année, les dernières versions Beta ont été postées.
Elles concernent Melody et Harmony d'une part, et PDFtoMusic et PDFToMusic Pro de l'autre.
Nos autres applications, Melody Player et Myriad Plug-in, dont le fonctionnement avait été peu modifié par rapport à la beta précédente, n'ont pas été republiés.
Outre les corrections de problèmes listés aux fils des jours dans ce blog, les nouvelles versions sont donc utilisables sur les vieilles versions de Windows (95, 98 et ME) par le biais d'une version spéciale, également téléchargeable.
L'heure n'est pas encore au bilan de cette version beta, mais au vu de la multitude de corrections apportées grâce à la recompilation de la version Windows, la stabilité de toutes nos applications devrait avoir été grandement améliorée. Nous restons cependant à l'affut des rapports de crash provenant de participants à la version beta, et surtout des fichiers qui leur ont posé problème, seul moyen pour nous de reproduire et corriger ce dernier.
Mais sur ce, nous vous souhaitons un bon réveillon, et un passage en douceur à l'année 2010 ! |
|
|
| by Olivier Guillion |  |
|
| |
|
- PDFtoMusic, amelioration de la transformation des frames en lignes horizontales. Cela donne de bien meilleurs résultats dans le traitement de certaines accroches horizontales.
- Amélioration des scripts Finale et NoteWorthy.
Et surtout, archivage complet de l'ensemble de nos travaux sur un disque dur amovible dédié à cet effet...
|
|
|
| by Didier Guillion |  |
| |
|
Harmony / Melody
- Les mesures de métronome avant le début de la musique étaient exportées en numérique, ceci a été corrigé.
- Il est maintenant possible de spécifier que la taille des paroles est adaptée en fonction de l'échelle d'affichage de la portée.
- Sur Windows, correction de l'aspect des groupes de notes et des trilles altérées dans la palette d'ornements
- Crash possible lors de la fabrication de la liste des noms de séquence d'accompagnement.
- Modification de l'interprétation des symboles d'appui et de fin de pédale (Ped / *). Une note relâchée par une fin de pédale (*) ne peut pas voir sa relâche maintenue par un nouvel appui de pédale (Ped).
- L'option "Edition > Ajouter" ne vérifiait pas la présence d'une barre de mesure avant d'en ajouter une autre. Ceci permettait d'avoir plusieurs fois la même barre dans une même mesure. Avec plusieurs copier/ajouter successifs, le nombre de barres augmentait exponentiellement, jusqu'au "plantage" du fichier. On nous signale que ce problème affectait également le script "Joindre fichiers". Nous devons vérifier si cela a également été corrigé.
PDFtoMusic / Pro
- Correction d'un crash dans la gestion des coulés multiples (devait aussi affecter l'import XML d'Harmony).
- l'export MIDI avait été malencontreusement inactivé. C'est rétabli. |
|
|
| by Olivier Guillion | |
| |
|
Bon sang, c'est déjà Noël !
Cette année, les fistons voulaient un sapin de Noël "grand". Ils l'ont eu. Mais il a fallu un escabeau pour poser les décorations ...
Toute l'équipe de Myriad vous souhaite de joyeuses fêtes familiales, nous lèverons notre coupe de vin à bulle à votre santé !
|
|
|
| by Didier Guillion | |
|
| |
|
Une mésaventure est arrivée à ma petite belle-soeur, et j'ai passé un peu de temps à lui arranger tout ça. Voila de quoi il s'agit, cela pourra toujours aider quelqu'un dans le même cas.
Dans Windows 7 (et peut-être déjà dans Vista) un nouveau panneau a fait son apparition. Il permet d'affecter un programme à un type de fichier. Par exemple, si on veut que tous les MP3 s'ouvrent avec iMedia plutôt qu'avec Tune Player, il suffit d'aller dans le menu Windows, de sélectionner "Programmes par défaut", puis "Associer un type de fichier ou un protocole à un programme".
Apparaît alors une boîte permettant de sélectionner un type de fichier (.mp3, .txt, etc) et de définir l'application qui l'ouvrira.
Ceux parmi vous qui ont une bonne vue auront remarqué qu'il est possible de changer l'application qui ouvre les fichiers ".lnk". Les .lnk, ce sont les raccourcis vers les applications qui fleurissent sur les bureaux et dans le menu des programmes. Par définition, il n'ont pas besoin d'une application pour les ouvrir, puisque eux-même servent à ouvrir une application...
Mais chez Microsoft, ils ont oublié de retirer ce type de fichier de la liste, comme ils l'ont pourtant fait avec ".exe".
Résultat : si vous définissez un programme pour ouvrir les .lnk (par exemple le bloc-notes ou Internet explorer), tous les raccourcis apparaîtront avec le symbole de l'application sélectionnée : des bloc-notes ou des "e" bleus partout sur le bureau, à la place de l'icône de l'application que ces raccourcis représentent !
Cerise sur le gâteau, tous ces raccourcis ne fonctionnent plus, car Windows essaie alors de les faire ouvrir par l'application sélectionnée, qui ne sait pas vraiment quoi en faire.
Chantilly sur la cerise, il est impossible de revenir à la valeur par défaut, car, depuis la boîte d'association de type de fichier, on ne peut pas revenir à "Application inconnue". On peut seulement choisir un autre programme, qui ne saura pas plus que l'autre ouvrir ces .lnk.
Enfin, paillettes de chocolat sur la chantilly, cette opération de destruction ne nécessite pas les droits administrateurs, ce qui permet de planter le compte d'un utilisateur en seulement quelques secondes.
Donc, si vous possédez un sens de l'humour un peu spécial, ou que vous en voulez vraiment à quelqu'un, n'oubliez pas de remercier Microsoft pour laisser de tels trous dans son système.
Je donne cependant la solution pour remettre tout ça en place :
lancez "Regedit" et dans "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Fi leExts\.lnk", supprimez le dossier "UserChoice" puis redémarrez la session.
Simple, n'est-ce pas ?
Bon réveillon à tous !  |
|
|
| by Olivier Guillion | |
|
| |
|
Depuis quelques semaines, nous avons reçu un nombre anormalement élevé de courriels nous signalant qu'Harmony Assistant ne pouvait plus être lancé sur Windows XP.
Une boîte d'alerte système s'ouvre lors de la tentative de lancement, indiquant: "Windows ne parvient pas à accéder au périphérique, au chemin d'accès ou au fichier spécifié. Vous ne disposez peut-être pas des autorisations appropriées pour avoir accès à l'élément.".
Après de longues et pénibles investigations tous azimuths, nous pensons avoir enfin compris ce qui peut bien s'être passé.
Tous les utilisateurs rencontrant ce problème semblent utiliser le même antivirus : Kaspersky.
Suite à une réelle infection de leur ordinateur, ou, plus probablement, suite à un "faux positif" lors de l'utilisation à une certaine date par Kaspersky d'une base virale mal configurée, l'exécutable Harmony Assistant a été considéré comme "application douteuse" (sic).
Il a donc été rangé d'office dans la liste des programmes ne devant pas être lancés. Malheureusement, l'alerte apparaissant désormais lors d'une tentative de lancement est moins que claire, et ne permet pas de faire le lien avec l'antivirus.
Il suffit de déplacer Harmony Assistant vers la liste des applications dites "de confiance" pour tout arranger.
L'honnêteté intellectuelle des fabricants d'anti-virus devrait leur imposer de re-tester les programmes rangés en quarantaine lors de la sortie d'une nouvelle base virale. Si un programme n'était pas détecté auparavant, a été détecté un jour, mais ne l'est plus le lendemain, il y a de fortes chances qu'il se soit agi d'un "faux positif", et l'antivirus devrait alors proposer de le rétablir.
Mais il faudrait alors montrer clairement à l'utilisateur que l'antivirus n'est pas infaillible et peut commettre des erreurs. Il est plus simple et moins dommageable pour l'image de marque de laisser l'application "plantée", et de faire porter le chapeau à celle-ci, en délivrant une information confuse. L'utilisateur et le support technique de l'application se lasseront peut-être, et personne ne saura jamais ce qui s'est vraiment passé...
Merci à B.T (Chicoutimi, Qc) pour son assistance et sa patience. |
|
|
| by Olivier Guillion | |
|
| |
|
La version Windows de nos programmes est appelée à fonctionner sous 3 environnements différents :
- Windows 2000/XP/Vista/7
- Windows 95/98/ ME
- Linux au travers de Wine
La version 95/98/ ME nécessite une compilation et une mise en place différentes. Nous avons donc créé les projets correspondants, compilé pour ces plateformes, créé les installateurs et essayé tout cela sur nos machines virtuelles équipées d'anciens OS.
La version Linux/Wine, elle, utilise directement la version "standard" pour les Windows récents. Par contre, elle nécessite de petits aménagements, les polices de texte proposées dans Wine posant quelques problèmes. En effet, la fonte standard Windows "Tahoma" est bien présente sous Wine, mais les résultats visuels sont catastrophiques pour les petites tailles. Nous devons donc trouver un moyen, sous Wine, de choisir une autre fonte par défaut, sachant que la liste disponible semble varier entre les distributions et versions de Linux.
Ensuite, nous essaierons de débarasser l'installateur de l'alerte qui apparaît sous Linux, et qui est due à l'absence du menu standard des programmes installés présent sous Windows (Menu démarrer > Programmes).
|
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, c'est comme un Lundi, nous passons une bonne partie de la journée à traiter les emails du week-end.
Ensuite,
- Nous travaillons de concert avec le traducteur Japonais sur la nouvelle version.
- Correction de l'importateur Finale
- Correction de la doc PDFtoMusic
|
|
|
| by Didier Guillion | |
| |
|
Un peu de légèreté pour terminer la semaine...
C'est une curiosité dont nous avions parlé ici même il y a environ un an. Le "Tilt-Shift" est un procédé photographique qui permet de prendre des photos de paysages ou personnages réels, et de les faire apparaître comme des maquettes.
Il est aussi possible de retoucher des photos ou des films pour leur donner cet effet. Vous pouvez l'expérimenter vous-même à partir d'une photo de monument par exemple :
- Réduisez considérablement la profondeur de champ de la photo en appliquant des masques de flou successifs, de plus en plus prononcés lorsqu'on s'éloigne de la zone de mise au point.
- Saturez un peu les couleurs, les maquettes ayant souvent des couleurs plus vives que les objets grandeur nature
- S'il s'agit d'un film, passez-le à l'accéléré pour imiter des prises de vue image par image, et pour changer la fluidité apparente de l'eau dans les scènes de plage.
C'est ce type de procédé qu'a employé avec bonheur l'australien Keith Loutit, pour nous proposer des petits films saisissants sur un monde de lilliputiens embarquant dans des bateaux ou hélicoptères jouets.
Vous pouvez regarder ses films ici.
Pour retrouver son âme d'enfant et espérer à nouveau que le père Noël nous apportera toute une collection de petites voitures, camions de pompiers et figurines.
|
|
|
| by Olivier Guillion | |
| |
|
- Correction d'un problème de clipping sur les diagrammes d'accord guitare dans la ligne d'accord.
- Remaniement de la documentation de Melody Player
- Remaniement de la documentation de PDFtoMusic
- Correction de l'affichage des boutons MyrScript dans les palettes utilisateurs zoomées.
- Crash lors de la création d'un nouvel accompagnement
- Windows: icônes de la palette "Outils divers" déformés
- Windows: menus contextuels s'ouvrant aux alentours du bas de l'écran apparaissaient sur plusieurs colonnes
- Windows: boîtes vides lors de la désinstallation
- Windows 95/98 : erreur lors de l'ouverture d'une boite de sélection de fichier
|
|
|
| by Didier Guillion | |
| |
|
Comme nous l'annoncions dans le billet d'avant-hier, le maintien de la compatibilité de nos programmes avec les version de Windows pré-2000 (Windows 95, 98 et ME) posait de sérieux problèmes.
Entre arrêter purement et simplement cette compatibilité, ou déployer des efforts disproportionnés pour l'assurer, nous devions faire un choix.
Nous avons découvert quelques astuces qui nous permettent de générer encore des versions de programmes compatibles avec ces Windows 9x. Ce n'est ni immédiat, ni automatique, mais c'est faisable.
Aussi, nous avons décidé de maintenir, en tout cas pour un temps, la compatibilité.
Mais les utilisateurs de Windows 9x devront installer une version spéciale de nos programmes, qui ne sera pas mise à jour avec la même fréquence que la version standard. Les éventuels rapports de crash de ces versions ne pourront pas non plus être traités aussi rapidement que les autres.
En résumé, nous fournirons des versions compatibles de temps en temps, afin de permettre à ces utilisateurs de conserver la compatibilité de fichier et de fonctions avec les versions récentes. Mais ces versions spéciales seront fournies sans garantie de résultat, les utilisateurs étant priés d'envisager sérieusement la mise à jour de leur système (une fois tous les 10 ans, ce n'est pas du luxe).
Sur Macintosh, un problème similaire nous était posé par la dernière version du système de développement XCode, annonçant une incompatibilité avec les version de Mac OS inférieures à 10.4.
Nous avons donc testé nos nouvelles versions d'application sur Mac OS 10.3, et à notre grande surprise, elles fonctionnent parfaitement. Effet d'annonce, erreur, ou incompatibilité seulement partielle ne nous affectant pas ? Nous n'en savons rien, mais pouvons continuer à produire des programmes fonctionnant sur 10.3.
|
|
|
| by Olivier Guillion | |
|
| |
|
- Des décalages de sélection de texte ont été corrigés dans la doc MyrScript
- Les installateurs Mac avaient une mauvaise option de compilation ce qui les rendaient incompatible avec Mac OS <10.6. Cela a été corrigé et toutes les archives publiées à nouveau.
- Correction des caractères accentués dans les textes d'aide associés aux items des dialogues MyrScript
|
|
|
| by Didier Guillion | |
| |
|
Nous avons enfin pu, pendant quelques heures, réinstaller Windows 98 en machine virtuelle pour tester nos logiciels. Hélas, VirtualBox ne semble pas très doué pour gérer ces anciennes versions du système, et les crashs à répétition ont eu raison de notre test. Il ne nous reste plus qu'à recommencer une installation.
Mais entre-temps, nous avons pu lancer nos installateurs, et là, mauvaise nouvelle: ils ne fonctionnent plus pour des versions de Windows inférieures à Windows 2000.
Le nouveau compilateur (Visual C++) ne sait plus générer d'exécutables compatibles avec les anciennes versions du système du même éditeur. Outre les librairies de démarrage (Run-time libraries, appelées aussi "CRT") qui ont besoin de fonctions apparues avec Windows 2000, le compilateur marque les exécutables qu'il génère avec un sceau "Windows 2000 et supérieur" qu'il n'est apparemment pas possible de modifier.
Nous avons donc 5 solutions (si vous en trouvez une autre, exprimez-vous) :
1- Faire en sorte que ces exécutables, une fois compilés, soient à nouveau compatibles, par exemple changeant la version minimale nécessaire, et en court-circuitant les fonctions dans le CRT.
Pas génial, c'est un peu du bricolage, et cela revient à hacker nos propres programmes.
2- Reprendre et modifier les sources du CRT de Microsoft, et enlever ce qui est spécifique à Windows 2000.
Pas top, car nous ne disposons pas de ces sources, et cela rendrait difficile les évolutions dans les versions du compilateur. De plus, cela ne résoudrait pas le problème de la version minimale demandée, et nécessiterait tout de même de modifier les fichiers exécutables après compilation.
3- Compiler tant que c'est encore possible nos programmes sur notre ancien compilateur CodeWarrior, qui lui est resté compatible.
Possible, mais c'est reculer pour mieux sauter. Nous savons qu'au prochain changement de machine, nous aurons probablement un système récent (Windows 7) sur lequel CodeWarrior ne fonctionnera pas.
4- Fournir deux versions de nos produits, en conservant une machine sous Codewarrior qui compile pour Windows 9x.
Waouh, théoriquement possible, pratiquement difficile. Ce serait vraiment beaucoup de peine (machines multiple, maintien de la compatibilité de tous nos projets avec l'ancien système, double maintenance de tous nos produits...) pour un maigre résultat.
5- Abandonner purement et simplement la compatibilité Windows 9x. Il y a malheureusement encore des utilisateurs sous Windows 95, 98 ou ME. Même si nous leur laissont la possibilité de télécharger la dernière version compatible (9.4.7c) ils vont petit à petit perdre la compatibilité en fonctionnalités et en format de fichier avec les nouvelles versions du programme. C'est surtout dommage car, fonctionnellement, tous nos programmes tournent sans problème sur ces systèmes.
Cinq solutions, et aucune de satisfaisante. Nous allons, je crois, être obligés de déterminer quelle est la moins mauvaise. |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, nous avons généré les nouvelles bêta versions d'Harmony Assistant, Melody Assistant, Melody Player, PDFtoMusic, PDFtoMusicPro, Myriad Music Plug-in, ouf ! Le tout à été mis à disposition des bêta testeurs qui vont avoir un dur week-end. Nous on va faire la grasse matinée, hé-hé.
Le changement fondamental est la compilation de tous les logiciels avec un nouveau compilateur que ce soit sur Mac ou sur PC.
Sur les deux plateformes, également, les installateurs sont nouveaux, de sacrés tests en perspective...
Mais bon, pas de panique, à priori cela a déjà été validé en profondeur de notre coté.
Allez, pour vous détendre, un lien sur un de nos sites préférés :
http://www.levisiteurdufutur.com/accueil.html |
|
|
| by Didier Guillion | |
|
| |
|
Nous travaillons toujours sur la prochaine version beta, en essayant d'y inclure tout ce qui est susceptible de poser problème, afin de permettre la plus longue période de test possible.
Ainsi, certains utilisateurs sur Windows Vista (et peut-être Windows 7), avaient un problème d'installation de la police musicale. Ils installaient le programme, le lançaient et tout fonctionnait. Mais après un redémarrage de l'ordinateur la police n'était pas disponible, et ils devaient alors réinstaller pour pouvoir travailler.
Nous n'avons jamais pu reproduire ce problème sur nos machines virtuelles. D'après les symptômes, il semblerait que ce soit dû à une impossibilité pour l'installateur d'inscrire quelques clés dans le registre Windows, empêchant ainsi une déclaration permanente de cette police.
Nous avons donc décidé de mettre en place le mécanisme suivant dans tous nos programmes en version Windows : si, au lancement du programme, la police musicale n'est pas disponible dans le système, la copie de celle-ci (dans le sous-dossier "Font" de l'application) est utilisée localement jusqu'à la fermeture du programme.
Malheureusement, les fonctions nécessaires à ce procédé ne sont disponibles qu'à partir de Windows 2000. Nous nous efforçons donc de redémarrer nos machines virtuelles sous Windows 95 et 98 afin de le tester et d'assurer une compatibilité, même au prix de fonctionnalités réduites, avec ces anciens systèmes.
Car, même si notre sondage ne le montre pas encore, nous savons que plusieurs utilisateur continuent de fonctionner avec ces vieux machins. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui :
Myrscript : BrowseFolder peut maintenant extraire les noms de sous dossier.
Correction du script "Doigté pour instrument à cordes frettées"
Correction du script "Export par lot"
Correction d'un problème dans le forçage des mesures jouées.
Correction de la méthode MusicExport avec des fréquences non autorisées en MP3
Nous envisageons une bêta de la plupart de nos logiciels pour la fin de la semaine...
|
|
|
| by Didier Guillion | |
|
| |
|
Aujourd'hui, les trépidations des engins de chantier dans la rue, de l'autre coté du mur du bureau, ne nous ont pas beaucoup laissé de possibilité d'une grande concentration.
Un gros rouleau compresseur produit des vibrations, amplifiées par l'effet de caisse de résonance des planchers, que nous évaluons à 4 sur l'échelle de Richter.
Nous avons cependant corrigé quelques problèmes signalés par les utilisateurs, par exemple des crashs lors de l'utilisation de certaines fonctions de formatage des paroles dans le cas de portées fusionnées.
Le modèle de portées "grégorien" a également été corrigé, l'ancien comportant 5 lignes au lieu des 4 attendues. Quelques scripts ont également été repris.
Enfin, nous avons commencé à réfléchir à la manière d'organiser les données dans notre future interface graphique, afin de faciliter le travail de relecture, modification et traduction du contenu des boîtes de dialogue. |
|
|
| by Olivier Guillion | |
| |
|
A l'occasion de la sortie d'Ubuntu 9.10, cryptiquement nommée "Karmic Koala" (on peut présager que la suivante s'appellera "Lazy Llama"), Toulibre et Ubuntu-fr organisaient samedi après-midi une ubuntu-party à Toulouse. Nous sommes donc allés y faire un tour en voisins curieux.
Un public jeune et nombreux était présent, des planches didactiques sur le logiciel libre, les diverses licences ou l'open-source permettaient aux visiteurs un peu extérieurs au mouvement comme nous de tenter de comprendre le modèle économique sous-jacent, à moins qu'il s'agisse d'une philosophie, ou même, à en écouter certains, d'une véritable religion. 
Des conférences techniques étaient également organisées. Toujours préoccupés par nos problèmes d'outils de développement et de librairie graphique multi-plateforme, nous avons assisté à deux conférences:
- La première concernait Eclipse, que nous pensions être un environnement intégré de développement (IDE) destiné au Java et au C++.
En fait, l'outil est plus large que ça, et sa structure permet de faire virtuellement n'importe quoi avec, pour autant qu'il s'agisse de saisir, visualiser, éditer et transformer les données. Son architecture ouverte lui permet d'accueillir des plug-ins, qui cohabitent en harmonie pour produire le résultat attendu.
Nous avions connaissance d'Eclipse depuis plusieurs années, mais nos tentatives d'utilisation comme simple IDE pour le C s'étaient avérées décevantes, donnant l'impression, maintenant expliquable, d'essayer d'utiliser un couteau suisse à 25 lames pour planter un simple clou.
- La seconde conférence concernait QT4, l'environnement graphique multi-plateforme utilisé notamment par KDE (par exemple dans KUbuntu). Une très bonne présentation technique en a été faite, permettant d'en comprendre les concepts de base. Techniquement, tout a été parfaitement clair, et la bête semble bien structurée, solide, puissante et agrémentée d'excellents outils. Seuls bémol pour l'usage que nous désirons en faire.
Nous avons eu confirmation cette librairie n'utilise pas les objets graphiques standard du système, mais retrace les siens. Elle imite cependant l'aspect standard, si bien qu'il est impossible de se rendre compte de la différence.
Cela pose cependant quelques problèmes : il faut avoir toute confiance en la réactivité de la communauté pour espérer que lors de la sortie d'une nouvelle version d'un système, la librairie continue à tourner, et soit agrémentée du nouvel aspect. De plus, les anciennes applications utilisant la librairie statique QT gardent l'ancien aspect sur le nouveau système.
Enfin, point qui n'a pas vraiment été approfonci lors de la conférence, le système de licence quasi-incompréhensible semblerait dire qu'il n'est possible d'utiliser QT, propriété de Nokia, dans un logiciel commercial aux sources fermés qu'en achetant une licence coûtant environ 1500 euros par type de machine visé. Nous espérons seulement que ceci ne concerne pas le développement en natif sur Kubuntu, sur lequel QT est le coeur de l'interface graphique.
Nous en restons donc pour l'instant à notre première idée, qui est de tout faire nous-mêmes, et de considérer QT seulement comme le moteur de l'interface graphique d'un des multiples systèmes sur lesquels nos applications seraient susceptibles de tourner.
Mais pour en revenir à la réunion, les participants étaient sympathiques et les intervenants d'un excellent niveau. Nous avons pu obtenir des réponses à quelques-unes de nos nombreuses interrogations. Assez pour commencer à chercher les autres nous-mêmes. |
|
|
| by Olivier Guillion | |
|
| |
|
En cette fin de semaine, nous avons corrigé des problèmes, certains assez vieux, dont peu d'utilisateurs s'étaient rendu compte. Entre autres :
- La correction de problèmes d'annulation d'opérations depuis MyrScript nous a permis de mettre en évidence la non prise en compte des modifications aux "Titre, compositeur, remarques" lors d'un "refaire" (contraire de "Annuler").
- La modification du titre de la partition par clic droit -> Editer ne pouvait pas être annulée.
- Le déplacement de notes en accord en sélection individuelle (maj-clic) ne fonctionnait plus depuis la version 9.4.7
- Un problème de coulé sur une note liée par-dessus une barre de mesure en fin de ligne a été corrigé
- Un problème d'échelle des différentes vues lors de l'impression de toutes les vues a été corrigé.
Enfin, ce week-end, si notre emploi du temps et le temps tout court le permettent, nous irons peut-être faire un tour du coté de l'ubuntu-party de Toulouse, histoire de voir de quoi qu'est-ce qu'on cause.
Et, pour mettre tout le monde de bonne humeur ce week-end, la vidéo du chaton le plus mignon du monde |
|
|
| by Olivier Guillion | |
|
| |
|
Après installation du nouveau système Mac OS, nous avons constaté un léger dysfonctionnement de certaines de nos applications : des libellés ne s'affichaient plus. Il a fallu mettre les mains de le cambouis et descendre très très bas pour nous rendre compte que l'affichage avec la police Geneva ne fonctionnait plus. Et de fait, nous avons découvert que Mac OS X avait créé une police Geneva cassée dans notre espace utilisateur. La supprimer a tout remis en ordre.
Aujourd'hui un utilisateur nous contacte, il est également sous 10.6 et n'arrive plus à imprimer, rien ne sort sur l'imprimante et même l'export PDF intégré au système ne donne rien. Après de long échanges pour essayer de localiser la cause, nous épuisons toutes nos idées.
Il contacte alors un technicien Apple et se rend compte que l'installation lui a créé une police Arial corrompue dans son espace utilisateur.
Poubelle et tout revient dans l'ordre.
Pour une raison mystérieuse, il semblerait que Snow Léopard fasse des copies défectueuses de certaines polices systèmes dans les polices utilisateurs lors de l'installation. A noter et à garder en mémoire...
|
|
|
| by Didier Guillion | |
| |
|
- Correction du script "Export par lot"
- Correction d'un crash dans la palette "mode page" en fermeture de l'application
- PDFtoMusic : gestion des métrique incomplète (par exemple "3" au lieu de "3/4")
- PDFtoMusic : amélioration de la reconnaissance des passages. Cela a demandé une modification sur une routine très bas niveau, donc pas mal de tests en perspective.
|
|
|
| by Didier Guillion | |
| |
|
Un point crucial dans l'élaboration d'un projet multi-plateforme est le respect de l'aspect graphique natif du système sur lequel tourne l'application.
Les utilisateurs de Mac OS X, en particulier, sont très sensibles à cela. Les utilisateurs Windows le sont un peu moins, peut-être, et enfin les Linuxien s'en fichent un peu, apparemment, vu la disparité de l'aspect des applications qu'on peut y trouver.
Certes, la personnalisation de l'apparence (les "thèmes" actuellement présents dans la version Windows de nos programmes) peut être pratique, mais pour la plupart des utilisateurs, un programme qui a une apparence "standard" est moins déroutant et plus facile à prendre en main.
Nos recherches dans le monde Linux, et la grande interrogation du choix de la distribution et de la librairie d'interfaçage nous ont amenés à nous pencher sur diverses solutions de développement multi-plateforme déjà existantes.
Ainsi, la librairie FLTK permet d'écrire des programmes pouvant fonctionner sur Linux, Windows ou Mac OS. Intéressant. La lecture de la documentation est alléchante, la licence LGPL peu contraignante. Mais respecte-t-il l'aspect du système sur lequel il fonctionne ? Difficile de trouver des informations claires à ce sujet. Une recherche d'images nous a convaincus du contraire :
 (Source)
Le bouton "OK" n'a pas vraiment le look "Aqua" de Mac OS X. Donc, a priori, cette solution est éliminée. Dommage.
Deuxième piste: GTK+. Créée à l'origine pour l'application graphique GIMP, cette librairie est elle aussi compatible Linux, Windows et Mac OS X. Hélas, apparemment même problème. Même si les boutons sont plus jolis, et que le thème peut être choisi par l'utilisateur, nous avons des doutes quant à son intégration des éléments de l'interface native. Cette image combine des boutons Aqua avec d'autres éléments (taquets, ascenseurs) définitivement non-Macs:
 (Source)
Enfin, Qt semble fournir un aspect cohérent avec le système sur lequel il tourne. Ce pourrait être un bon choix, car les sources sembleraient prouver qu'il utilise, autant que faire se peut, les appels au système pour tracer les objets graphiques.
Bémol de taille, il semblerait que QT, assez lourd d'utilisation, impose de travailler en C++, ce qui nous poserait des problèmes pour l'intégrer à nos projets existants écrits en C tout court.
Nous en revenons donc à la question de base. Même si cela est plus rapide, vaut-il mieux faire confiance à une librairie multi-plateforme existante, ou prendre le temps d'écrire la nôtre?
Nous avons fait une petite liste des avantages de chacun des deux procédés :
* Utilisation d'une librairie existante
- Mise en place plus rapide (tout est déjà prêt)
- Possibilité de compatibilité avec des systèmes que nous ne possédons pas encore
- Allègement de la charge de travail de mise à jour : tests, maintien et débogage assurés par la communauté
* Création et utilisation de notre propre librairie
- Meilleure adaptation à nos besoins
- Maintenance et débogage assurée par nos soins, sur des fichiers source que nous avons nous-même écrits
- Facilité d'ajouts ou de modification de fonctionnalités
- Contrôle total de nos application. En cas de bug, pas la peine de se demander qui l'a causé.
- Assurance de la pérennité de la librairie
Pour l'instant, la deuxième solution l'emporte, cette façon de travailler étant notre credo depuis nos tout débuts.
Reste alors la question du développement spécifique sur Linux. Avec quoi travailler sur ce système? Les librairies FLTK ou GTK utilisent-elles directement le système, ou, comme sur Mac OS ou Windows, tracent-elles leur propres boutons et autres objets?
De plus, ces librairies fonctionnent-elles aussi bien sur KDE que sur Gnome, sans demander à l'utilisateur d'installer quelque chose d'autre ? Les fonctionnalités sont-elles identiques sur les deux GUI ?
Etant donné notre très faible connaissance du développement sur Linux, et particulièrement le développement cross-distribution, cela risque de virer au casse-tête. Impossible de trouver une documentation claire sur la manière d'ouvrir une boîte de dialogue "native" sur KDE ou Gnome, c'est-à-dire respectant les personnalisations (couleurs, tailles de fontes, etc) effectuées globalement par l'utilisateur du système.
Apparemment, ce n'est pas le cas pour GTK+ sur une distrib basée sur KDE. Est-ce le cas avec QT4 sur une distrib basée sur Gnome? Ou nous faudra-t-il obligatoirement prévoir deux versions de chacune de nos applications sous Linux ?  |
|
|
| by Olivier Guillion | |
|
| |
|
|
