Qt Jambi - Page 1

Qt Jambi est le port Java de la technologie Qt.
Trolltech (les créateurs de Qt) ont releasé dernièrement une preview technique de Qt Jambi.
Cela permettra de concevoir des interfaces graphiques en bénéficiant de l'API Qt, tout en Java.
Personnellement, je suis plutôt content, car j'apprécie beaucoup développer en Java, et j'aime bien Qt également
Et vous, qu'en pensez-vous ? Que pensez-vous de l'API Qt ?
Plus d'infos : http://linuxfr.org/2006/09/01/21276.html

C'est quoi l'avantage d'utiliser QT à la place de Swing ? Si on connait QT et pas Swing je comprends, mais à part ça ?

Aucune idée.
La différence est dans l'API. Le mécanisme de Qt pour gérer les évènements (signals/slots) est quand même plus souple que celui de SWING (listeners), mais c'est tout ce que je peux dire.
Je trouve que les deux APIs sont plutôt bien conçues perso, même si ça ne semble pas être l'avis de tout le monde. C'est surtout là-dessus que j'aimerais avoir votre témoignage.

Je connais pas du tout SWING, mais je pense que ca fait des fenetres (sous windows) qui sont pas du tout integrees au theme (comme AWT par exemple). Si c'est le cas, Qt regle deja ce probleme normalement...
Et puis Qt est pas mal pour tous les widgets etc. C'est bien puissant sur les images, opengl etc.
Bon, biensur, Qt::Jambi integrera p-e pas tout ca... je sais pas

Pour moi swing est complètement dépassé. Les widgets supporté par swing sont des wigets implémenté en Java pour toutes les plateforme : les appli ont la même tête quelque soit la plateforme : c'est moche.
Après y'a SWT qui lui utilise les wigets de la plateforme, ce qui fait que c'est bien plus performant, bien mieux intégré, bien plus joli, cf eclipse. En plus avec SWT et les eclipse-product, c'est hyper facile de faire ca petite appli standalone sans qu'on remarque que y'a de l'eclipse derrière. Je connaissais un peu SWT et le mécanisme de plugin, j'ai refait les 3/4 de l'appli luke (http://www.getopt.org/luke/) en 2 jours.
Et Qt, je connais que du coté utilisateur final, et je trouve qu'il sintègre encore mieux à une plateforme.
Je viens de lire un peu leur white paper : vraiment très interessant. Et leur API à l'air d'être bien mieux foutue. Rien que ça, ça me fait rêver :
QImage img = new QImage("classpath:images/logo.png");
Et j'ai un peu regarder l'API, et y'a un truc qui manque dans SWT et Swing, c'est ca :
<<
QTableWidget Class Reference
[...]
void sortItems ( int column, Qt:ortOrder order = Qt::AscendingOrder )
>>

Je pense que c'est à essayer
Mais y'a un truc que j'ai toujours pas piger, c'est leur licence....

nEUrOO
: Je connais pas du tout SWING, mais je pense que ca fait des fenetres (sous windows) qui sont pas du tout integrees au theme (comme AWT par exemple).

Heu non, les appli en swing apparaissent comme des applications natives

pas vraiment...

Sinon dans swing faut coder soit même une classpour trier les éléments d'un tableau :/

JackosKing :
Sinon dans swing faut coder soit même une classpour trier les éléments d'un tableau :/

Heuu, swing c'est pas exactement fait pour trier des tableaux Il y a ça dans je sais plus quelles classe standart.

Il parle du widget souvent appelé "table", cf mon post précédent.
Dans SWT, il y a d'implémenté le dessin de la petite flèche sur la colonne, mais pour que ca trie effectivement, faut attendre la prochaine version...

nEUrOO :
Heu non, les appli en swing apparaissent comme des applications natives

JackosKing
: pas vraiment...

Enfin c'est pas si mal quand même... (même si c'est parfois un peu bancale, très gourmand et parfois lent).

c'est un peu lent oui, mais ça garde un aspect graphique exactement comme le système (enfin sous win en tt cas)

Sasume :
Et vous, qu'en pensez-vous ? Que pensez-vous de l'API Qt ?

J'en pense qu'en Java y'a aucun véritable interet vu que le véritable avantage de QT, le multiplateforme est déjà géré par Swing, et que même si tu tiens à faire du natif(à mon avis une mauvaise idée) SWT est déjà là pour ça.
L'API QT, je l'aime bien même si je ne suis pas fan du système signal/slot qui oblige qmake a générer des cpp.
Il faut reconnaitre qu'elle est assez complète pour permettre de faire facilement des applications natives et faciles à porter.

