Le tout est distribué pour les trois systèmes d'exploitation Linux, MacOS et Windows, excepté le greffon pour Eclipse qui n'est pas encore disponible pour Mac. La distribution est assez soignée, la documentation complète et le tout transpire la bonne volonté. Trolltech invite d'ailleurs les développeurs à tester cette version, et à communiquer leurs impressions sur une liste de diffusion vouée à cet effet.
NdM : Qt Jambi est pour le moment disponible sous une Licence "preview", mais à terme, une version du produit est annoncée en open source Ceux qui développent en langage Java s'accorderont pour dire que la bibliothèque SWING, celle qui est fournie en standard avec le kit de développement de Sun Microsystems, est une plaie (conceptuellement et graphiquement). Et ceux qui ont vaguement utilisé Qt dans d'autres langages en seront d'autant convaincus étant donné la facilité d'utilisation de celle-ci (en grande partie due à l'outil Qt-Designer), la conception un peu plus propre de l'API et le rendu beaucoup plus agréable. Si vous êtes dans ce cas, vous avez peut-être déjà essayé l'alternative SWT (la solution utilisée par Eclipse), qui ne semble pas encore satisfaire les espérances (projet trop jeune ?). Si vous êtes utilisateurs de logiciels libres (et pas trolleur pour un sou), vous devez connaître également Qt pour ses qualités de rendu et l'intégration possible dans un environnement de bureau.
Après plusieurs années d'attente, qui font penser à d'autres mythes comme on en connaît bien par ici, la possibilité de créer des interfaces graphiques avec Qt en Java semble enfin possible. Une tentative avait bien démarré au sein du projet KDE avec le projet Koala, mais n'a pas encore porté ses fruits. Pendant ce temps, Trolltech semble avoir bien progressé et proche du terme.
Aller plus loin
- Annonce officielle (2 clics)
- Page du projet Qt Jambi (14 clics)
- Exemples (17 clics)
- Intégration dans Eclipse (6 clics)
- Téléchargement (17 clics)
# Sur dot.kde.org
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
# toolkit graphique = troll ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 6.
J'ai comme l'impression que des que l'on parle de toolkits graphiques, les trolls sont livrés de série et pas en options...
A l'occasion, Nicolas, matte Aerith ( https://aerith.dev.java.net/ ) ... moi, je trouve ca professionnel comme rendu.
[^] # Re: toolkit graphique = troll ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Mais, j'ai été vaguement trollesque sur ce coup-là, mais bon il y a une belle part de vérité quand même, SWING ça saoûle pour faire le moindre petit truc. Tiens d'ailleurs, au passage pour ceux qui ne connaîtraient pas :
http://madbean.com/anim/totallygridbag/
[^] # Re: toolkit graphique = troll ?
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
Effectivement, Swing est plus adapté pour faire des gros trucs que des petits (encore que, avec les éditeurs d'interface qu'on trouve dans les principaux IDE, Swing n'est plus aussi difficile à prendre en main...), mais ton argumentation me parait un peu légère pour affirmer que c'est "une plaie".
J'ai personnalement eu à utiliser Swing sur des projets assez complexes et volumineux et je suis loin de faire un tel constat. Je trouve l'API plutôt bien pensée, carrée, et relativement simple à utiliser une fois qu'on a réussi à rentrer dedans (ce qui est à la portée de tout ingénieur qui se respecte).
En revanche, je n'ai jamais utilisé Qt, donc j'aimerais savoir en quoi c'est mieux exactement, histoire de dépasser le niveau 0 du troll velu de l'énoncé de la dépêche...
[^] # Re: toolkit graphique = troll ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Bien sûr que SWING a sa logique qui a quelquechose d'élégant avec son beau modèle MVC. Mais il reste que le positionnement des éléments et leur dimensionnement ne sont pas évidents. Je n'ai peut-être pas autant d'expérience que vous dans ce domaine, mais il me semble que ces quelques points ralentissent la productivité et sont sources de bugs graphiques.
En quoi Qt est mieux ? Le rendu. Pour avoir réalisé quelques applications en QT, j'ai été impressionné de la facilité de concevoir une interface graphique qui a une apparence correcte.
Un autre point intéressant est les composants qui sont proposés par Qt. Les composants SWING ont souvent été accusés d'un manque de fonctionnalités (comme les JTable), même si ça a tendance à s'améliorer avec le temps. Un autre exemple est celui du sélecteur de date qui a longtemps fait défaut, et s'est vu comblé par des solutions tierces plus ou moins bien distribuée.
Bien sûr tout cela reste suggestif :-) Et puis c'est vendredy aussi :-D
[^] # Re: toolkit graphique = troll ?
Posté par Pierre Tramo (site web personnel) . Évalué à 3.
On ne fait plus du Swing aujourd'hui de la même façon qu'en 1995 : http://weblogs.java.net/blog/claudio/archive/nb-layouts.html
Les composants SWING ont souvent été accusés d'un manque de fonctionnalités
Sur ce point je suis d'accord, un peu plus de widgets de haut niveau utilisables "out of the box" ne feraient pas de mal à Swing (mais la plupart des besoins du genre que j'ai eu concernait des widgets assez orientés métier, et je doute que d'autres frameworks aient pu m'aider plus sur ces cas précis).
[^] # Re: toolkit graphique = troll ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 3.
[^] # Re: toolkit graphique = troll ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 1.
Pour avoir utiliser QtDesigner, je le trouve tout de même beaucoup plus naturel.
[^] # Re: toolkit graphique = troll ?
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
Il est bien précisé qu'elle n'est présente que pour ceux qui veulent absolument s'en servir et que le mode par défaut permet d'obtenir le même résultat très rapidement, de façon très intuitive et suffit à répondre à la plupart des besoins (au même titre que les autres éditeurs d'interface).
Ce n'est pas cette mauvaise foi flagrante qui va me convaincre de passer à QtDesigner..
[^] # Re: toolkit graphique = troll ?
Posté par Rhadamante . Évalué à 10.
QT ne permet en effet que de faire des petits projets ... comme KDE par exemple ;-)
J'ai personnalement eu à utiliser Swing sur des projets assez complexes et volumineux et je suis loin de faire un tel constat. Je trouve l'API plutôt bien pensée, carrée, et relativement simple à utiliser une fois qu'on a réussi à rentrer dedans (ce qui est à la portée de tout ingénieur qui se respecte).
Je trouve ta phrase que je mets en gras très intéressante, car elle raisonne étrangement avec une puissante métaphore que j'ai entendu Matthias Ettric, fondateur du projet KDE et travaillant aujourd'hui chez Trolltech, utiliser pour illustrer le très difficile art du design d'API (Application Programmers Interface)
N'hésitez pas à lire tout le compte-rendu, ce ne sera pas du temps de perdu :
http://conference2004.kde.org/transcripts/matthias.ettrich-d(...)
http://doc.trolltech.com/qq/qq13-apis.html
La métaphore est celle-ci : l'API est au programmeur ce que la GUI est l'utilisateur et doit être élaborée avec le même soin.
Je suis très tentée de filer la métaphore : ta phrase que j'ai soulignée sous-entend que SWING a sa logique propre, carrée, logique et qu'il s'agit pour le programmeur de la découvrir et de s'adapter à elle. C'est le paradigme qui était utilisé traditionellement pour concevoir les interfaces graphiques : m'enfin, comprenez comment marche la machine, quoi , et adaptez vous y. Il est logique lui ! Et si vraiment l'utilisateur n'y arrive pas, c'est qu'il est con, qu'il ne se respecte pas
Et puis est arrivée la révolution du macintosh qui a posé comme principe de renverser cette manière de penser. C'est à la machine de s'adapter à l'utilisateur et à tendre à fonctioner comme lui. Observez et comprenez d'abord comment fonctionnent les bipèdes et proposez ensuite une interface qui respecte les users expectations.
N'est-ce pas une raison qui expliquerait que des programmeurs trouvent les interfaces à la Qt intuitives et qualifie les interfaces à la Swing de plaie conceptuelles malgré ses qualités théoriques que tu défends ? Oui, ils sont bizarres et imparfaits ces bipèdes, qu'ils soient utilisateurs ou simple programmeurs, résignons nous y et voyons comment on peut les aider malgré cela.
[^] # Re: toolkit graphique = troll ?
Posté par Loic Dreux . Évalué à 4.
[^] # Re: toolkit graphique = troll ?
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
Il y a quand même des différences de taille entre un programmeur et un utilisateur qui font qu'on peut avoir des attentes différentes envers eux : le programmeur est bien souvent payé pour le faire et doit justifier son salaire par ses compétences, de plus il est supposé avoir suivi une formation solide et en avoir conservé des acquis (autant en connaissances brutes qu'en méthodes ou en faculté d'adaptation, ...). On peut supposer qu'il aura le courage de se documenter un minimum avant d'utiliser un outil, et de réfléchir un peu plutôt que d'écrire du code au kilomètre. Sinon, qu'il reste avec son VB6...
Quand on conçoit une GUI, on se doit de considérer que l'utilisateur est assez neuneu, je suis confronté tous les jours à cette contrainte. Mais considérer le programmeur comme un neuneu n'est pas lui rendre service : c'est en résolvant des problèmes qu'on progresse, et j'ai personnellement beaucoup appris en intégrant les principes de certaines bibliothèques qui me semblaient complexes au premier abord.
ta phrase que j'ai soulignée sous-entend que SWING a sa logique propre
Absolument pas, la logique de Swing est inspirée d'un bon nombre de patrons de conception (MVC, cité plus haut, pour le principal, mais aussi beaucoup d'autres : Observateur, ...). Swing utilise un paquet de notions qu'il est nécessaire de maîtriser, et celles-ci n'ont pas été inventées pour l'occasion, mais sont tirées de l'état de l'art.
malgré ses qualités théoriques que tu défends ?
Ça n'a rien de théorique, c'est de par mon expérience que je me permets de contredire certains mythes qui ont la vie dure.
Bien évidemment, Swing a ses défaut (personne n'osera défendre le code verbeux qu'on doit parfois se taper quand on ne passe pas par un éditeur d'interface ou une surcouche spécialisée), et Qt a certainement beaucoup de qualités tellement on en dit du bien. Je ne demande qu'à les connaître, mais pour ça, il faudrait sortir un peu des sentiers trollesques et des leçons de rhétorique...
[^] # Re: toolkit graphique = troll ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
Les delegates (ou signaux) par rapport a des interfaces Listener c'est carrement moins rebarbatif/verbeux a utiliser.
- Qt Designer genere du XML
Qt Designer est une petite merveille a utiliser.
Le code genere se trouve dans un fichier separee et pour s'interfacer avec c'est propre et clean. La derniere fois que j'ai utilise des generateurs SWING ca collait tout dans le meme fichier (ca a peut etre change depuis)
- Qt s'integre 10x mieux au desktop que SWING sous Linux et Windows
- Une interface Qt c'est rapide !
- Qt evolue beaucoup plus vite que SWING et est plus complet
il suffit de voir les ameliorations de la version 4.2: integration DBUS, icones SVG, nouveaux widgets, utilisation de CSS pour personnaliser l'interface...
De tout ce que j'ai utilise (MFC, win32, GTK+, SWING, SWT, wxWidget) j'ai trouve que Qt est le plus sympa a tout niveau: rendu, rapidite, integration, simplicite, puissance, maintenabilite du code, documentation ect...
SWING n'est pas mauvais, mais a mon avis est moins bon que Qt ce qui ne signifie pas qu'on peut pas faire des trucs sympas avec SWING.
Ceci est juste mon avis :)
[^] # Re: toolkit graphique = troll ?
Posté par ndesmoul . Évalué à 2.
- Qt Designer genere du XML
Qt Designer est une petite merveille a utiliser.
Le code genere se trouve dans un fichier separee et pour s'interfacer avec c'est propre et clean. La derniere fois que j'ai utilise des generateurs SWING ca collait tout dans le meme fichier (ca a peut etre change depuis)
Le designer de la dernière version de NetBean génère également du XML. Pour l'avoir essayé un peu il est plutôt pas mal. A voir pour un vrai projet mais je conseille tout de même à ceux développant une GUI java d'y jetter un coup d'oeil. Ca pourrait les intéresser.
- Qt s'integre 10x mieux au desktop que SWING sous Linux et Windows
Ca s'est clair. Encore que ce qui me dérange le plus c'est que les polices de caractères ne sont pas lissées avec Swing. Ca devrait bientôt être le cas ceci dit.
- Une interface Qt c'est rapide !
Pour avoir essayé des versions récentes de Swing, je trouve que c'est plutôt réactif. J'ai même trouvé NetBean (Swing) plus réactif que Eclipse (SWT). Le tout sous Linux. En même temps c'est sans doute SWT qui est un peu buggé...
Je me demandai d'ailleurs si j'allais pas essayé SWT pour voir mais QT me semble beaucoup plus intéressant.
L'autre avantage c'est qu'on va pouvoir développer plus facilement des applications Java pour KDE. Bah, oui moi j'aime pas le C++.
Avec Java qui devrait être libéré par SUN, ça pourrait devenir intéressant.
[^] # Re: toolkit graphique = troll ?
Posté par golum . Évalué à 2.
Marketainge QT
[^] # Re: toolkit graphique = troll ?
Posté par ndesmoul . Évalué à 1.
[^] # Re: toolkit graphique = troll ?
Posté par Calvin0c7 . Évalué à 5.
Trop fort.
Je suis un utilisateur de swing et c'est sur que si on est habitué à faire du VB (je prends l'extrême hein, je t'insulte pas) ça fait drôle. Je trouve l'API TRES bien faite et puissante, la manière de gérer les event est élégante (même si un peu déroutante au début) et la portabilité n'est PAS une légende (en tout cas dans la majorité des cas).
Par contre l'exemple de cette animation est, à mes yeux, symptomatique de la principale difficulté de swing : les layouts.
Alors je le dis pour ceux qui vont, veulent, sont obliger de s'y mettre : les layouts c'est l'enfer, la géhenne, c'est mystérieux, c'est vivant, ça se rebelle, ça fait ce que ça veut (et ça veut rarement la même chose que toi).
[^] # Re: toolkit graphique = troll ?
Posté par Philippe F (site web personnel) . Évalué à 6.
Une application graphique, c'est avant tout un ensemble de briques graphiques a organiser. Et de nos jours, on a les parametres suivants qui sont variables :
- les traductions peuvent allonger ou racourcir les dialogues en permanence
- les gens ont des resolutions d'affichage hautement variable : entre le commercial avec son portable 12 pouces et le geek avec son 3500 x 4600, il faut s'adapter.
Donc les layouts sont quand meme un element important de la conception graphique de nos jours.
Pour l'instant, je trouve le discours des defenseurs de swing plutot desagreable. En gros, soit le programmeur est assez intelligent pour comprendre comment swing marche, soit il ferait mieux de retourner a son visual basic. Ca me fait penser aux defenseurs des MFCs qui disent que les MFCs sont simples et faciles a utiliser, mais qu'il faut 5 ans pour apprendre a bien s'en servir.
Trolltech a propose une approche de la programmation graphique qui est facile. Ce n'est pas une tare d'etre facile a utiliser, et ce n'est pas parce que Microsoft a fait rimer facilite et simplicite avec truc crade et inutilisable en gros deploiement que c'est une loi immuable.
Qt possede a mon sens l'avantage d'etre agreable a utiliser par des experts et par des debutants. Les debutants sont contents d'arriver rapidement a des resultats et les experts ne se sentent pas contraints par le framework mais peuvent au contraire laisser libre cours a leur creativite.
Pour revenir a l'histoire des layout, sous Qt, on peut par exemple laisser un expert en ergonomie travailler sur l'interface avec Qt Designer pendant que le programmeur travaille sur la logique, et cela sans se perturber l'un l'autre. La gestion des layouts est donc accessible a des non-techos.
Dans toutes les applications graphiques sur lesquelles j'ai travaille avec Qt, ce qui m'a le plus plu, c'est que comme la partie graphique est simple a mettre en place, on peut vraiment se concentrer sur la logique de l'application.
[^] # Re: toolkit graphique = troll ?
Posté par ndesmoul . Évalué à 1.
J'aimerai également attiré l'attention sur l'éditeur graphique de la dernière version de NetBean. J'ai un peu joué avec et il m'a paru très facile d'utilisation et permettant un placement facile des composants (et sans soucis pour bien aligner les composants). Le code Java généré a l'air propre mais de toute façon l'éditeur ne te permet pas d'y toucher: l'interface créé est sauvegardé dans un format basé sur du XML à partir duquel est généré le code.
Je suis pas allé très loin avec mais à mon avis ça mérite un coup d'oeil.
Ceci dit je trouve que pouvoir utilisé QT avec Java est une excellente nouvelle. Je préfère cette solution à SWT et QT tourne sur énormément de plateformes différentes donc la portabilité ne semble pas être un problème.
Mais bon j'attend d'avoir essayé.
PS: pour les adeptes du GridBagLayout, je sais qu'il y a une logique d'utilisation derrière (si si) et qu'on finit par arriver à un résultat correct mais c'est quand même prise de tête.
[^] # Re: toolkit graphique = troll ?
Posté par Philippe F (site web personnel) . Évalué à 3.
Rien ne m'empeche non plus de developper un toolkit graphique complet pour remplacer Qt, Gtk, Swing en une seule fois. Sauf que je prefere me concentrer sur la logique de mon application et que je trouve que ce travail revient plutot au developpeur du toolkit graphique.
Le fait que les layouts soient mal geres veut dire que le programmeur va passer beaucoup de temps a resoudre un probleme qui n'a rien a voir avec l'application qu'il developpe alors qu'il pourrait etre en train de corriger des bugs ou ajouter des fonctionnalites.
[^] # Re: toolkit graphique = troll ?
Posté par reno . Évalué à 1.
mais beaucoup moins l'implémentation: quand j'avais essayé de l'utiliser c'était buggé jusqu'a la moelle (i18n, impression, etc) et très lent: ça n'a pas du beaucoup changer pour cette partie: les outils d'admin Solaris9 donc fait par Sun (!!!) sont 'escargotesques'.
[^] # Re: toolkit graphique = troll ?
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Personnellement, j'aime bien les trolls, je trouve ça drole : "un projet bien conçu (un peu comme qmail)", "des raccourcis conviviaux à la façon d'emacs", "ubuntu contribue fortement à la popularité de debian" ...
J'ai l'impression que là il s'agit surtout d'affirmer des certitudes : "j'aime pas swing, donc c'est pourris". Ce n'est pas surprenant, venant d'un utilisateur de kubuntu, mais c'est vraiment curieux que les modos aient laissé passer ça.
[^] # Re: toolkit graphique = troll ?
Posté par BAud (site web personnel) . Évalué à 4.
quand dans le texte de la dépêche, il y a
Si vous êtes utilisateurs de logiciels libres (et pas trolleur pour un sou)
Ne crois-tu pas que certains modos sont trolleurs eux-aussi et le laissent sciemment passer ? De temps en temps, cela ne fait pas de mal et peut permettre des choses au passage.
[^] # Re: toolkit graphique = troll ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Si j'avais fait une dépêche sans troll, sans aucune critique, il n'y aurait eu aucun commentaire, à part une ou deux tentatives de lâcher de troll par des frustrés. Tandis que là, on a plein d'éléments ! Merci donc à ceux qui ont fait l'effort de répondre, et tant pis si je vous ai froissé ;-)
[^] # Re: toolkit graphique = troll ?
Posté par stephwww . Évalué à 1.
# héritage multiple?
Posté par salvaire . Évalué à 2.
[^] # Re: héritage multiple?
Posté par lasher . Évalué à 4.
- dans les cas simple, l'utilisation des interfaces est suffisant ;
- dans les cas plus complexes, il y a plusieurs techniques. L'une d'entre elles est de dériver la classe depuis l'une de celles dont on voudrait hériter, et de créer des objets privés des autres classes, en reproduisant l'interface publique de chaque objet (oui, c'est fastidieux), par exemple.
[^] # Re: héritage multiple?
Posté par Sylvain Sauvage . Évalué à 2.
class A;
class B;
class C : A, B;
devient, en Java :
interface A {}
class A_I implements A {}
interface B {}
class B_I implements B {}
interface C extends A, B {}
class C_I extends A_I {
private B_I b_i;
/* refaire toutes les fonctions f de B : */
f() { b_i.f(); }
}
(Il faut choisir entre hériter de A_I, de B_I, ou d'aucun.)
(On fait aussi de C une interface pour pouvoir multi-hériter de C ensuite...)
Donc, c'est très lourd à écrire, mais c'est automatisable, mais c'est plus vraiment du Java...
[^] # Re: héritage multiple?
Posté par Thomas Douillard . Évalué à 5.
Chef, chef, mon voisin de bureau il est tout le temps en pause café ! Et en plus, il délègue tout son boulot sur moi.
[^] # Re: héritage multiple?
Posté par golum . Évalué à 2.
http://www.trolltech.com/developer/downloads/qt/resolveuid/2(...)
# SWING n'est pas une plaie pour moi
Posté par David Sporn (site web personnel) . Évalué à 5.
Et bien pas moi. Au contraire, j'ai considéré SWING comme un don du ciel (Allélouïa mes frères !) quand j'ai commencé sérieusement à me mettre au Java en 1999 : j'avais besoin d'un éditeur de texte UTF-8 pour mon site de cours de Japonais, et le seul éditeur que je connaissait sous Windows 95 était Outlook express.
Bref, une fois configuré le font.properties pour utiliser toutes les bonnes fontes (MS Mincho et Gothic pour la plage CJK, puis -deuxième don du ciel (re-Allélouïa mes frères !)- Arial Unicode qui évite d'avoir à mélanger les fontes pour couvrir les plages unicodes dont j'ai besoin), Swing m'a permis d'avoir un tel éditeur, les doigts dans le nez.
Actuellement, ce sera plus pour des problèmes de pouvoir faire tourner mes création sur des émulateur Java libres plutot que celui fourni par le jdk/jre de sun qui me préoccupera ==> éventuellement passage à SWT, jambi -quand il aura cette fameuse license open source-, voire un binding java-gtk.
[^] # Re: SWING n'est pas une plaie pour moi
Posté par Iyo . Évalué à 2.
Bon, la-dessus, je vais me penchez sur le projet parce que c'est vrai que QT j'aime bien aussi. Par contre, pas de version Solaris donc je ne peux pas l'exploiter en prod...
# Quelques petites précisions ...
Posté par Gmooron . Évalué à 2.
* Qt et QtJambi ne consiste pas qu'en un toolkit graphique. Autrement dit, QtJambi n'est pas que le portage des classes graphiques de Qt, mais de toutes les classes (à terme en tous les cas)
[^] # Re: Quelques petites précisions ...
Posté par ndesmoul . Évalué à 1.
[^] # Re: Quelques petites précisions ...
Posté par tanguy_k (site web personnel) . Évalué à 4.
QtCore Core non-GUI classes used by other modules
QtGui Graphical user interface components
QtNetwork Classes for network programming
QtOpenGL OpenGL support classes
QtSql Classes for database integration using SQL
QtSvg Classes for displaying the contents of SVG files
QtXml Classes for handling XML
QtTest Tool classes for unit testing
SQL, SVG, XML, reseau (FTP, HTTP, detection reseau), OpenGL, thread, mutex, slot/signaux, file, timer, DBus... Bref tout un framework a la Java ou a la C#
Tout n'est pas disponible dans Qt Jambi cf
http://doc.trolltech.com/qtjambi-1.0/qtjambi-classes.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.