J'ai un daemon =E9crit en java qui tourne sur un serveur Unix (lanc=E9
depuis un compte Admin)
Ce daemon doit r=E9pondre en socket =E0 des requetes provenant d'autres
users logu=E9s sur le m=EAme serveur (via une =E9mulation X; chacun a son
propre display).
Pour r=E9pondre =E0 ces requetes, il est parfois n=E9cessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lanc=E9 requette
(il l'aura pass=E9 lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de g=E9rer plusieurs DISPLAY au
sein d'une m=EAme JVM ?)
2/ quelqu'un sait-il comment faire ?
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé depuis un compte Admin) Ce daemon doit répondre en socket à des requetes provenant d'autres users logués sur le même serveur (via une émulation X; chacun a son propre display). Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une IHM (swing). Il faut donc que je puisse (au sein du thread qui traite cette requette) positionner le display du user qui a lancé requette (il l'aura passé lors de sa connection au daemon). 1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au sein d'une même JVM ?) 2/ quelqu'un sait-il comment faire ?
Merci d'avance
Je ne suis pas sur de comprendre. Le serveur ouvre une fenetre? Je sais pas si c'est une bonne idee.
Le plus simple serait, je pense, de faire une appli cliente separee. Dans, ce cas, le client ouvre une connexion vers le serveur et le serveur repond sur cette connexion dans un protocole precis. Apres, il faut bien preciser le protocole, mais suivant les besoins, ca peut tres bien etre un protocole connu genre HTTP (qui evite d'avoir a ecrire un client) ou un protocole maison qui sera potentiellement plus adapte mais qu'il faudra creer et implementer dans un client en plus du serveur. J'espere que ca repond a la question.
rdeman@gmail.com wrote:
Bonjour,
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé
depuis un compte Admin)
Ce daemon doit répondre en socket à des requetes provenant d'autres
users logués sur le même serveur (via une émulation X; chacun a son
propre display).
Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lancé requette
(il l'aura passé lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au
sein d'une même JVM ?)
2/ quelqu'un sait-il comment faire ?
Merci d'avance
Je ne suis pas sur de comprendre.
Le serveur ouvre une fenetre? Je sais pas si c'est une bonne idee.
Le plus simple serait, je pense, de faire une appli cliente separee.
Dans, ce cas, le client ouvre une connexion vers le serveur et le
serveur repond sur cette connexion dans un protocole precis.
Apres, il faut bien preciser le protocole, mais suivant les besoins, ca
peut tres bien etre un protocole connu genre HTTP (qui evite d'avoir a
ecrire un client) ou un protocole maison qui sera potentiellement plus
adapte mais qu'il faudra creer et implementer dans un client en plus du
serveur.
J'espere que ca repond a la question.
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé depuis un compte Admin) Ce daemon doit répondre en socket à des requetes provenant d'autres users logués sur le même serveur (via une émulation X; chacun a son propre display). Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une IHM (swing). Il faut donc que je puisse (au sein du thread qui traite cette requette) positionner le display du user qui a lancé requette (il l'aura passé lors de sa connection au daemon). 1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au sein d'une même JVM ?) 2/ quelqu'un sait-il comment faire ?
Merci d'avance
Je ne suis pas sur de comprendre. Le serveur ouvre une fenetre? Je sais pas si c'est une bonne idee.
Le plus simple serait, je pense, de faire une appli cliente separee. Dans, ce cas, le client ouvre une connexion vers le serveur et le serveur repond sur cette connexion dans un protocole precis. Apres, il faut bien preciser le protocole, mais suivant les besoins, ca peut tres bien etre un protocole connu genre HTTP (qui evite d'avoir a ecrire un client) ou un protocole maison qui sera potentiellement plus adapte mais qu'il faudra creer et implementer dans un client en plus du serveur. J'espere que ca repond a la question.
TestMan
Bonjour,
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ? Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM (process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs simmultanement, car autant je suis sur que le multidisplay marche nickel et depuis des décénies avec du multiprocess autant je doute que le multidisplay marche avec du multithread pour un même processus sauf à trouver une "bidouille".
Je pense ainsi qu'un contournement vous sera nécessaire, d'où ma question du début ...
A+ TM
Bonjour,
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé depuis un compte Admin) Ce daemon doit répondre en socket à des requetes provenant d'autres users logués sur le même serveur (via une émulation X; chacun a son propre display). Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une IHM (swing). Il faut donc que je puisse (au sein du thread qui traite cette requette) positionner le display du user qui a lancé requette (il l'aura passé lors de sa connection au daemon). 1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au sein d'une même JVM ?) 2/ quelqu'un sait-il comment faire ?
Merci d'avance
Bonjour,
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir
? Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM
(process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs
simmultanement, car autant je suis sur que le multidisplay marche nickel
et depuis des décénies avec du multiprocess autant je doute que le
multidisplay marche avec du multithread pour un même processus sauf à
trouver une "bidouille".
Je pense ainsi qu'un contournement vous sera nécessaire, d'où ma
question du début ...
A+
TM
Bonjour,
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé
depuis un compte Admin)
Ce daemon doit répondre en socket à des requetes provenant d'autres
users logués sur le même serveur (via une émulation X; chacun a son
propre display).
Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une
IHM (swing). Il faut donc que je puisse (au sein du thread qui traite
cette requette) positionner le display du user qui a lancé requette
(il l'aura passé lors de sa connection au daemon).
1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au
sein d'une même JVM ?)
2/ quelqu'un sait-il comment faire ?
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ? Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM (process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs simmultanement, car autant je suis sur que le multidisplay marche nickel et depuis des décénies avec du multiprocess autant je doute que le multidisplay marche avec du multithread pour un même processus sauf à trouver une "bidouille".
Je pense ainsi qu'un contournement vous sera nécessaire, d'où ma question du début ...
A+ TM
Bonjour,
J'ai un daemon écrit en java qui tourne sur un serveur Unix (lancé depuis un compte Admin) Ce daemon doit répondre en socket à des requetes provenant d'autres users logués sur le même serveur (via une émulation X; chacun a son propre display). Pour répondre à ces requetes, il est parfois nécessaire d'ouvrir une IHM (swing). Il faut donc que je puisse (au sein du thread qui traite cette requette) positionner le display du user qui a lancé requette (il l'aura passé lors de sa connection au daemon). 1/ est-ce possible ? (est-il possible de gérer plusieurs DISPLAY au sein d'une même JVM ?) 2/ quelqu'un sait-il comment faire ?
Merci d'avance
Vincent Cantin
Ne serait-il pas plus simple que ce ne soit pas le demon qui fasse l'affichage, mais un client ?
Vincent
Ne serait-il pas plus simple que ce ne soit pas le demon qui fasse
l'affichage, mais un client ?
Ne serait-il pas plus simple que ce ne soit pas le demon qui fasse l'affichage, mais un client ?
Vincent
rdeman
Voici une description + détaillée de l'architecture : le but de ce daemon est de centraliser les echanges avec une appli web (echanges en RMI). Le Daemon est donc un client pour cette appli web (serveur J2EE). Sur le serveur Unix, plusieurs utilisateurs sont loggés (via une emulation X), chacun avec son propre login, sa propre ip (celle du terminal X d'ou est lancée l'émulation) et donc son propre DISPLAY. L'utilisateur lance sur ce serveur une application de calcul. Il en existe plusieurs. Elles sont écrites en Perl, en C++ ou autre. Ces applications de calcul doivent maintenant s'interfacer avec l'appli web pour sélectionner ou stocker des données (jusqu'à maintenant, les données étaient stockées sur le file system, maintenant, elles doivent être stockées dans l'appi web). Pour celà, il faut monter une IHMs, par exemple pour naviguer dans la structure de folders de l'appli web. - Premiere solution : développer un service web (type SOAP) côté de l'appli web. Chacune des applications de calcul devrait donc mettre à jour ses IHM pour utiliser cette API (en tant que client de ce service web) de bas niveau (par exemple, une API pour naviguer dans la structure de folders de l'appli web). - Deuxieme solution qui me semble nettement plus judicieuse : déployer un daemon qui offre 2 services : une API de haut niveau (selectionner une donnée ou un folder) en socket (utilisable depuis n'importe quel langage) et des écrans déjà tout prêts (pour aller naviguer dans la structure de folders). Cela évite de développer le même type d'écran dans chacune des applications de calcul. Ils sont développés une fois pour toute dans le daemon java. Autres avantages, le daemon est lancé une fois pour toute; il peut optimiser les accès au serveur web et par exemple conserver des données en cache, ... Je pourrais lancer une instance de ce daemon pour chaque utilisateur connecté au serveur unix, mais vu ce que bouffe une JVM, je préfèrerai le lancer une seule fois. J'ai donc besoin de gérer au sein de la même JVM le display de plusieurs utilisateurs.
Pour info, j'ai trouvé sur SDN un bug qui correspond à mon besoin (http://bugs.sun.com/bugdatabase/view_bug.do?bug_idF70851 ) , mais il est resté ouvert depuis 2002 ...
J'espère que c'est plus clair cette fois ...
Voici une description + détaillée de l'architecture : le but de ce
daemon est de centraliser les echanges avec une appli web (echanges en
RMI). Le Daemon est donc un client pour cette appli web (serveur J2EE).
Sur le serveur Unix, plusieurs utilisateurs sont loggés (via une
emulation X), chacun avec son propre login, sa propre ip (celle du
terminal X d'ou est lancée l'émulation) et donc son propre DISPLAY.
L'utilisateur lance sur ce serveur une application de calcul. Il en
existe plusieurs. Elles sont écrites en Perl, en C++ ou autre. Ces
applications de calcul doivent maintenant s'interfacer avec l'appli web
pour sélectionner ou stocker des données (jusqu'à maintenant, les
données étaient stockées sur le file system, maintenant, elles
doivent être stockées dans l'appi web). Pour celà, il faut monter
une IHMs, par exemple pour naviguer dans la structure de folders de
l'appli web.
- Premiere solution : développer un service web (type SOAP) côté de
l'appli web. Chacune des applications de calcul devrait donc mettre à
jour ses IHM pour utiliser cette API (en tant que client de ce service
web) de bas niveau (par exemple, une API pour naviguer dans la
structure de folders de l'appli web).
- Deuxieme solution qui me semble nettement plus judicieuse : déployer
un daemon qui offre 2 services : une API de haut niveau (selectionner
une donnée ou un folder) en socket (utilisable depuis n'importe quel
langage) et des écrans déjà tout prêts (pour aller naviguer dans la
structure de folders). Cela évite de développer le même type
d'écran dans chacune des applications de calcul. Ils sont développés
une fois pour toute dans le daemon java. Autres avantages, le daemon
est lancé une fois pour toute; il peut optimiser les accès au serveur
web et par exemple conserver des données en cache, ...
Je pourrais lancer une instance de ce daemon pour chaque utilisateur
connecté au serveur unix, mais vu ce que bouffe une JVM, je
préfèrerai le lancer une seule fois. J'ai donc besoin de gérer au
sein de la même JVM le display de plusieurs utilisateurs.
Pour info, j'ai trouvé sur SDN un bug qui correspond à mon besoin
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670851
) , mais il est resté ouvert depuis 2002 ...
Voici une description + détaillée de l'architecture : le but de ce daemon est de centraliser les echanges avec une appli web (echanges en RMI). Le Daemon est donc un client pour cette appli web (serveur J2EE). Sur le serveur Unix, plusieurs utilisateurs sont loggés (via une emulation X), chacun avec son propre login, sa propre ip (celle du terminal X d'ou est lancée l'émulation) et donc son propre DISPLAY. L'utilisateur lance sur ce serveur une application de calcul. Il en existe plusieurs. Elles sont écrites en Perl, en C++ ou autre. Ces applications de calcul doivent maintenant s'interfacer avec l'appli web pour sélectionner ou stocker des données (jusqu'à maintenant, les données étaient stockées sur le file system, maintenant, elles doivent être stockées dans l'appi web). Pour celà, il faut monter une IHMs, par exemple pour naviguer dans la structure de folders de l'appli web. - Premiere solution : développer un service web (type SOAP) côté de l'appli web. Chacune des applications de calcul devrait donc mettre à jour ses IHM pour utiliser cette API (en tant que client de ce service web) de bas niveau (par exemple, une API pour naviguer dans la structure de folders de l'appli web). - Deuxieme solution qui me semble nettement plus judicieuse : déployer un daemon qui offre 2 services : une API de haut niveau (selectionner une donnée ou un folder) en socket (utilisable depuis n'importe quel langage) et des écrans déjà tout prêts (pour aller naviguer dans la structure de folders). Cela évite de développer le même type d'écran dans chacune des applications de calcul. Ils sont développés une fois pour toute dans le daemon java. Autres avantages, le daemon est lancé une fois pour toute; il peut optimiser les accès au serveur web et par exemple conserver des données en cache, ... Je pourrais lancer une instance de ce daemon pour chaque utilisateur connecté au serveur unix, mais vu ce que bouffe une JVM, je préfèrerai le lancer une seule fois. J'ai donc besoin de gérer au sein de la même JVM le display de plusieurs utilisateurs.
Pour info, j'ai trouvé sur SDN un bug qui correspond à mon besoin (http://bugs.sun.com/bugdatabase/view_bug.do?bug_idF70851 ) , mais il est resté ouvert depuis 2002 ...
J'espère que c'est plus clair cette fois ...
Rémy
"TestMan" a écrit dans le message de news: 44251f39$0$7093$
Bonjour,
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ? Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM (process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs simmultanement, car autant je suis sur que le multidisplay marche nickel et depuis des décénies avec du multiprocess autant je doute que le multidisplay marche avec du multithread pour un même processus sauf à trouver une "bidouille".
Si,si aucun problème dans le principe. J'ai codé plusieurs programmes multi-display.
Le tout est de ne pas utiliser la variable DISPLAY justement, mais de passer le nom du display au moment où l'on fait le XOpenDisplay. (en fait, ce n'est que lorsqu'on fait XOpenDisplay() sans paramètre que la variable DISPLAY est recherchée).
Notez que le XOpenDisplay est généralement encapsulé dans la librairie graphique utilisée (Xt, Motif, ...) et qu'il est possible que certaines ne fournissent pas l'API pour renseigner le display lors de la connexion.
Par contre est-ce possible depuis un programme Java ? Je n'ai jamais essayé. Il faudrait rechercher dans le documentation Swing (en l'occurence) s'il y a un moyen autre que DISPLAY de spécifier le display...
Rémy
Rémy
"TestMan" <none@example.com> a écrit dans le message de news:
44251f39$0$7093$626a54ce@news.free.fr...
Bonjour,
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ?
Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM
(process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs
simmultanement, car autant je suis sur que le multidisplay marche nickel
et depuis des décénies avec du multiprocess autant je doute que le
multidisplay marche avec du multithread pour un même processus sauf à
trouver une "bidouille".
Si,si aucun problème dans le principe. J'ai codé plusieurs programmes
multi-display.
Le tout est de ne pas utiliser la variable DISPLAY justement, mais de passer
le nom du display au moment où l'on fait le XOpenDisplay. (en fait, ce n'est
que lorsqu'on fait XOpenDisplay() sans paramètre que la variable DISPLAY est
recherchée).
Notez que le XOpenDisplay est généralement encapsulé dans la librairie
graphique utilisée (Xt, Motif, ...) et qu'il est possible que certaines ne
fournissent pas l'API pour renseigner le display lors de la connexion.
Par contre est-ce possible depuis un programme Java ? Je n'ai jamais essayé.
Il faudrait rechercher dans le documentation Swing (en l'occurence) s'il y a
un moyen autre que DISPLAY de spécifier le display...
"TestMan" a écrit dans le message de news: 44251f39$0$7093$
Bonjour,
Pouvez-vous nous en dire plus sur les besoins associés à l'IHM à ouvrir ? Qui l'utilisera ? Quel but ? Quel type d'interraction ?
Sauf erreur, la variable DISPLAY de Java est celle du processus de la VM (process UNIX), il me parrait donc difficile d'avoir plusieurs valeurs simmultanement, car autant je suis sur que le multidisplay marche nickel et depuis des décénies avec du multiprocess autant je doute que le multidisplay marche avec du multithread pour un même processus sauf à trouver une "bidouille".
Si,si aucun problème dans le principe. J'ai codé plusieurs programmes multi-display.
Le tout est de ne pas utiliser la variable DISPLAY justement, mais de passer le nom du display au moment où l'on fait le XOpenDisplay. (en fait, ce n'est que lorsqu'on fait XOpenDisplay() sans paramètre que la variable DISPLAY est recherchée).
Notez que le XOpenDisplay est généralement encapsulé dans la librairie graphique utilisée (Xt, Motif, ...) et qu'il est possible que certaines ne fournissent pas l'API pour renseigner le display lors de la connexion.
Par contre est-ce possible depuis un programme Java ? Je n'ai jamais essayé. Il faudrait rechercher dans le documentation Swing (en l'occurence) s'il y a un moyen autre que DISPLAY de spécifier le display...
Rémy
Rémy
rdeman
Ben justement, mon pb est que je ne trouve pas l'équivalent de la methode XOpenDisplay dans l'API java. - existe-t-il et c'est moi qu ne l'ai pas trouvé ? - s'il n'existe pas, et si je dois développer un conposant en C pour y accéder, cela implique-t-il que je dois développer mes IHMs en C également (donc finallement, mon Daemon tout entier) ? J'aimerais développer les IHMs en java car celà m'assure une meilleure portabilité / réutilisabilité du code.
Ben justement, mon pb est que je ne trouve pas l'équivalent de la
methode XOpenDisplay dans l'API java.
- existe-t-il et c'est moi qu ne l'ai pas trouvé ?
- s'il n'existe pas, et si je dois développer un conposant en C pour y
accéder, cela implique-t-il que je dois développer mes IHMs en C
également (donc finallement, mon Daemon tout entier) ?
J'aimerais développer les IHMs en java car celà m'assure une
meilleure portabilité / réutilisabilité du code.
Ben justement, mon pb est que je ne trouve pas l'équivalent de la methode XOpenDisplay dans l'API java. - existe-t-il et c'est moi qu ne l'ai pas trouvé ? - s'il n'existe pas, et si je dois développer un conposant en C pour y accéder, cela implique-t-il que je dois développer mes IHMs en C également (donc finallement, mon Daemon tout entier) ? J'aimerais développer les IHMs en java car celà m'assure une meilleure portabilité / réutilisabilité du code.
Rémy
a écrit dans le message de news:
Ben justement, mon pb est que je ne trouve pas l'équivalent de la methode XOpenDisplay dans l'API java. - existe-t-il et c'est moi qu ne l'ai pas trouvé ?
Il semble en effet que Swing sait utiliser plusieurs écrans sur une même machine, mais pas des écrans distants.
C'est logique dans la mesure où cette fonctionnalité ne peut pas être assurée sur tous les OS (Windows par exemple), et donc ne serait pas portable.
- s'il n'existe pas, et si je dois développer un conposant en C pour y accéder, cela implique-t-il que je dois développer mes IHMs en C également (donc finallement, mon Daemon tout entier) ?
Quitte à faire du non portable, il est en effet possible de développer cette fonctionnalité dans une librairie C ou C++ et d'y accéder depuis le Java en JNI.
J'aimerais développer les IHMs en java car celà m'assure une meilleure portabilité / réutilisabilité du code.
De toute façon, la fonctionnalité d'affichage distant n'existe pas sur tous les OS. Elle ne peut donc pas être portable.
Dans ce cas, il faudrait plutôt développer les IHM côté client et que le daemon se contente d'envoyer des messages vers les clients.
Normalement, un déemon ne devrait pas avoir des IHM complexes (au maximun des boîtes d'erreur / mot de passe)...
<rdeman@gmail.com> a écrit dans le message de news:
1143448081.724365.6970@i40g2000cwc.googlegroups.com...
Ben justement, mon pb est que je ne trouve pas l'équivalent de la
methode XOpenDisplay dans l'API java.
- existe-t-il et c'est moi qu ne l'ai pas trouvé ?
Il semble en effet que Swing sait utiliser plusieurs écrans sur une même
machine, mais pas des écrans distants.
C'est logique dans la mesure où cette fonctionnalité ne peut pas être
assurée sur tous les OS (Windows par exemple), et donc ne serait pas
portable.
- s'il n'existe pas, et si je dois développer un conposant en C pour y
accéder, cela implique-t-il que je dois développer mes IHMs en C
également (donc finallement, mon Daemon tout entier) ?
Quitte à faire du non portable, il est en effet possible de développer cette
fonctionnalité dans une librairie C ou C++ et d'y accéder depuis le Java en
JNI.
J'aimerais développer les IHMs en java car celà m'assure une
meilleure portabilité / réutilisabilité du code.
De toute façon, la fonctionnalité d'affichage distant n'existe pas sur tous
les OS. Elle ne peut donc pas être portable.
Dans ce cas, il faudrait plutôt développer les IHM côté client et que le
daemon se contente d'envoyer des messages vers les clients.
Normalement, un déemon ne devrait pas avoir des IHM complexes (au maximun
des boîtes d'erreur / mot de passe)...
Ben justement, mon pb est que je ne trouve pas l'équivalent de la methode XOpenDisplay dans l'API java. - existe-t-il et c'est moi qu ne l'ai pas trouvé ?
Il semble en effet que Swing sait utiliser plusieurs écrans sur une même machine, mais pas des écrans distants.
C'est logique dans la mesure où cette fonctionnalité ne peut pas être assurée sur tous les OS (Windows par exemple), et donc ne serait pas portable.
- s'il n'existe pas, et si je dois développer un conposant en C pour y accéder, cela implique-t-il que je dois développer mes IHMs en C également (donc finallement, mon Daemon tout entier) ?
Quitte à faire du non portable, il est en effet possible de développer cette fonctionnalité dans une librairie C ou C++ et d'y accéder depuis le Java en JNI.
J'aimerais développer les IHMs en java car celà m'assure une meilleure portabilité / réutilisabilité du code.
De toute façon, la fonctionnalité d'affichage distant n'existe pas sur tous les OS. Elle ne peut donc pas être portable.
Dans ce cas, il faudrait plutôt développer les IHM côté client et que le daemon se contente d'envoyer des messages vers les clients.
Normalement, un déemon ne devrait pas avoir des IHM complexes (au maximun des boîtes d'erreur / mot de passe)...
rdeman
Effectivement, je comprend bien que la librairie java que je recherche ne marcherait que sur X11 ...
Sur 'comp.lang.java.programmer', qqun m'a envoyé un lien vers http://escher.sourceforge.net/. A voir ...
Merci pour ce feeback. Rodolphe
Effectivement, je comprend bien que la librairie java que je recherche
ne marcherait que sur X11 ...
Sur 'comp.lang.java.programmer', qqun m'a envoyé un lien vers
http://escher.sourceforge.net/. A voir ...
J'ai testé http://escher.sourceforge.net/ et ca résoud mon probleme.
Merci pour vos réponses Rodolphe
rdeman
Euh, enfin, non, ca ne résoud pas du tout mon pb car ca ne permet pas d'ouvrir une fenêtre awt ou swing sur 2 terminaux X11 différents depuis la même JVM. C'est une API de bas niveau à partir de laquelle il faut tout redévelopper ... Et même un truc simple comme un JTree, ca va me couter bonbon !!
Euh, enfin, non, ca ne résoud pas du tout mon pb car ca ne permet pas
d'ouvrir une fenêtre awt ou swing sur 2 terminaux X11 différents
depuis la même JVM. C'est une API de bas niveau à partir de laquelle
il faut tout redévelopper ...
Et même un truc simple comme un JTree, ca va me couter bonbon !!
Euh, enfin, non, ca ne résoud pas du tout mon pb car ca ne permet pas d'ouvrir une fenêtre awt ou swing sur 2 terminaux X11 différents depuis la même JVM. C'est une API de bas niveau à partir de laquelle il faut tout redévelopper ... Et même un truc simple comme un JTree, ca va me couter bonbon !!