Sasume :
La différence est dans l'API. Le mécanisme de Qt pour gérer les évènements (signals/slots) est quand même plus souple que celui de SWING (listeners), mais c'est tout ce que je peux dire.

Moi personellement je préfère les listener, c'est peut-être une question de gout.

nEUrOO :
Je connais pas du tout SWING, mais je pense que ca fait des fenetres (sous windows) qui sont pas du tout integrees au theme (comme AWT par exemple). Si c'est le cas, Qt regle deja ce probleme normalement...

Les composant AWT sont moches et complètement dépassés.
Swing est beaucoup plus complet. Pas entièrement, mais aucune API multiplateforme ne l'est vraiment.
Il permet de faire des applications en choisissant le look&feel. Certains sont communs mais chaque JVM fournit un look&feel "système" qui permet de reprendre le look natif presque à la perfection. il sufit de faire un UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

hibou :
Pour moi swing est complètement dépassé. Les widgets supporté par swing sont des wigets implémenté en Java pour toutes les plateforme : les appli ont la même tête quelque soit la plateforme : c'est moche.

C'est le cas pour AWT, mais swing à bien evolué et continue d'évoluer à chaque version. Bien sur il est un peu en retard, mais il reste tout à fait valable pour beaucoup d'appplications.

hibou :
Après y'a SWT qui lui utilise les wigets de la plateforme, ce qui fait que c'est bien plus performant, bien mieux intégré, bien plus joli, cf eclipse. En plus avec SWT et les eclipse-product, c'est hyper facile de faire ca petite appli standalone sans qu'on remarque que y'a de l'eclipse derrière. Je connaissais un peu SWT et le mécanisme de plugin, j'ai refait les 3/4 de l'appli luke (http://www.getopt.org/luke/) en 2 jours.

Pour moi en JAVA le natif c'est plus ou mois Swing. QT, SWT,... on beau être natif par rapport au sytème, il ne le sont pas pas rapport à l'environement. Ils nécessiteront d'utiliser des binaires supplémentaires dépendants du système, pas vraiment dans l'esprit JAVA.
Pour moi si on veut faire du natif, autant prendre un langage fait pour ça et ne pas se retrouver avec une bête hybride binaire/bytecode qui nécessitera quand même une JVM et n'ira pas beaucoup plus vite.

JackosKing :
Sinon dans swing faut coder soit même une classpour trier les éléments d'un tableau :/

Des petits problèmes comme ça, on en trouve dans presque tous les environemments.

Pour moi QT est génial quand on fait du C++ et que l'on veut du natif, vu qu'il apporte ce qui manque au C++ par rapport à JAVA : une API simple, efficace et multiplateforme.
Mais je ne vois pas l'interet de l'utiliser en JAVA vu que tout ca est déjà dans l'API JAVA sans rien avoir à ajouter.

Uther
:

hibou :
Pour moi swing est complètement dépassé. Les widgets supporté par swing sont des wigets implémenté en Java pour toutes les plateforme : les appli ont la même tête quelque soit la plateforme : c'est moche.

C'est le cas pour AWT, mais swing à bien evolué et continue d'évoluer à chaque version. Bien sur il est un peu en retard, mais il reste tout à fait valable pour beaucoup d'appplications.

ca fait 1 an ou 2 que j'ai pas touché à du Swing, mais à l'époque c'était bien moche : peut-être aussi parce que je l'utilisais pas correctement , au vu du screenshot précédent.

hibou :
Après y'a SWT qui lui utilise les wigets de la plateforme, ce qui fait que c'est bien plus performant, bien mieux intégré, bien plus joli, cf eclipse. En plus avec SWT et les eclipse-product, c'est hyper facile de faire ca petite appli standalone sans qu'on remarque que y'a de l'eclipse derrière. Je connaissais un peu SWT et le mécanisme de plugin, j'ai refait les 3/4 de l'appli luke (http://www.getopt.org/luke/) en 2 jours.

Pour moi en JAVA le natif c'est plus ou mois Swing. QT, SWT,... on beau être natif par rapport au sytème, il ne le sont pas pas rapport à l'environement.

C'est bizarre que tu dises "natif par rapport à Java". Avec Java, y'a le natif, code "assembleur", et le Java, non ?

Ils nécessiteront d'utiliser des binaires supplémentaires dépendants du système, pas vraiment dans l'esprit JAVA.

de la même manière qu'il te faut une jvm...

Pour moi si on veut faire du natif, autant prendre un langage fait pour ça et ne pas se retrouver avec une bête hybride binaire/bytecode qui nécessitera quand même une JVM et n'ira pas beaucoup plus vite.

??? Il est de réputation et de constatation que Swing est plus lent que les lib qui utilisent les widgets natif.

JackosKing :
Sinon dans swing faut coder soit même une classpour trier les éléments d'un tableau :/

Des petits problèmes comme ça, on en trouve dans presque tous les environemments.

Pour moi QT est génial quand on fait du C++ et que l'on veut du natif, vu qu'il apporte ce qui manque au C++ par rapport à JAVA : une API simple, efficace et multiplateforme. Mais je ne vois pas l'interet de l'utiliser en JAVA vu que tout ca est déjà dans l'API JAVA sans rien avoir à ajouter.

Si ton appli dépend d'autres libraries qui sont elles en Java par exemple ? Parce que les développeurs que tu as sous la main sont des codeurs Java ?

Uther
:

Sasume :
La différence est dans l'API. Le mécanisme de Qt pour gérer les évènements (signals/slots) est quand même plus souple que celui de SWING (listeners), mais c'est tout ce que je peux dire.

Moi personellement je préfère les listener, c'est peut-être une question de gout.

Moi ce qui me chagrine un peu dans les listeners, c'est par exemple ce qu'il se passe quand on veut gérer l'évènement de fermeture d'une fenêtre (windowClosing()), on doit écrire un listener qui implémente l'interface WindowListener, qui comporte 8 fonctions, alors qu'une seule nous intéresse. Alors il y a la solution des WindowAdapter, mais je ne trouve pas ça très élégant...
De plus, quand on écrit des widgets personnalisés (ce qui arrive assez souvent), il faut qu'on écrive beaucoup plus de code que l'équivalent Qt pour gérer une liste de listener et leur dispatcher les évènements comme il faut. Ce n'est pas compliqué, mais c'est très répétitif (d'ailleurs il existe peut-être des outils qui font ça automatiquement ?).

Alors que Qt élargit le C++, en étendant le concept d'objet, permettant d'exposer des propriétés, et les signals et slots qui permettront aux autres composants de les utiliser.
Par contre, ce qui est un peu laid à mon goût, c'est justement le fait que tout ça ne soit qu'une surcouche du langage C++, gérée par un préprocesseur et un pseudo-compilateur (moc), qui donne un aspect un peu bricolé à l'ensemble (ce qui ne serait pas le cas, si le langage intégrait déjà toutes ces notions intrinsèquement).

Voilà, sinon, pour ce qui est des APIs de Qt ou Swing, j'ai beaucoup de mal à les juger, parce que d'une part je ne les connais pas sur le bout des doigts, et d'autre part, je manque de recul pour vraiment analyser ça d'un oeil avisé.

hibou
:

Pour moi en JAVA le natif c'est plus ou mois Swing. QT, SWT,... on beau être natif par rapport au sytème, il ne le sont pas pas rapport à l'environement.

C'est bizarre que tu dises "natif par rapport à Java". Avec Java, y'a le natif, code "assembleur", et le Java, non ?

Ils nécessiteront d'utiliser des binaires supplémentaires dépendants du système, pas vraiment dans l'esprit JAVA.

de la même manière qu'il te faut une jvm...

Ben justement ce qui est intéressant dans Java à mon avis, c'est que la JVM t'offre la possibilité d'exécuter tout programme Java.
Et dans le cas de Qt Jambi, effectivement, la JVM ne suffira pas à lancer les programmes, il faudra ajouter ce qui ne fait pas partie de la JVM standard.

Sasume
:

Uther
:

Sasume :
La différence est dans l'API. Le mécanisme de Qt pour gérer les évènements (signals/slots) est quand même plus souple que celui de SWING (listeners), mais c'est tout ce que je peux dire.

Moi personellement je préfère les listener, c'est peut-être une question de gout.

Moi ce qui me chagrine un peu dans les listeners, c'est par exemple ce qu'il se passe quand on veut gérer l'évènement de fermeture d'une fenêtre (windowClosing()), on doit écrire un listener qui implémente l'interface WindowListener, qui comporte 8 fonctions, alors qu'une seule nous intéresse. Alors il y a la solution des WindowAdapter, mais je ne trouve pas ça très élégant...

En général tu as toujours un espèce de DummyWindowListener que tu peux étendre non ?

Par contre, ce qui est un peu laid à mon goût, c'est justement le fait que tout ça ne soit qu'une surcouche du langage C++, gérée par un préprocesseur et un pseudo-compilateur (moc), qui donne un aspect un peu bricolé à l'ensemble (ce qui ne serait pas le cas, si le langage intégrait déjà toutes ces notions intrinsèquement).

Hummm, je ne vois pas trop ce que tu sugères à la place... augmenter le langage Java ?

Voilà, sinon, pour ce qui est des APIs de Qt ou Swing, j'ai beaucoup de mal à les juger, parce que d'une part je ne les connais pas sur le bout des doigts, et d'autre part, je manque de recul pour vraiment analyser ça d'un oeil avisé.

idem, moi je suis payé pour coder les trucs qui ne se voient pas.

Sasume
:

hibou
:

Pour moi en JAVA le natif c'est plus ou mois Swing. QT, SWT,... on beau être natif par rapport au sytème, il ne le sont pas pas rapport à l'environement.

C'est bizarre que tu dises "natif par rapport à Java". Avec Java, y'a le natif, code "assembleur", et le Java, non ?

Ils nécessiteront d'utiliser des binaires supplémentaires dépendants du système, pas vraiment dans l'esprit JAVA.

de la même manière qu'il te faut une jvm...

Ben justement ce qui est intéressant dans Java à mon avis, c'est que la JVM t'offre la possibilité d'exécuter tout programme Java.
Et dans le cas de Qt Jambi, effectivement, la JVM ne suffira pas à lancer les programmes, il faudra ajouter ce qui ne fait pas partie de la JVM standard.

C'est vrai qu'en y réfléchissant, Java tourne sur énormément de plateforme, notemment tout ce qui est embarqué, tel mobiles... Mais Qt aussi ! http://fr.wikipedia.org/wiki/Qtopia

hibou :
C'est bizarre que tu dises "natif par rapport à Java". Avec Java, y'a le natif, code "assembleur", et le Java, non ?

Oui mais je ne vois pas le problème exactement comme ca.
En utilisation normale le JAVA doit être "write once run anywhere" donc une application JAVA normale ne doit dépendre uniquement de la JVM dans laquelle elle est executée.
Introduire du code natif au système va induire une fonctionnement non conforme au but de JAVA. C'est pour ca que je l'ai appellé non natif par rapport à JAVA.

hibou :
??? Il est de réputation et de constatation que Swing est plus lent que les lib qui utilisent les widgets natif.

Je n'ai pas dit que Swing était rapide mais SWT n'est pas une flèche non plus. Eclipse est plus rapide que Netbeans par exemple mais il reste quand même très lent.

Sasume :
Moi ce qui me chagrine un peu dans les listeners, c'est par exemple ce qu'il se passe quand on veut gérer l'évènement de fermeture d'une fenêtre (windowClosing()), on doit écrire un listener qui implémente l'interface WindowListener, qui comporte 8 fonctions, alors qu'une seule nous intéresse. Alors il y a la solution des WindowAdapter, mais je ne trouve pas ça très élégant...
De plus, quand on écrit des widgets personnalisés (ce qui arrive assez souvent), il faut qu'on écrive beaucoup plus de code que l'équivalent Qt pour gérer une liste de listener et leur dispatcher les évènements comme il faut. Ce n'est pas compliqué, mais c'est très répétitif (d'ailleurs il existe peut-être des outils qui font ça automatiquement ?).

Pour les WindowAdapter je ne vois pas en quoi c'est plus genant d'utiliser ça qu'un WindowsLinener.
Pour le coté verbeux, j'utilise Netbean qui s'occupe pour moi de génerer tout le code compliqué et verbeux. Netbean 5.x est un vrai bonheur pour faire des applications swing.

Sasume :
Alors que Qt élargit le C , en étendant le concept d'objet, permettant d'exposer des propriétés, et les signals et slots qui permettront aux autres composants de les utiliser.
Par contre, ce qui est un peu laid à mon goût, c'est justement le fait que tout ça ne soit qu'une surcouche du langage C , gérée par un préprocesseur et un pseudo-compilateur (moc), qui donne un aspect un peu bricolé à l'ensemble (ce qui ne serait pas le cas, si le langage intégrait déjà toutes ces notions intrinsèquement).

Oui quand je disais que je n'aime pas les signaux, c'est plus ça que le principe même des signaux que je n'aime pas.

Uther
:

hibou :
??? Il est de réputation et de constatation que Swing est plus lent que les lib qui utilisent les widgets natif.

Je n'ai pas dit que Swing était rapide mais SWT n'est pas une flèche non plus. Eclipse est plus rapide que Netbeans par exemple mais il reste quand même très lent.

Je pense que le fait qu'Eclipse soit lent n'a en rien avoir avec la couche SWT. Eclipse est conçu pour être méga réutilisable, donc plein de listeners génériques de partout, les stack traces sont énormes, etc...
Après, question pref entre Qt et SWT, je pense que Qt doit être mieux loti car bien plus mature.