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
|
|
|
|
Test de User Interface Kit 1.4
(Article écrit par David Scrève et extrait d'Amiga News - février 1994)
|
|
Depuis environ un an, un certain type d'outils de développement est à la mode :
il s'agit des outils d'aide à la conception d'interfaces utilisateur.
En effet, avec MUI (Magic User Interface) et UIK (User Interface Kit),
les méthodes de conception ont bien changé, et on est bien loin des produits DP
comme l'isup.library qui ne constituait qu'un simple enrichissement d'Intuition.
Parmi ces nouveaux produits, UIK de Jean-Michel Forgeas est le seul qui soit commercial
et également celui qui semble être à l'origine de ce mouvement lancé il y a environ un an.
Toutefois, testé il y a un
an par Xavier Leclercq, UIK a beaucoup évolué depuis, et sa comparaison avec des
produits comme MUI semble aujourd'hui déplacée, même si elle est encore pratiquée sur
Usenet. Je vais donc vous rappeler certains aspects généraux de UIK, pour ensuite vous
présenter ce qu'apporte la version 1.40 par rapport à la 1.1 qui avait été testée.
Notion d'objets
UIK est basé sur la POO (programmation orientée objet), et c'est ce qui fait
sa puissance et le place technologiquement en avant face aux outils de développement disponibles
sur Amiga. Intuitivement, pour UIK, un objet est une entité capable de réaliser une
tâche bien déterminée. Elle dispose pour cela de toutes les fonctions et variables nécessaires
à son fonctionnement et propose parfois au programmeur une partie de ses fonctions, alors
dites "publiques".
L'intérêt de la programmation par objet est alors que chaque objet peut travailler seul,
sans aide extérieure. On n'a donc pas besoin de savoir comment il fonctionne. Par exemple,
sous UIK, l'objet 8SVX permet de lire en "direct-to-disk" un fichier son IFF-8SVX.
Eh bien, vous n'aurez pas à vous soucier de la manière de lire un fichier IFF-8SVX
ou de faire jouer un son par l'audio.device : c'est le travail de l'objet.
Un programme par objets se résume donc à un simple assemblage d'objets qui vont travailler
en parallèle, chacun dans son coin. Pour les assembler, on constituera alors un arbre,
avec un objet racine (root) et toutes une série d'objets fils les uns des autres.
On peut alors comparer cela à un arbre généalogique, puisqu'un objet fils hérite de
certains attributs de son père. Ainsi, sous UIK, si une fenêtre a pour fils un
objet bouton, ce dernier héritera de la même police que son père, sauf avis contraire
bien sûr.
Cette structure en arbre apporte également beaucoup de souplesse au niveau de la gestion de
la mémoire. Ainsi, avec UIK, l'objet situé à la racine s'appelle toujours "UIK".
Si vous agissez sur cet objet, la plupart de vos interventions se répercuteront sur
tous les objets fils de l'arborescence. Ainsi, vous pourrez arrêter, démarrer ou
désallouer une infinité de fenêtres et écrans en n'agissant que sur l'objet "UIK".
En fait, la POO met en oeuvre beaucoup plus de notions, mais UIK se charge pour la
plupart de les gérer à votre place et rend leur connaissance non nécessaire.
Moteur d'objets
Le principal problème de la plupart des langages à objets classiques comme le C++
de chez SAS (qui devrait être commercialisé à l'heure où vous lisez ces lignes),
est qu'il faut faire travailler les objets soi-même : chaque objet possède ses
propres fonctions, mais c'est le programmeur qui y fait directement appel,
et non pas l'objet lui-même.
C'est là que la puissance de UIK apparaît. UIK est un moteur d'objets. Il
va donc se charger de faire travailler les différents objets, sans intervention
du programmeur. Par exemple, si vous avez une fenêtre qui a été retaillée, UIK
va dire à chacun des gadgets de se retailler automatiquement, sans intervention du
programmeur.
Bien entendu, ce dernier pourra bien sûr être informé de l'événement.
De même, pour un bouton booléen, il suffit d'indiquer les fonctions à exécuter
lorsque l'utilisateur clique dessus et UIK fera l'appel au moment opportun.
Cette démarche peut bien entendue être appliquée à toute sorte d'objets :
gadgets, AppIcon (avec l'objet AppWBench), ARexx, etc.
Le paquetage UIK
Après toute cette théorie, revenons sur terre. Concrètement, UIK
est constitué d'une bibliothèque d'environ 70 ko et d'une série d'objets
sur disque. La bibliothèque contient toute une série de fonctions pour
la gestion du moteur d'objets ainsi qu'un ensemble de fonctions qui simplifient
la vie du programmeur : gestion dynamique de chaînes de caractères avec couper-coller,
liste chaîné, indexée avec de puissantes fonctions de balayage.
Des objets au caractère primordial sont également dans la bibliothèque.
Les autres objets sont sur disque. Toutefois, leur accès via UIK
se fait par la même fonction UIK_AddObject(). L'intérêt est surtout qu'une
bibliothèque d'objets est facilement constituable. Ainsi, actuellement
trois disquettes d'objets sont déjà disponibles dans le commerce.
Le véritable intérêt de la programmation objet est atteint, à savoir
ne pas reprogrammer ce qui l'a déjà été par d'autres.
Les objets livrés avec UIK couvrent de nombreux aspects de la programmation :
lecture de fichiers ILBM, 8SVX et SMUS, mise en place d'un port ARexx,
requête de fichiers, requête de polices, et bien sûr tous les objets liés
à une interface graphique (glissière, bouton, toggle, flèche haut,
bas, droite, gauche, bouton annuler et OK...). En fait, la création d'objets
est infinie, puisqu'un objet peut être créé à partir des autres pour en faire
un super objet.
Enfin, parmi les avantages non cités ci-dessus, on peut donner le retaillage
automatique des boutons dans une fenêtre lorsque la taille de cette dernière
est modifiée, et le respect parfait du multitâche. Des tests sérieux ont été
effectués et il est apparu que MUI, le concurrent direct de UIK
en matière d'interface graphique, était d'une lenteur qui frise l'insupportable.
De nombreux développeurs vous diront aussi que, professionnellement,
UIK convient mieux que MUI parce qu'il maintient la compatibilité 1.3, tout
en proposant les avantages du système 3.0 comme la localisation.
Comme le fait souvent remarquer Philippe Ducalet, UIK est également prévu pour
les handicapés puisqu'il propose de nombreux modes de pilotage pour l'interface.
IPUIK
Nous allons maintenant voir la grande nouveauté de la version 1.40.
Outre un objet "Palette" qui s'adapte au système 3.0 et au jeu de composants
AGA et quelques fonctions qui ne signifieraient pas grand-chose pour vous,
la grande nouveauté reste IPUIK (Inter Process UIK).
IPUIK est la réponse à certains problèmes qui se révèlent parfois complexes
à résoudre en une seule tâche. IPUIK c'est l'exploitation à la fois du multitâche de
l'Amiga, et du côté d'UIK qui fait que ce n'est pas simplement un gestionnaire
d'interface graphique. Ainsi, dans le cas d'une application en plusieurs programmes,
l'utilisateur peut ne lancer que les fonctions qui l'intéressent,
chaque programme se chargeant d'une tâche précise, comme le fait un objet UIK,
mais en parallèle avec les autres.
Le problème est que souvent on ne peut travailler proprement sur les données
d'un autre programme sans avoir recours à des processus complexes (pour le
non initié) de protection de la mémoire comme les sémaphores, et qu'il n'est
pas immédiat de faire partager une même fonction à plusieurs programmes (nécessité
d'écrire du code réentrant).
Or, la programmation orientée objet d'UIK force souvent le programmeur à écrire
du code réentrant, partageable entre plusieurs programmes. Un des problèmes est
donc résolu. C'est là qu'intervient IPUIK. Partant du principe que tout est objet,
y compris les zones mémoire qui peuvent être allouées avec l'objet mémoire,
IPUIK est une surcouche d'UIK qui permet de travailler sur les objets d'une
tâche distante. On peut donc greffer une interface graphique sur une application qui
n'en possède pas à l'origine, faire des allocations mémoire,
allouer des signaux ou toute autre forme de données qu'il est en théorie impossible
de faire à la place du programme d'accueil.
Plus fort encore, on peut même dire à un bouton de la tâche distante d'appeler, quand
il sera enfoncé, une fonction qui fait partie d'un programme externe !
Les avantages sont nombreux : IPUIK s'applique à toutes les fonctions de la bibliothèque
et la syntaxe est la même que pour les fonctions standard d'UIK, à deux exceptions
près : il faut rajouter "IP" devant le nom de la fonction, et il faut préciser la tâche sur
laquelle on souhaite travailler avant les autres paramètres. En fait, malgré toutes les
apparences, la quantité de fonctions de la bibliothèque n'a pas doublé :
les fonctions ne sont pas en double.
On peut alors créer des correctifs de logiciels très simplement,
et de façon transparente pour celui qui reçoit de nouveaux objets.
Conclusion
Aujourd'hui, UIK est bien plus qu'une simple surcouche d'Intuition. De
par les objets qu'il propose et avec IPUIK, c'est beaucoup plus qu'une
interface graphique. C'est tout simplement une interface avec l'extérieur
qui comprend à la fois l'utilisateur, mais aussi les autres programmes qui
fonctionnent en même temps et toutes les ressources du système.
Il faut dire qu'IPUIK a fortement été conditionné par le développement de l'objet
IPOL (Inter Process Object Link) que j'ai conçu et qui permet avec simplicité,
d'échanger des données entre programmes sans connaissance du système. On peut
même construire simplement des échanges dynamiques inter applications en quatre
ou cinq fonctions : le protocole a été défini.
De même, IPUIK permet de créer un objet "Process" très simplement. Ainsi,
vous créé un processus fils comme un objet, qui se terminera en même temps
que le programme père qui en reste le maître.
Voilà, je pense que Jean-Michel Forgeas est allé plus loin que MUI avec UIK
en proposant avant un outil de productivité. La meilleure preuve de la
fiabilité de son produit est peut-être qu'il l'utilise chaque jour pour
ses développements, et je fais la même chose. Les applications grand public arrivent
d'ailleurs bientôt et devraient inonder le marché, étant donné qu'UIK permet de
diviser le temps de développement par deux.
Nom : User Interface Kit 1.4.
Développeur : Jean-Michel Forgeas.
Genre : programmation.
Date : 1993.
Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire.
Licence : commercial.
Prix : 550 FF.
|
|
