Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Point de vue : L'adaptateur GTK-MUI
(Article écrit par Mathias Parnaudeau et extrait d'Amiga Power - décembre 2005)
|
|
GTK fait régulièrement parler de lui. En effet, cet ensemble d'outils graphiques est très utilisé pour créer
les interfaces de logiciels, sous Linux principalement, bien qu'il existe pour plusieurs autres systèmes.
Avec le gain de puissance et la dynamique apportés par nos machines PowerPC, l'envie d'avoir accès à de
nouvelles applications se fait plus grande. Ainsi, on parle souvent de The Gimp, Gnumeric, Gaim, AbiWord, Nvu, etc.
Voyons sur quoi repose GTK et quels moyens nous permettraient de l'obtenir, avant de voir ce que l'on peut
attendre de l'adaptateur (wrapper) GTK-MUI.
Qu'est-ce que GTK ?
GTK est une bibliothèque destinée, comme MUI ou ReAction, à construire et gérer des interfaces graphiques. A la
manière de Qt pour l'environnement KDE, ou MUI pour Ambient, GTK est pleinement et exclusivement utilisée pour le bureau Gnome.
Elle nécessite de nombreux autres modules pour pouvoir être compilée. Elle se repose en effet sur :
- Glib, le noyau, s'occupe des opérations bas niveau, pas encore en relation avec la partie graphique.
Il définit des types et structures de données (chaînes Unicode, listes, arbres...) et gère les événements,
processus, fichiers, timers...
- Pango, qui s'occupe de la manipulation du texte pour le rendu (gestion des polices, affichage) et l'internationalisation...
Sa recompilation nécessite apparemment libXft et libXrender.
- ATK, bibliothèque qui gère l'interfaçage de GTK pour rendre les programmes qui s'y conforment accessibles depuis l'extérieur.
- GDK : le "drawing kit" de GTK gère tout ce qui touche au dessin, ça concerne donc : les bitmaps, les images, les primitives
de dessin, les couleurs, les polices... La Glib est indissociable de cette bibliothèque (au moins pour les types).
- Les bibliothèques JPEG, PNG et TIFF, très connues désormais.
- FreeType pour la gestion des polices et dessin des caractères.
De plus amples informations peuvent être retrouvées directement depuis le site de GTK : www.gtk.org.
Un autre site intéressant regroupe par catégories de nombreux programmes faisant appel à GTK : www.gnomefiles.org.
C'est idéal pour trouver des outils à compiler avec l'adaptateur actuel afin de le faire progresser.
Pourquoi faire compliqué ?
Maintenant que l'on a une bonne vision de ce qu'est GTK, de ce qu'il permet de faire et de ce qu'il représente
(il tient quand même lieu de référence quand on parle de kits d'outils pour GUI, au côté Qt et WxWindows), nous pouvons
aborder la question du portage sur l'Amiga. Un portage réel nécessiterait déjà de se mettre à disposition un nombre
conséquent de bibliothèques, dont les moins spécifiques existent déjà ou seraient simples à porter. Les
soucis commencent avec la Glib (processus...) puis se poursuivent avec GDK et ses relations avec le système X11.
Bien sûr, un portage fidèle permettrait d'adapter n'importe quel logiciel. Mais bien que l'on veuille bénéficier des
logiciels en code source ouvert, souhaite-t-on réellement utiliser au quotidien toutes les applications Linux ? Oui pour
le confort et la reconnaissance extérieure, non pour l'identité et peut-être l'efficacité. Chacun se fera un avis sur
la question.
Alors comment obtenir GTK sur Amiga ? C'est sûr, GTK finira par être géré sur nos plates-formes. De nombreux OS
alternatifs (sans doute plus orientés Unix, certes) en ont déjà une implémentation. Le travail serait assez énorme
pour un portage complet, sans compter que pendant ce temps, GTK continuera d'évoluer ! Plusieurs approches sont
possibles. En fait, comme GTK se compose de plusieurs niveaux et il faut choisir l'API de celui semble le plus
cohérent à porter ou à écrire. Voici plusieurs possibilités :
- Porter la Glib et les bibliothèques de base, qui pourront servir pour d'autres projets. Au-dessus, on porte
GDK sachant que ce qui a été fait précédemment n'est pas suffisant puisque GDK a du code qui lui est propre. Après,
il faut soit avoir porté X11, soit avoir écrit un gestionnaire équivalent comme cela a été fait pour Windows
(ou Linux avec le tampon de trame). Enfin, il faut s'atteler à GTK et à nouveau adapter ce qui manque. L'aspect
Amiga qui en résulte est incertain... vu qu'à aucun moment on utilise les gadgets MUI par exemple ; je suppose
que tout n'est que dessin via GDK.
- Porter GDK en écrivant juste ce qui manque des bibliothèques qu'il utilise. A cette étape, on peut déjà mettre
du code spécifique Amiga, concernant les polices, les entrées-sorties, le rendu graphique, etc. Et rien n'empêche de
ne pas implémenter toutes les fonctions : j'ai par exemple vu que celles qui gèrent le glisser-déposer à bas niveau
ne sont pas utilisées dans GTK qui redéfinit les siennes ! Ça montre à quel point il est important de connaître déjà
très bien toute la chaîne avant de s'attaquer à un quelconque développement.
- Opter pour une adaptation de GTK (on part du haut) et on avance par étapes. Les gadgets des interfaces manipulent
en sous-main des objets graphiques MUI. On complexifie les sources à compiler et on tente de résoudre ce qui
bloque de manière à ce que cela s'intègre le mieux possible au code déjà existant. Et ainsi de suite. Bien
que cette méthode puisse manquer de visibilité, c'est celle qui permet sans doute une meilleure intégration
au système. Les sources officiels de Glib, GDK, GTK et autres sont ignorés, on interprète ce que doit faire
chaque fonction et on y place du code neuf : c'est cela réaliser un adaptateur, voie choisie par les développeurs
du projet GTK-MUI. Cette approche permet de progresser mais on peut très bien tomber sur quelque chose qui
remettre tout ce qui a été fait en cause.
Quelle est la meilleure manière, s'il en existe vraiment une, pour porter GTK ? Déjà, comme pour n'importe quel
projet informatique, il faut se demander ce qu'on veut vraiment faire et obtenir. Pourquoi GTK ? Est-ce pour
porter un maximum d'applications ou bien pour des besoins ponctuels pour lesquels seule une partie des fonctions
de GTK est nécessaire ?
Et encore, à chaque fois que le portage d'un logiciel avec interface graphique est évoqué, on en vient à se
demander s'il vaut mieux porter le kit d'outils ou bien développer l'équivalent en natif (MUI, ReAction) comme
cela a été fait dans Bourriquet. Seuls les traitements sont conservés et il reste à faire les connexions avec l'interface.
Au sujet de l'adaptateur
L'adaptateur est issu d'une cagnotte AROS qui se limite à un certain nombre de fonctions. Il faut bien comprendre
que c'est dans cet objectif que le projet est mené. Pourquoi ces fonctions ? Il faudrait contacter les auteurs
pour savoir. Et la différence entre cette gestion partielle de GTK et une adaptation complète est de taille !
C'est pourquoi il ne faut pas croire que l'on est en train d'accéder à GTK. Ils ont sans doute choisi la facilité
(toute relative) en adaptant quelques fonctions mais ça limitera les applications qui pourront être portées.
Ce qui semblait être une voie de garage (approche trop limitante) pourrait bien être la manière d'obtenir le plus
vite un GTK incomplet mais plus véloce et qui sera parfaitement intégré au système avec le choix de MUI. Le risque
est de constater à un moment une impossibilité de poursuivre à cause d'une conception au jour le jour. Mais les
connaissances acquises seront primordiales pour redéfinir un projet plus ambitieux.
Certains ont manifesté des craintes de voir les développeurs se mettre à utiliser GTK au lieu de MUI par exemple.
Je crois qu'on peut les écarter tout de suite quand on connaît les avantages de MUI en termes de conception objet,
de lisibilité et de logique. Ceci n'engage que moi et j'avoue ne pas être un habitué de GTK.
Il va falloir suivre de près cet adaptateur et mettre le nez dans les sources pour voir comment cela a été orienté.
Et plus que le choix d'un adaptateur par rapport à un portage complet, je pense que c'est de son implémentation que
dépendra son succès. Il faut voir s'il y a une réflexion derrière pour envisager la suite de la cagnotte
ou si les fonctions ont été recodées d'après l'action que chacune a à remplir. C'est plus l'approche choisie
pour l'adaptateur qui déterminera le potentiel du projet et les probabilités de voir des applications conséquentes en GTK.
|
