|
Réalisation 
|
|
Java et bureau Linux
|
Une petite info en passant...
Hier, je cherchais une distrib Linux dans un journal (comme ça arrive
parfois). Et je suis tombé dans le magazine Linux (ben oui, c'est un nom
logique pour trouver une distrib) sur un long article d'un certain
Guillaume Desnoix qui explique comment configurer sont bureau Linux pour
lui donner un look and feel complètement Java. Alors Guillaume, une petite
présentation pour la liste ?
Nicolas Delsaux
 |
 |
Nicolas Delsaux:
> Une petite info en passant...
> Hier, je cherchais une distrib Linux dans un journal (comme ça arrive
> parfois). Et je suis tombé dans le magazine Linux (ben oui, c'est un nom
> logique pour trouver une distrib) sur un long article d'un certain
> Guillaume Desnoix qui explique comment configurer sont bureau Linux pour
> lui donner un look and feel complètement Java. Alors Guillaume, une
> petite présentation pour la liste ?
Bon je me lance. Sans repeter le premier article (LMF36, dispo en
kiosque), l'objectif de cette serie est de presenter la construction d'un
bureau entierement en Java (et donc d'exposer au passage quelques
techniques utilees pour ce projet mais utiles dans beaucoup d'autres cas).
L'article parle principalement des objectifs, du lancement d'un second
serveur X et de la modification dynamique du bytecode (avec un classloader
etendu) pour transformer les elements graphiques natifs (JFrame) en
elements legers (JInternalFrame).
Le projet de bureau vient par ailleurs d'etre lance (
http://www.jdistro.com/ ) et utilise les idees exposees. Le
developpement vient juste de commencer donc actuellement il s'agit d'un
protoype tres experimental mais deja partiellement fonctionnel.
Guillaume
!!!
!Guillaume Desnoix wrote:
> Bon je me lance. Sans repeter le premier article (LMF36, dispo en
> kiosque), l'objectif de cette serie est de presenter la construction
> d'un bureau entierement en Java (et donc d'exposer au passage quelques
> techniques utilees pour ce projet mais utiles dans beaucoup d'autres
> cas). L'article parle principalement des objectifs, du lancement d'un
> second serveur X et de la modification dynamique du bytecode (avec un
> classloader etendu) pour transformer les elements graphiques natifs
> (JFrame) en elements legers (JInternalFrame). Le projet de bureau vient
> par ailleurs d'etre lance ( http://www.jdistro.com/ ) et utilise les
> idees exposees. Le developpement vient juste de commencer donc
> actuellement il s'agit d'un protoype tres experimental mais deja
> partiellement fonctionnel.
Pourquoi ne pas avoir entrepris la meme série d'article, mais en se
basant sur jesktop ?
Cela aurait été bénéfique pour tout le monde : jesktop aurait gagné des
utilisateurs et probablement aussi des dévelopeurs (le manque de
documentation étant toujours un sérieux frein). Voici l'adresse :
www.jesktop.[net,org] (aucun nerépond pour l'instant :-().
http://www.geocities.com/bill_beebe/cc10.html (une présentation de
l'historique).
Il y avait eu Echidna il y a quelques années, il est vraiment dommage que
ce genre de projets n'est pas pris plus d'ampleur (je n'ose pas parler de
JOS ;)) !
a+, yann.
 |
 |
Yann Secq:
> Pourquoi ne pas avoir entrepris la meme série d'article, mais en se
> basant sur jesktop ?
Pour beaucoup de raisons, mais la principale est que Jesktop ne m'a pas
convaincu. Soit dit, je cite Echidna et Jesktop dans l'article et meme sur
la page d'accueil de JDistro. A chacun de choisir.
D'autre part, l'article concerne principalement l'aspiration des frames,
qui n'est pas faite dans Jesktop. Dans Jesktop, il faut modifier le code
source de son appli (ou au moins rajouter un wrapper). Jesktop utilise
aussi un format particulier d'archive, n'a pas de support JNLP, ne separe
pas lanceur et bureau, ... Je n'ai pas regarde en detail, mais je n'ai pas
vu de support pour la securite, les applets, les applications natives, ...
> Cela aurait été bénéfique pour tout le monde : jesktop aurait gagné des
> utilisateurs et probablement aussi des dévelopeurs (le manque de
> documentation étant toujours un sérieux frein).
Y'a t'il des developpeurs ou des utilisateurs de Jesktop sur cette liste ?
Es-tu utilisateur ou developpeur, et si non, pourquoi ? Pour ma part, je
m'amuse. Et mon bureau tourne en permanence sur un second serveur X, en
parallele avec Gnome. L'editeur J tourne deja. Des que JEdit fonctionnera
(et donc ant, javac, ...), ca deviendra mon bureau principal.
> Voici l'adresse : www.jesktop.[net,org] (aucun nerépond pour l'instant
> :-().
Ca marchait il y a 15 jours.
> Il y avait eu Echidna il y a quelques années, il est vraiment dommage
> que ce genre de projets n'est pas pris plus d'ampleur
Tout a fait d'accord. Echidna est un beau projet (voir aussi jsh).
Guillaume
 |
 |
