Envoy� par pseudocode
�a me laisse baba... c'est du Normand dans le texte ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter
Effectivement je ne connaissais pas et le descriptif a l'air sympa.
Par contre en lisant le dernier post : http://www.developpez.net/forums/d78...t/#post4565792 c'est apparemment encore un proof of concept, m�me s'il est bien avanc�. Ca n'a pas encore fait ces preuves mais il y a deux trois choses qui ont l'air prometteuse.
@pseudocode: pas sur de bien saisir en quoi l'ind�pendance � la plateforme est un inconv�nient ? Des librairies comme JDIC qui impl�mentent le systray sont de bons exemples d'extensions pour profiter des possibilit�s des plateformes tout en restant g�n�rique.
Les avantages des uns sont les inconv�nients des autres.
Le simple fait que des librairies comme cela existe montre bien qu'il y a un "manque" dans Swing. Ce manque est combl� en �crivant, au mieux des "wrappers", au pire des "�mulateurs", de la toolkit native.
Ce qui est dommage, c'est que les toolkits natives �voluent beaucoup plus vite que ces librairies, sans parler des IDE pour dessiner les IHM.
SUN (et la communaut� Java) a pris le parti d'impl�menter sa propre toolkit afin de respecter sa philosophie de portabilit� totale (Write once, run anywhere). C'est d�j� un travail �norme de d�velopper une toolkit, ca l'est encore plus de la faire �voluer pour qu'elle soit toujours � la pointe de la technologie. Aujourd'hui, Swing est un "follower'" qui a toujours du retard sur les innovations des autres toolkits, que ce soit en terme de composants, rendus ou langage.
La question "Devrait-on faire un client lourd en Java ?" se pose pour moi en d'autres termes:
"Pourquoi choisir Java pour d�velopper un client lourd ?"
Les r�ponses sont vari�es (portabilit�, frameworks disponibles, maitrise du langage, ...). Mais comme dans tout choix, il faut aussi de poser le probl�me des contraintes:
"Quelles sont les contraintes impos�es par l'utilisation de Java POUR CE PROJET PARTICULIER ?"
Besoin d'une IHM qui d�chire sous windows, peut-on utiliser Swing ? Besoin de portabilit�, peut-on utiliser QtJambi ? Besoin de d�velopper rapidement, a-t-on le temps de se former � Aerith ? Besoin de p�r�nit�, peut-on prendre Eclipse E4 ?
Tout est dans la d�finition des contraintes du "client lourd".
ALGORITHME (n.m.): M�thode complexe de r�solution d'un probl�me simple.
ben, tu utilises les m�me mots dans les 2 cas...Les avantages des uns sont les inconv�nients des autres.
(j'ai compris, tu as appliqu� ton message utilisateur [ALGORITHME ...] au cas)
"Pourquoi choisir Java pour d�velopper un client lourd ?", on peut voir le probl�me autrement...
Pourquoi apprendre plusieurs langages et maitriser plusieurs EDI quand on pourrait tout faire avec 1...
La valeur ajout�e est dans l'application, pas dans la techno...
En fait, le seul truc, c'est qu'Eclipse n'utilise PAS Swing, mais SWT... dans c'est juste pas dans le propos !
Cela dit, SWT a sans doute une part de plus en plus importante dans le dev d'applis riches en Java...
C'est une vision des choses... A l'inverse, pourquoi utiliser un langage g�n�raliste plutot que plusieurs langages d�di�s ?
On n'est pas forc�ment dans le cadre d'un projet avec un seul d�veloppeur "java" qui serait oblig� de faire l'IHM.
ALGORITHME (n.m.): M�thode complexe de r�solution d'un probl�me simple.
Eternel d�bat polyvalence vs sp�cialisation. La nature explore les 2 voies depuis des millions d'ann�es, et aucune n'a encore gagn� seule !
Alors que bizarrement dans l'id�e et l'architecture, SWT est encore plus archa�que et "sale" dans le code que Swing. C'est surtout la plate forme RCP qui change la donne.
Tu d�tournes un peu mon propos, mais d'un autre c�t�, je l'avais mal exprim�
J'essaye de faire mieux :
Outre les contraintes techniques qui justifieraient une plate-forme sp�cialis�e, pourquoi avoir besoin de plusieurs langages et edi l� o� un couvre tous les besoins, la valeur ajout� est dans l'application, pas dans l'outil utilis� pour la concevoir
Dans un sens... mais la polyvalence n'exclue pas la sp�cialisationEternel d�bat polyvalence vs sp�cialisation. La nature explore les 2 voies depuis des millions d'ann�es, et aucune n'a encore gagn� seule !
C'est juste beaucoup plus long d'�tre sp�cialiste de plusieurs techno... la vie est courte... et ces techos bougent tout le temps... sauf swing (
Pour moi, la techno (l'outil) est choisie en fonction des contraintes "projet" : comp�tences individuelles, r�partitions des t�ches, sp�cification du produit, d�lai/cout a respecter, ...
Je ne vois pas pourquoi Java serait la r�ponse universelle a tous les projets de client lourd. Ou au contraire un choix a �viter a tout prix. Tout d�pend du projet.
Faire une IHM qui d�chire en Swing, c'est aussi compliqu� que vouloir faire une IHM portable en GTK. Autant choisir la techno en fonction des contraintes.
ALGORITHME (n.m.): M�thode complexe de r�solution d'un probl�me simple.
T'aurais pu prendre un peu mieux que GTK quand m�me, l� la comparaison il est un poil foireuse
Je peux prendre WPF si tu pr�f�res.T'aurais pu prendre un peu mieux que GTK quand m�me, l� la comparaison il est un poil foireuse
Mais le probl�me est l� : si tu cherches la portabilit� tu vas choisir certaines technos et pas d'autres.
ALGORITHME (n.m.): M�thode complexe de r�solution d'un probl�me simple.
Devrait-on faire un client lourd en Java ?
je pense que Sun doit vraiment boss� dur pour faire evoluer Swing car la je suis deja � mon deux ans que je bosse sur java et swing. le plus grand probleme est l'ergonomie de l'ihm car si on essai de le comparer aux ihm faites en .net, les ihm java son vraiment trop null. bien sur JavaFX est la pour remedier au probleme mais le developpement est toujours fatiguant car ca necessite de coder tous les composants � la main notament leur position et le look and feel (chose pas trop interessant).
le seul conseil que je peux propos� � Sun est que s'il veut aussi etre trop present au niveau application desktop, il doit faire evoluer rapidement JavaFx (du genre XAML/WPF du .net)
Je serais surpris de voir quelque chose en interface .net qui ne soit pas realisable en swing.
C'est quoi "null", des exemples ?
une question d'un mec qui ne code pas du tout de client lourd
et merci bouye pour l'histoire de swing, c'�tait vraiment �clairant
quelques points en vrac :
- diff�rences gui .Net/Java : .Net est tr�s proche de D3D, l� o� java c'est nettement moins clair.
- � propos des layout : matisse ne r�sout il pas le souci joliment ?
++
Une autre question m'est venue � l'esprit � propos : j'ai souvent entendu/lu des plaintes � propos de l'EDT et de cette fa�on de g�rer les traitements gourmands en ressources. Comment font les autres framework client lourd pour g�rer la chose ?
Pourquoi pas clair ? Java �tant multiplateforme il n'utilise D3d que sur windows.- diff�rences gui .Net/Java : .Net est tr�s proche de D3D, l� o� java c'est nettement moins clair.
Pour activer l'acc�l�ration direct3d sur windows tu peux m�me utiliser un param�trage particulier :
-Dsun.java2d.d3d=true
j'utilise eclipse donc je ne m'�tendrais pas trop la dessus, ne connaissant pas bien. Mais a ce que j'ai vu matisse ne sait pas g�rer tout les layout (exemple formlayout de jgoodies)- � propos des layout : matisse ne r�sout il pas le souci joliment ?
Concernant l'EDT, le concept n'est pas critiqu� en soi, on retrouve le m�me dans Qt il me semble d'ailleurs. C'est juste que, mal connu ou parfois mal exploit� on trouve souvent de belles erreurs d'utilisation qui ont forg� une bonne r�putation de lourdeur a Swing. Il faut bien manipuler le threading dans Swing, chose pas si maitris� que ca par bcp de d�veloppeurs.
(android aucune id�e, je ne connais pas le sujet.)
Sun ainsi que les publications des divers grandes maisons d'edition (O'Reilly, Addisson-Weisleym, etc. y compris les propres livres edites par Sun meme) sont principalement responsables de ce fait. Pendant longtemps, aucun de leur didacticiel, code ou livre ne se penchait ni n'insistait sur cela ni n'en expliquait l'importance crutiale et souvent la regle de l'EDT n'y etait meme pas respectee.
A partir de 2004~2005 dans les JavaOne, il a ete mentionne et annonce lors des JavaOne que des regles de bonnes conduites ainsi que la creation et l'adoption d'un Swing application framework et les guidelines qui allaient avec devaient etre rapidement mises en place pour eviter tout ce qui est de nos jours considere comme de la mauvaise programmation en Swing.
La plupart des livres recents edites par Sun semblent en tenir desormais compte, les demos fournies avec le JDK et les didacticiels semblent avoir ete corriges depuis (plus ou moins en silence) et en fouillant bien on peut meme trouver une ebauche de regles de bonnes conduites a suivre dans la doc disponible chez Sun. Si on en est arrive a ce point c'est surtout grace au martellage qu'on bien voulu faire Scott, Romain ou d'autres a l'epoque via leurs blogs ou leurs presentations lors de confs et dont nous nous sommes fait echo ici ou ailleurs. Mais globalement c'est quelques chose qu'ils nous faut regulierement remettre sur le tapis car je pense que pas mal de formateurs ou d'enseignants en lycee ou en fac ne se sont toujours pas mis au gout du jour.
Cote application framework, ben, c'est toujours dans les choux et les guidelines eux aussi sont portes disparus puisqu'ils devaient en decouler.
Merci de penser au tagquand une r�ponse a �t� apport�e � votre question. Aucune r�ponse ne sera donn�e � des messages priv�s portant sur des questions d'ordre technique. Les forums sont l� pour que vous y postiez publiquement vos probl�mes.
suivez mon blog sur D�veloppez.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook
Je voulais surtout dire que Java �tait moins appropri� pour faire de la 3D, pas que swing ne b�n�ficiait pas de D3D.
il y a myEclipse pour cela �ventuellement, sachant que d'apr�s ce que j'avais compris matisse venait surtout avec son propre layout qui aidait bien � la conception graphique de gui (drag and drop).
concernant l'EDT et la n�cessit� de gestion multithread�, est ce aussi le cas pour du winforms/WPF ? Ou sous les gui mac ?
R�pondre avec citation
Partager