From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA12803 for caml-redistribution; Fri, 23 Oct 1998 19:47:14 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA24931 for ; Mon, 19 Oct 1998 09:34:06 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA15863 for ; Mon, 19 Oct 1998 09:34:04 +0200 (MET DST) Received: from localhost (safran.kurims.kyoto-u.ac.jp [130.54.16.91]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with ESMTP id QAA24581; Mon, 19 Oct 1998 16:33:51 +0900 (JST) To: Emmanuel.Dorlet@cea.fr, caml-list@pauillac.inria.fr Subject: Re: Connection à une IHM en IlogViews In-Reply-To: Your message of "Mon, 12 Oct 1998 11:07:46 +0200" <3621C6E2.DEF69281@soleil.serma.cea.fr> References: <3621C6E2.DEF69281@soleil.serma.cea.fr> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <19981019163422A.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 19 Oct 1998 16:34:22 +0900 From: Jacques GARRIGUE X-Dispatcher: imput version 980905(IM100) Content-Transfer-Encoding: quoted-printable Sender: weis From: Emmanuel Dorlet > 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 pou= r > réaliser des IHM d'assez haut niveau. > Tcl-Tk n'est pas, nous semble-t-il, à un niveau suffsant pour le typ= e > 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-existe= r > 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 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 plu= s > 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 JG