Guillaume Desnoix wrote:
> D'autre part, l'article concerne principalement l'aspiration des
> frames, qui n'est pas faite dans Jesktop. Dans Jesktop, il faut
> modifier le code source de son appli (ou au moins rajouter un
> wrapper). Jesktop utilise aussi un format particulier d'archive, n'a pas
> de support JNLP, ne separe pas lanceur et bureau, ... Je n'ai pas
> regarde en detail, mais je n'ai pas vu de support pour la securite, les
> applets, les applications natives, ...
Certes, je n'ai pas été vérifié au niveau du code comment cela se
passait, mais la modification
des JFrame en JInternalFrame aurait probablement pu etre rajouté dans
jesktop. Je ne pousse pas à l'utilisation de tel ou tel projet, je trouve
juste dommage qu'aucun environnement java ne soit encore viable malgré les
efforts qui ont été faits.
> Y'a t'il des developpeurs ou des utilisateurs de Jesktop sur cette liste
> ? Es-tu utilisateur ou developpeur, et si non, pourquoi ?
Non, effectivement à cause du problème que tu soulignes (i.e. la
modification nécessaire des projets),
de ce point de vue, la modification du bytecode à la volée est une
solution intéressante.
> Pour ma part, je m'amuse. Et mon bureau tourne en permanence sur un
> second serveur X, en parallele avec Gnome. L'editeur J tourne deja. Des
> que JEdit fonctionnera (et donc ant, javac, ...), ca deviendra mon
> bureau principal.
J'ai chargé jdistro, compilation impeccable (pas Ant ? :), j'ai lancé
Korte : ça tourne. J'ai eu un petit problème en quittant l'explorateur
(l'application s'est terminée) : secq@beckett:/tmp/jdistro$ java -cp
classes/ com.jdistro.KorteMain KTM: add K?rte Main Task
KorteClassLoader(0): Created java.lang.VerifyError: (class:
com/jdistro/Wharf, method: buildPager signature: ()V) Incompatible object
argument for function call
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:1613) at
java.lang.Class.privateGetPublicMethods(Class.java:1641) at
java.lang.Class.getMethod0(Class.java:1730) at
java.lang.Class.getMethod(Class.java:951) at
com.jdistro.KorteMain$7.run(KorteMain.java:524) at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:443) at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.
java:190)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.ja
va:144)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
ACTION: OUVRIR REGISTER class com.jdistro.KFrame %%% KORTE UNREGISTER
class com.jdistro.KFrame UNREGISTER class com.jdistro.KFrame
KorteClassLoader(0): Freed (Compilation : Jikes 1.15, Runtime :
j2sdk1.4.0rc sous une Debian instable)
Ma question : est-ce un projet "perso" dans le sens ou le but est
d'avoir un environnement
qui te convienne, ou est-ce un pas vers un desktop java ?
> Tout a fait d'accord. Echidna est un beau projet (voir aussi jsh).
Oui, j'ai un petit peu tripoté jsh et c'est aussi un projet prometteur (en
tout cas pour les unixiens qui on du mal à se passer d'un shell :)). Tu
vas l'intégrer dans jdistro ?
yann.
 |
 |
Yann Secq:
> je trouve juste dommage qu'aucun environnement java ne soit
> encore viable malgré les efforts qui ont été faits.
C'est que la chose est plutot delicate car ni la JVM, ni Swing ne sont
prevus pour ca. En fait, je ne sais pas jusqu'ou il est possible d'aller.
Y'a t'il un moyen de superviser les allocations memoire ? Y'a t'il moyen
de controler le temps passe dans le thread swing pour chaque appli ? (- Si
vous avez des idees... -)
>> Des que JEdit fonctionnera (et donc ant, javac, ...), ca deviendra mon
>> bureau principal.
JEdit 3.2.2 semble fonctionner (avec un patch de 4 lignes).
Par contre je n'ai pas encore teste les greffons.
> J'ai chargé jdistro, compilation impeccable (pas Ant ? :), j'ai lancé
> Korte : ça tourne.
Le fichier build.xml est en cours d'ecriture. Il n'est pas encore joint
car il y a encore qqs petits problemes de repertoire.
> J'ai eu un petit problème en quittant l'explorateur (l'application s'est
> terminée) : secq@beckett:/tmp/jdistro$ java -cp classes/
> com.jdistro.KorteMain KTM: add K?rte Main Task KorteClassLoader(0):
> Created java.lang.VerifyError: (class: com/jdistro/Wharf, method:
> buildPager signature: ()V) Incompatible object argument for function
> call (Compilation : Jikes 1.15, Runtime : j2sdk1.4.0rc sous une Debian
> instable)
Alors tu n'as pas vu le wharf...
Bizarre mais je n'ai pas teste avec jikes 1.15 (qui me pose toujours des
problemes) ni surtout sous le JDK1.4.
Sinon le point d'entree est com.jdistro.Korte.
Si tu aimes prendre des risques ;-) essaye la version compilee.
http://www.desnoix.com/jdistro/distribution/install_korte.jar
> Ma question : est-ce un projet "perso" dans le sens ou le but est
> d'avoir un environnement qui te convienne, ou est-ce un pas vers
> un desktop java ?
Les deux. Ca ne me semble pas incompatible.
> Oui, j'ai un petit peu tripoté jsh et c'est aussi un projet prometteur
> (en tout cas pour les unixiens qui on du mal à se passer d'un shell :)).
> Tu vas l'intégrer dans jdistro ?
Je compte integrer un shell. Certains aspects de Jsh m'interessent mais
par exemple le portage des gnu tools (date, ls, ...) est tres peu avance.
D'autre part, une dizaine d'interpreteurs de script seront bientot dispo
(vu que j'ai deja fait le boulot pour Alma).
Guillaume
 |
 |
Le 5 Feb 2002 Guillaume Desnoix a écrit :
>
> C'est que la chose est plutot delicate car ni la JVM, ni Swing ne sont
> prevus pour ca. En fait, je ne sais pas jusqu'ou il est possible
> d'aller. Y'a t'il un moyen de superviser les allocations memoire ? Y'a
> t'il moyen de controler le temps passe dans le thread swing pour chaque
> appli ? (- Si vous avez des idees... -)
>
Pour les allocations mémoire je sais pas trop. Mais de toutes façons
personnes ne contrôle les allocations mémoires, il me semble ? C'est pour
quoi que tu veux le faire ?
Pour swing il y a peut être moyen de se débrouiller (un peu) en
forçant le thread group de swing. Je l'ai jamais fait, mais un jour
il faudra certainement que je me le tape pour être sûr de récupérer
les erreurs swing.
Il suffit peut être de créer un ThreadGroup dès le départ
(normalement tous les thread créés à partir de lui, dont swing,
devrait y être intégrés, ou bien de passer par le
SecurityManager.getThreadGroup. Mais cela oblige à fixer soit le
ThreadGroup, soit le SecurityManager.
A+.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
 |
 |
>> Y'a t'il un moyen de superviser les allocations memoire ?
Herve AGNOUX:
> Pour les allocations mémoire je sais pas trop. Mais de toutes façons
> personnes ne contrôle les allocations mémoires, il me semble ? C'est
> pour quoi que tu veux le faire ?
Tout simplement pour eviter qu'une appli consomme toute la memoire (et de
ce fait bloque le bureau et toutes les autres applis). J'avais pense a
redefinir la classe Object (ca marche) mais la consequence est que chaque
appli a des classes totalement differentes et donc ne sont plus
compatibles (ne peuvent etre affichees sur le meme bureau.
Je n'ai rien trouve non plus du cote de JPDA.
Une troisieme possibilite envisagee est la modification du bytecode:
remplacer les "new MaClasse()" par des appels a "Usine.createMaClasse()".
Mais ca ne m'a pas l'air simple.
Reste la piste des proxys. (voir message separe)
>> Y'a t'il moyen de controler le temps passe dans le thread swing
>> pour chaque appli ? (- Si vous avez des idees... -)
> Pour swing il y a peut être moyen de se débrouiller (un peu) en
> forçant le thread group de swing. Je l'ai jamais fait, mais un jour il
> faudra certainement que je me le tape pour être sûr de récupérer les
> erreurs swing.
En fait il n'y a pas de group pour swing mais un seul thread. L'idee est
effectivement de le controler... surement avec un autre thread de priorite
superieure.
En fait je pense recuperer la EventQueue et filtrer les evenements selon
les applis. Et placer un delai maximal d'execution pour chaque
evenement... Ca simplifierait quand meme pas mal les choses si Swing etait
multi-threade.
> Il suffit peut être de créer un ThreadGroup dès le départ
> (normalement tous les thread créés à partir de lui, dont swing,
> devrait y être intégrés, ou bien de passer par le
> SecurityManager.getThreadGroup. Mais cela oblige à fixer soit le
> ThreadGroup, soit le SecurityManager.
J'ai deja un SecurityManager personnalise, c'est lui qui grace a
getClassContext() me permet de determiner quelle appli est en cours. Et
chaque appli s'execute dans son propre threadgroup. Mais ceci n'est pas
utilisable pour la partie Swing (car mono-thread).
A+ Guillaume
 |
 |
Le 6 Feb 2002 Guillaume Desnoix a écrit :
>
> Tout simplement pour eviter qu'une appli consomme toute la memoire (et
> de ce fait bloque le bureau et toutes les autres applis). J'avais pense
> a redefinir la classe Object (ca marche) mais la consequence est que
> chaque appli a des classes totalement differentes et donc ne sont plus
> compatibles (ne peuvent etre affichees sur le meme bureau.
>
Moi je pense que tu confonds bureau et système d'exploitation. Mais
tu as le droit, je ne veux en aucun cas me lancer dans un troll
"bureau ou système d'exploitation ?" !
>
>
> En fait il n'y a pas de group pour swing mais un seul thread. L'idee est
> effectivement de le controler... surement avec un autre thread de
> priorite superieure.
>
Rien ne t'empêche de ne mettre qu'un thread dans un groupe de thread (ou
même aucun !). Depuis le ThreadGroup tu peux contrôler différentes choses
qui peuvent être intéressantes, comme la priorité des threads, ou attraper
les exceptions issues des threads.
> En fait je pense recuperer la EventQueue et filtrer les evenements
> selon les applis. Et placer un delai maximal d'execution pour chaque
> evenement... Ca simplifierait quand meme pas mal les choses si Swing
> etait multi-threade.
>
Du coté de swing y'a effectivement pas mal de choses à améliorer,
mais le sujet est complexe.
>
> J'ai deja un SecurityManager personnalise, c'est lui qui grace a
> getClassContext() me permet de determiner quelle appli est en cours. Et
> chaque appli s'execute dans son propre threadgroup. Mais ceci n'est pas
> utilisable pour la partie Swing (car mono-thread).
>
J'ai un problème similaire, bien que fort éloigné, et pas encore tout à
fait résolu.
A partir d'évènements issus de topic messages JMS, comment influer
sur une visu swing ? Chaque message JMS vient d'un thread différent, hors
avec swing tout est dans un seul thread.
On peut bien sûr dans les cas simples se débrouiller avec invokeLater ou
assimilé, mais ça marche pas dés que ça devient un peu sioux. Il ne suffit
pas que swing soit dans un seul thread, il faut en plus que ta propre
partie swing y soit aussi, ce qui t'obligerait à placer des synchronized
un peu partout, ce qui n'est vraiment pas éléguant.
Ma solution est de créer un nouveau "topic", destiné à choper les
messages issus de tous les topic que je veux écouter. C'est une sorte
d'entonoir. Donc j'ai d'un coté tous mes petits threads qui batifolent, et
de l'autre la partie vue qui est plus ou moins dans le même thread. Je
trouve ça pas mal, finalement. Cela correspond bien aux phénomènes réels,
il me semble.
Pourquoi tiens-tu à repérer chaque appli ? Ne pourrais-tu pas laisser
swing tel qu'il est, et te contenter de repérer les parties MC du Model
Vue Controller ?
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com