Re: Connection à une IHM en IlogViews

[Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>]

From: Emmanuel Dorlet <dorlet@soleil.serma.cea.fr>

> Nous allons devoir réaliser dans un proche avenir des IHM à
> l'application de pilotage de code couplage
> de codes du CEA-DRN (ISAS).
> Ilog Views a été retenu par la DRN comme le produit industriel pour
> réaliser des IHM d'assez haut niveau.
> Tcl-Tk n'est pas, nous semble-t-il, à un niveau suffsant pour le type
> d'interface que l'on sera amené à
> réalsier à terme.

J'ai regarde' moi-meme les differentes interfaces graphiques
disponibles, et je penses qu'avant de faire un choix il faut voir le
probleme dans son ensemble.

Soit, Tcl/Tk n'est pas la panacee. Il y a parfois des choses
difficiles a` exprimer. Mais il y a aussi des avantages majeurs, comme
la grande facilite' de developpement, ou la possibilite' d'utilisation
sur des systemes varies. La facilite' pour l'utilisateur de changer
l'apparence (choix des polices, etc...) ne me parait pas a` negliger.
Tout ca me semble plus difficile dans d'autres interfaces.

A remarquer aussi, Tcl/Tk est lui-meme extensible (en C), et CamlTk
(ainsi que LablTk) peut facilement tirer parti de ces extensions.

Interfacer une autre bibliotheque, en creant des stubs C, n'est pas
impossible. Je l'ai fait recemment a` grande echelle pour interfacer
completement OpenGL. Malheureusement, les interfaces graphiques
utilisent beaucoup de structures de donnees (contrairement a` OpenGL
qui n'utilise que des donnees simples), ce qui rend beaucoup plus
complexe l'interfacage.

Pour ces deux raisons, meme si ca peut paraitre un peu decourageant,
je deconseillerai de se lancer dans la creation d'une telle interface,
a` moins d'etre tres competent en OCaml. Comme le fait remarquer
Xavier Leroy, un outil de generation automatique pourrait changer cet
etat de fait, mais a` l'heure actuelle il me semble que le ratio
cout/performance est mauvais. Pire, si elle n'est pas concue avec
assez de soin, une telle interface risque d'etre tres rapidement
abandonnee.

> Quel serait à votre avis la bonne approche:
>     - 1) édition de lien Ocaml/Views pour un exécutable:
>             - sans Top-level (mais alors pas de moyen d'enrichir
> dynamiquement l'application, ce
>                 qui est un besoin fort)

Comme quelqu'un l'a deja` dit, grace au module Dynlink il est possible
d'etendre un executable sans toplevel. MMM est un exemple d'une telle
application.

>             - avec Top-level, mais dans ce cas comment faire co-exister
> la boucle X et l'interprète, et où serait saisie
>                 les entréees clavier de l'utilisateur

C'est bien sur plus convivial. Jun Furuse <Jun.Furuse@inria.fr> avait
commence' a` travailler la-dessus avec CamlTk, et obtenu de bons
resultats. L'idee etait d'utiliser les threads caml pour appeler Tk
depuis un thread, et utiliser un autre thread pour le toplevel. Il
n'est malheureusement pas alle' jusqu'au bout des problemes
techniques, mais comme l'ecrit Xavier dans son mail, ca marchait
grosso-modo parce que le changement de thread ne peut se faire
qu'apres retour a` la boucle Caml --pas de probleme de re-entrance.

> Outre ce problème d'architecture, peux-t-on envisager un mapping plus
> profond avec IlogViews
> (API des classes Views en objets Ocaml par exemple)?
> Ce qui a été fait avec TK est-il de même nature?

C'est un peu ce a` quoi j'ai repondu dans la premiere partie de mon
mail. Si vous voulez ecrire l'interface utilisateur en C, et la
presenter a` Caml comme un petit nombre de fonctions, c'est tres
faisable et pas tres difficile, mais je crois que CamlTk ou LablTk
donneront un resultat plus satisfaisant au niveau de l'integration.

Un mapping complet de l'API est une tache lourde qui demande a` etre
automatisee, et aussi qui pose de serieux problemes de qualite'.

Cordialement,

	Jacques Garrigue
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>