Nous avons pu créer une version d'Harmony Assistant n'utilisant plus du tout GTK, Cairo ou Pango, les bibliothèques de gestion d'interface de haut niveau.
Pour cela,nous avons dû créer un module d'affichage d'alerte système sur X11 pur, mais ce dernier ne propose rien pour gérer des boutons ou pour formater facilement du texte. Nous avons donc fait au mieux, quelque chose de pas trop moche, mais qui ne nous demande pas trop de travail. Cela sera utilisé uniquement dans le cas d'alertes système (par exemple en cas de crash).
Ca donne quelque chose comme ceci :
Pour l'instant, cette pré-version alpha d'Harmony ne permet pas d'ouvrir un sélecteur de fichier, d'imprimante, ou d'imprimer une page. Tout ceci devra être écrit plus tard.
Nous avons essayé d'installer cette version d'Harmony Assistant indépendante de la distribution Linux sur Ubuntu 14.04, en 64 bits. Et c'est là que les ennuis ont commencé. Pour résoudre les fameuses dépendances de bibliothèques, qui sont à la convivialité ce que le Kraken est à Bambi, il nous faut installer X11 en version 32 bits. Et lui-même a des dépendances, dont certaines ne peuvent pas être résolues.
Pour l'instant, nous en sommes là, à tourner en rond, et à faire chauffer notre ligne ADSL pour savoir quel paquet installer pour satisfaire quelle dépendance. Car, bien sûr, lorsqu'une bibliothèque "x" manque, ce serait trop simple d'installer le paquet appelé "x". Pour "X11", ce sera "xorg", pour "freetype", "libfreetype", pour "alsa", "libasound", etc.
Mais que cela ne vous empêche pas de passer un bon week-end (cela ne nous en empêchera pas non plus, je vous rassure) |
|
|
| by Olivier Guillion |  |
| |
|
Nous n'étions plus habitués à progresser rapidement sur l'interface Acam Winter pour Linux. C'est pourtant ce à quoi nous avons eu droit aujourd'hui.
Les touches "mortes"
Tout d'abord, nous rencontrions des problèmes de clavier avec les "touches mortes" (dead keys) permettant de taper des lettres accentuées, qui n'étaient pas gérées par X11. Mais nous avons pu trouver, sur le site du consortium Unicode, un fichier texte contenant l'intégralité du jeu de caractères, avec, pour chaque code, son nom en clair.
Nous avons pu écrire un programme jetable (en Perl), qui analyse ce texte, et reconstitue les caractères précomposés en fonction des deux touches entrées.
Par exemple, si l'utilisateur entre le caractère "^", il sera traduit par le code
0302 CIRCUMFLEX ACCENT
Ensuite, s'il entre un petit "e", il correspondra au code
0065 LATIN SMALL LETTER E
Or, dans la même table unicode, on a un caractère
00EA LATIN SMALL LETTER E WITH CIRCUMFLEX
Par analyse des noms des caractères, nous avons donc pu établir une table de correspondance complète entre les couples accent-lettre, et la lettre accentuée correspondante.
Les Alt-codes
Pour obtenir des caractères n'étant pas disponibles sur le clavier, sur Windows (et repris depuis sur d'autres systèmes), on peut appuyer sur Alt et entrer le code numérique du caractère.
Nous avons géré cela, en permettant l'entrée numérique par Alt-code de tous les caractères Unicode.
Par exemple, on pourra entrer Alt 234 pour obtenir un ê, ou Alt 0EA (le 0 de départ indiquant qu'il s'agit d'une entrée en hexadécimal) pour obtenir le même caractère. En effet, la plupart des tables Unicode sont fournies en hexadécimal, et il sera donc possible d'entrer directement des codes dans cette base.
Harmony Assistant
Acam Winter étant suffisamment fonctionnel, nous avons alors recompilé la version Linux d'Harmony Assistant avec cette bibliothèque. Après quelques ajustements d'options de compilation, nous avons obtenu ceci :
L'application utilisant le nouveau système d'interface est donc quasi-fonctionnelle.
Quelques détails restent à régler. Entre autres :
1- Les curseurs souris dessinés par nos soins. Les fonctions X11 pour gérer cela sont assez difficiles à maitriser.
2- Quelques touches clavier (Page up/Page Down, Suppr...) ne sont pas bien gérées
3- Le bouton droit de la souris et sa molette ne sont pas correctement pris en compte
4- Toute la partie impression est à reprendre en utilisant un export PostScript et CUPS.
Mais tout cela attendra la semaine prochaine.
Bon week-end à tous, et joyeuses Pâques ! |
|
|
| by Olivier Guillion | |
|
| |
|
Les affichages de textes sont maintenant terminés. Nous avons géré les différents styles et écrit les routines permettant de créer ces styles lorsqu'aucune variation de la police n'est disponible.
Ainsi, les styles gras, italique, souligné, contour (pas facile, celui-ci), ombré, condensé ou étendu sont gérés sor toutes les polices, en toutes les tailles.
Le mode de fonctionnement de l'interface étant maintenant en MDI, c'est-à-dire une grande fenêtre de bureau contenant le menu et toutes les fenêtres et palettes de l'application, nous avons créé les ascenseurs qui permettent de voir les morceaux de fenêtres qui sont en dehors de l'aire du bureau. Ces ascenseurs ont été réduits au strict minimum pour éviter de gâcher de l'espace sur l'aire utile.
Dans l'image ci-dessous, l'ascenseur vertical est montré par une flêche :
On peut également y voir un texte en contour et ombré. Bizarrement, la bibliothèque d'affichage de texte Freetype ne semble pas fournir de fonction de tracé de contour de caractère, ce qui nous a obligé à gérer nous-même ce style. |
|
|
| by Olivier Guillion | |
| |
|
La gestion du presse-papier X11 est décidément bien complexe. Nous avions pratiquement abandonné l'idée de l'utiliser, ne parvenant pas à faire fonctionner ce système correctement.
Mais les conseils avisés de Bubu42 (que nous remercions au passage) nous ont poussés à persister encore un peu. Ne pouvant trouver aucune documentation digne de ce nom, nous sommes allés à la pêche aux extraits de code, et nous avons pu repérer quelques pistes que nous avons alors explorées une à une. Et au bout de quelques heures, bingo !
Tout notre code était correct. Simplement, nous interrogions le système pour lui demander de nous fournir le contenu du presse-papier sous la forme d'une chaine de caractères standard. Et, selon l'application dans laquelle le "copier" avait été effectué, cela pouvait ne rien donner. Dans ces cas-là, il fallait réitérer la demande, mais en demandant le résultat sous la forme d'une chaine de caractères encodée en UTF8, format non connu par défaut dans X11.
Introuvable par nous-même, et non documenté. Le top.
Enfin, bon, avec cela, ça commence à fonctionner. Tout au moins sous Ubuntu/Gnome. |
|
|
| by Olivier Guillion | |
|
| |
|
Pas de grandes avancées aujourd'hui. Il est extrêmement difficile d'obtenir des informations précises et claires sur le fonctionnement interne de X11 et de Gnome, KDE ou autre.
Par exemple, X11 gère un presse-papier (pour le copier/coller). Dans Ubuntu (Gnome), il y a également un presse-papier. Sont-ils les mêmes ? Pas sûr.
Les premiers tests montrent qu'en utilisant le presse-papier X11, on parvient bien à récupérer du texte copié depuis le Terminal, par exemple, mais pas celui copié depuis Gedit.
Est-ce un problème de format, une initialisation qui manque, ou simplement Gnome gère-t-il un presse-papier indépendant de celui de X11?
Dans ce dernier cas, cela nous obligerait à gérer des accès au presse-papiers différent pour chacun des environnements possibles, ce qui complique sensiblement la chose. |
|
|
| by Olivier Guillion | |
|
| |
|
La structure d'Acam Winter est entièrement en place, il nous "suffit" maintenant de remplir les blancs, et d'écrire les fonctions manquantes.
La prochaine étape devrait consister à trouver un moyen de tracer les courbes de Bezier sans utiliser Cairo. En effet, même si cette bibliothèque est largement répandue, il est dommage de conserver une dépendance vers elle seulement pour le tracé de ces courbes.
Ensuite, nous avons fait des essais d'impression avec CUPS. A priori, si nous parvenons à écrire un export au format PostScript performant, nous devrions pouvoir utiliser CUPS pour envoyer ces données à l'imprimante. Cela ne résoudra cependant pas le problème de la boîte de sélection d'imprimante, de taille papier, et de mise en page (orientation, etc)
Nous avons le week-end pour réfléchir à tout cela. Les Linuxiens sont étonnamment silencieux sur tous ces points. Ils semblaient beaucoup plus nombreux lorsqu'il s'agissait de réclamer que pour nous aider à trouver des solutions, mais je suppose qu'il fallait nous y attendre.
Bon week-end à tous ! |
|
|
| by Olivier Guillion | |
|
| |
|
Nous commençons à voir un peu mieux les points qui nous poseront problème dans Acam Winter version Linux, et nous avons pu établir une liste.
Pour rappel, nous essayons de porter notre système d'interface sur Linux en utilisant le strict, mais alors strict minimum de fonctionnalités du système ou de bibliothèques optionnelles (seulement Xlib, freetype et ALSA pour le son).
Voici la liste des difficultés recensées jusqu'ici :
1- Gestion des touches "mortes" du clavier (pour l'instant, aucune solution en vue)
2- Sélecteur de fichier (pour l'instant, aucune solution en vue)
3- Sélecteur d'imprimante (pour l'instant, aucune solution en vue)
4- Tracé de courbes de Bezier (par un module "custom" inclus dans le programme?)
5- Impression (par génération de fichier PS puis envoi par CUPS ?)
6- Gestion du drag & drop (géré par Xlib?)
7- Gestion des entrées clavier complexes, par exemple en japonais (IME, géré par Xlib?)
8- Gestion du presse-papier (à vérifier, mais devrait être géré correctement par Xlib)
9- Icône de l'application (à vérifier, mais devrait être géré correctement par Xlib)
10 - Import & export d'images au format jpg, bmp, tiff... (bibliothèque-s- à inclure dans nos projets ?)
Il y en aura peut-être d'autres, mais pour l'instant, nous essayons de nous documenter et de savoir ce que nous pouvons faire avec ces 10 premier points. |
|
|
| by Olivier Guillion | |
| |
|
|
