Journal Qt Jambi abandonné pat Qt Software

Posté par  (Mastodon) .
Étiquettes : aucune
4
24
fév.
2009
http://www.qtsoftware.com/about/news/preview-of-final-qt-jam(...)

C'est dans l'annonce de la preview de Qt Jambi 4.5 que Qt Software annonce que ce sera la dernière version officielle.

Le support continuera pendant un an après la release et pendant ce temps Qt Jambi sera donné à la communauté.

Pour rappel, Qt Jambi est la version Java de Qt. Il existe une intégration de Qt Designer dans Eclipse, et il est même possible d'utiliser des classes Qt C++ dans un programme en Qt Jambi. En bref, le boulot a été très bien fait et c'est vraiment agréable de programmer avec Qt Jambi.

C'est donc dommage qu'il soit plus ou moins abandonné, car l'absence de support officiel ne va pas aider à une plus grande adoption par les programmeurs Java.

  • # Qyoto

    Posté par  . Évalué à 2.

    Et que devient Qyoto ? Ça fait longtemps qu'on attend un support officiel de la part de Qt Software !

    https://www.ohloh.net/p/qyoto

    • [^] # Re: Qyoto

      Posté par  . Évalué à 2.

      Qyoto/Kimono ce ne sont pas des projets KDE utilisant smoke ?
      D'ailleurs, le gros reproche que je puisse faire des bindings utilisant smoke, c'est d'être dépendant des kdelibs (du moins le binding ruby). Peut-être que je me trompe (et vous êtes cordialement invité à le faire si vous avez plus de renseignements), mais la dépendance aux kdelibs, pour un gnomers c'est "no pasaran".

  • # Utilité de QtJambi

    Posté par  . Évalué à 0.

    Autant la version C++ et le binding Python sont une évidence, autant j'ai toujours été dubitatif sur QtJambi. A côté des poids lourds qui existent en Java (Swing et SWT), je ne voyait pas trop l'intérêt.

    Maintenant, je n'ai quasiment jamais développé en Java. Et je dois avouer que je n'ai jamais trouvé ce langage très sexy... Ma question est donc pour ceux qui développent en Java et ont utilisés QtJambi : La version Java de Qt apportaient-elle un véritable plus à l'environnement Java?

    • [^] # Re: Utilité de QtJambi

      Posté par  (site web personnel) . Évalué à 5.

      Elle apporte la même chose que plusieurs toolkit pour le C/C++/langage de ton choix.

      Par contre pour tout ce qui est en dehors du toolkit graphique (classe thread etc se trouvant aussi dans QT) là par contre je vois pas l'intérêt... mais je crois que QTJambi se cloisonne juste au binding des composants GUI.

      Sinon j'ai jamais personnellement utilisé jambi, mais il y a 3 ans j'avais utilisé le binding java de qt3 pour essayer mais vu le fait que ce binding était très très peu documenté, pas vraiment portable (la lib jni était compilable sous linux... mais pas réussi sous windows), j'ai abandonné ce binding. Et comme je fais plus vraiment de GUI actuellement, la question ne se pose pas.

      • [^] # Re: Utilité de QtJambi

        Posté par  . Évalué à 1.

        Le problème surtout de Jambi c'est dès que tu veux le redistribuer.

        "Allez allez cliquez sur mon .jnlp. Wai, un .jar de 20Mo par plateforme juste pour un hello world, tu vas pas te plaindre non plus."

        • [^] # Re: Utilité de QtJambi

          Posté par  (site web personnel) . Évalué à 6.

          "Allez allez cliquez sur mon .jnlp. Wai, un .jar de 20Mo par plateforme juste pour un hello world, tu vas pas te plaindre non plus."

          Exactement comme Python, et Python est un langage dont il ne faut pas médire ici car parfait extra génial sans défaut, donc je ne vois pas pourquoi une caractéristique de Python serait un inconvénient une fois qu'on remplace "Python" par "Qt".
          Ou alors tu es prêt à critiquer Python et te faire descendre ici? ;-)

          PS : sinon, je ne vois pas l'utilité de QtJambi quand même : le gros intérêt de JAva est justement que la machine virtuelle comprend déjà "tout" et est multi-OS, donc Qt n'apporte pas d'avantage par rapport à l'existant...

          • [^] # Re: Utilité de QtJambi

            Posté par  (site web personnel) . Évalué à 3.

            PS : sinon, je ne vois pas l'utilité de QtJambi quand même : le gros intérêt de JAva est justement que la machine virtuelle comprend déjà "tout" et est multi-OS, donc Qt n'apporte pas d'avantage par rapport à l'existant...

            Bin peut-être parce que les avantages d'un framework comme Qt sont si énormes qu'ils rendent acceptables le téléchargement du runtime par les clients.

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à 3.

            Je sais pas, mais je te sens amer ;)

            • [^] # Re: Utilité de QtJambi

              Posté par  (site web personnel) . Évalué à 0.

              Ah zut, c'était pas l'impression que je voulais donner.
              Je me voulais plutôt moqueur (ça me fait plus rire qu'autre chose, après Perl, après Java-mais-ça-pue-c'était-pas-libre, après PHP, après Ruby-On-Rail, maintenant Python... Qui sera le suivant?), zut!
              Comme quoi, faire passer un sentiment n'est pas toujours facile par écrit!

          • [^] # Re: Utilité de QtJambi

            Posté par  (site web personnel) . Évalué à 2.

            Alors qu'en perl, ça s'écrirait en une ligne. :P

      • [^] # Re: Utilité de QtJambi

        Posté par  . Évalué à -1.

        Elle apporte la même chose que plusieurs toolkit pour le C/C++/langage de ton choix.

        De la confusion?

    • [^] # Re: Utilité de QtJambi

      Posté par  . Évalué à 5.

      Parce que Swing c'est de l'API qui a provoqué des morts. Et SWT n'a pas de designer convi.

    • [^] # Re: Utilité de QtJambi

      Posté par  (Mastodon) . Évalué à 7.

      Qt Jambi reprend toute l'API Qt, alors c'est sûr que c'est redondant avec les libs Java, mais pour le dev, c'est pas vraiment un problème, Qt étant bien découpé, tu utilises la partie que tu veux.

      Et pour la partie gestion graphique, c'est quand même un bonheur d'utiliser Qt avec son système de signaux plutôt que Swing : Qt est quand même largement au dessus ! Il n'y a par exemple pas d'équivalent à QGraphicsView dans Swing.

      Ensuite, vient avec Qt un moteur de rendu HTML multiplateforme (Webkit), un API son (Phonon), etc ...

      Qt Jambi apporte aussi un designer digne de ce nom avec Qt Designer parfaitement intégré à Eclipse.

      Bref, les avantages sont nombreux, et ceux qui connaissent Qt comprendront.

      • [^] # Re: Utilité de QtJambi

        Posté par  . Évalué à 3.

        Et pour la partie gestion graphique, c'est quand même un bonheur d'utiliser Qt avec son système de signaux plutôt que Swing : Qt est quand même largement au dessus !

        Question de style... Je préfère les listeners aux signals/slots Qt, car on a moins de surprises à l'exécution.

        Il n'y a par exemple pas d'équivalent à QGraphicsView dans Swing.

        Et Java2D alors?

        Ensuite, vient avec Qt un moteur de rendu HTML multiplateforme (Webkit), un API son (Phonon), etc ...

        JWebPane et Java Media Framework?

        • [^] # Re: Utilité de QtJambi

          Posté par  . Évalué à 2.

          Et c'est quoi ces "surprises à l'exécution"? Les signaux/slots ça fonctionne très bien pour moi.

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à 3.

            La connexion entre un signal et un slot se fait en donnant leurs signatures sous forme de chaînes de caractères. La compatibilité entre les deux n'est donc vérifiée qu'à l'exécution. Ca ne me choque pas si on fait du PyQt, mais quand en Java ou C++, c'est dommage.

        • [^] # Re: Utilité de QtJambi

          Posté par  . Évalué à 1.

          Tu connais un endroit où on peut récupérer ce JWebPane?
          Parce que jusqu'à présent tout ce que j'ai vu sur les blogs des développeurs de sun c'est que c'est pour plus tard et on aurait bien besoin de ça pour pouvoir abandonner les immondes hack qui intègrent le moteur de firefox avec un heavyweight component.

    • [^] # Re: Utilité de QtJambi

      Posté par  . Évalué à 4.

      Ne pas utiliser la Java Class Library ? (Pour moi, ça constitue un avantage énorme)
      À la différence de la JCL, Qt4 n'a pas à se soucier d'un historique plutôt encombrant au nom de la compatibilité ascendante. Sans oublier les outils associés (le generator pour générer le code glue, Qt linguist, Qt designer etc ...). Le seul truc qui m'ennuie un peu, c'est l'absence de qmake.
      Quant aux développeurs Qt auquels les décideurs pressés ont imposés Java, de retrouver leurs marques rapidement. :o)

      L'abandon de Qt Jambi était prévisible dans une certaine mesure: pas de béta de Qt Jambi 4.5, les blogs des employés de Qt Software était relativement silencieux à ce sujet, pas de support de QtJambi dans Qt Creator.
      QtJambi c'est une bonne idée mais il y a tellement de chantiers dans Qt entre le développements de nouveaux outils, de nouvelles classes ou modules, les portages qu'il a fallu couper dans certains projets. C'est dommage, car QtJambi venait de commencer à percer auprès des développeurs, mais ce n'est pas critique car le C++ à la sauce Qt c'est quand même bien prémâché et ça n'a pas les inconvénients de Java.
      Qt, c'est un peu le meilleur des 2 mondes.

      • [^] # Re: Utilité de QtJambi

        Posté par  . Évalué à 3.

        > Ne pas utiliser la Java Class Library ? (Pour moi, ça constitue un avantage énorme)

        Pourquoi pas. Mais dans ce cas je suis surpris de ne pas voir Java-gnome comme un élément de l'abandon de Qt Jambi. Java-gnome a toujours été un binding supporté par gtk+ et gnome. L'api est de qualité. Java-gnome est aussi un très bon plugin eclipse.

        • [^] # Re: Utilité de QtJambi

          Posté par  (site web personnel) . Évalué à 3.

          Oui mais non...

          GTK ne propose qu'un toolkit GUI... pas de truc pour gérer le réseau, les threads, le xml, le render html etc comme le propose QT...

          Maintenant je vois vraiment mais vraiment pas l'intérêt d'utiliser ces classes QT en lieu et place des thread java + synchronize, de l'api java.net, java.io ou autre.

          GTK vs QT GUi ok pour le reste pas d'accord... mais je suis pas d'accord non plus avec le commentaire d'au-dessus qui préconiserait d'utiliser ces classes QT au lieu de la lib standard.

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à 5.

            QT c'est QuickTime

            Qt : c'est le truc en C++ de Trolltech/Nokia

            voili, voilu

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à -1.

            > GTK ne propose qu'un toolkit GUI...

            Ben oui. Ce n'est pas un OS :-)

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à 3.

            > GTK ne propose qu'un toolkit GUI... pas de truc pour gérer le réseau, les threads, le xml, le render html etc comme le propose QT...

            Gtk+ repose sur la GLib, donc t'as une gestion du réseau, un parseur xml (certes sommaire), des threads et pleins d'autres trucs intégrés. Pour le reste, t'as une multitude d'APIs complémentaire basés sur la GLib qui forme un ensemble cohérent (GStreamer, Webkit-Gtk, libsoup, Clutter, GNet etc ...), l'exception étant libxml.
            Tu n'as pas totalement tort en disant que Gtk+ n'est pas l'équivalent de Qt, mais la toolbox du développeur Gtk+ est aussi riche que celle du développeur Qt qui dépuis Qt4 est découpé en modules.
            Pour simplifier QtCore # GLib, QtGui #Gtk+, QNetwork # GNet, etc ...


            > je suis pas d'accord non plus avec le commentaire d'au-dessus qui préconiserait d'utiliser ces classes QT au lieu de la lib standard.

            La JCL traine pas mal de boulets, et je trouve personnellement l'API Qt (ou Gtk+) nettement plus agréable à utiliser. QtJambi a fait des choix plutôt intelligents, par exemple, ils utilisent le type Java.String plutôt que QString, on peut mélanger les classes d'I/O, bref, ça s'intégre plutôt bien dans une application Java standard. C'est loin d'être un binding bête et méchant qui t'impose ses choix fascistes.
            Je n'incite pas plus à utiliser QtJambi que la JCL, Java-Gnome, SWT ou autre chose, chacun fait ce qu'il veut, ce n'est pas mon problème.
            On a la chance d'avoir le choix entre plusieurs APIs de qualité (et libres), avec chacune des avantages et des inconvénients, donc autant choisir celle qui nous convient le mieux selon nos besoins et nos expériences.

            Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java mais on serait hors sujet. ;o)

            • [^] # Re: Utilité de QtJambi

              Posté par  . Évalué à 2.

              > Tu n'as pas totalement tort en disant que Gtk+ n'est pas l'équivalent de Qt, mais la toolbox du développeur Gtk+ est aussi riche que celle du développeur Qt qui dépuis Qt4 est découpé en modules

              La grosse différence est que Gtk ne veut pas être un "tout en un". Certes on trouve du thread, etc. Mais c'est surtout pour des raisons de portabilité ou pour avoir une API de plus haut-niveau. De plus, c'est au niveau de la glib.
              Gtk c'est glib + cairo + pango + etc. Gtk n'a pas wrappé toutes les fonctions de cairo en gtk_cairo..., etc. Gtk utilise Cairo. C'est tout.
              Développer avec Gtk/Gnome demande de "jongler" avec différentes API. Tu fais du son, tu utilises Gstreamer, tu fais du graphique, tu utilises Cairo, etc. Avec Qt il n'y a qu'une API. Est-ce bien ou mal ? J'ai un petit faible pour la philosophie Gtk.
              Gtk se base sur des standards, Gtk ne veut pas faire son standard universel.

              > Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java

              Peux-tu développer ?
              C'est une chose de dire "je préfère X à Y" et une autre de dire "il faut abandonner Y".
              Je connais très peu Java. Mais je suis très satisfait d'Eclipse (pour coder en C++).

              • [^] # Re: Utilité de QtJambi

                Posté par  . Évalué à 4.

                La grosse différence est que Gtk ne veut pas être un "tout en un".

                Certe qt le veut, même si la plupart des features sont séparés dans des libs séparés. La force de qt est AMHA sa cohérence, qui tourne presque entierrement autour de QtCore et surtout son implémentation du pattern observer. C'est perso ce qui m'a fait préférer qt a boost, malgré quelques défauts (un preproc très lent notament, signaux/slots non utilisables dans les templates sans "petites bidouilles", etc...)

                • [^] # Re: Utilité de QtJambi

                  Posté par  . Évalué à 2.

                  Je veux préciser que Qt est formidable !
                  Pas de doute. J'ai seulement un petit faible pour gtkmm. Mais je n'irais pas dire qu'on peut faire plus de chose avec gtkmm, ou qu'il est plus productif.

        • [^] # Re: Utilité de QtJambi

          Posté par  . Évalué à 2.

          Ça dépends, tu as deux générations du binding Java-Gnome, la branche 2.x et la branche 4.x.
          Si tu me parles de la première génération que fournissent toutes les distributions, elle est non seulement obsolète mais je ne m'avancerais pas à dire que l'API est de qualité.
          Andrw Cowie d'Operational Dynamics [1] avait fait une présentation (au Guadec notamment) pour expliquer pourquoi Java-Gnome 2.x était une impasse.
          Quant à la seconde génération, c'est clairement mieux foutue (c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie) mais ça n'avance pas niveau intégration dans les distributions. Si ça t'intéresse, au niveau de Fedora, c'est le ticket 438452.


          Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).
          Si tu ajoutes ça au manque de polish, pas de distributions clés-en-main pour Windows, MacOS X (en dehors de GNU/Linux, Solaris[2], c'est un peu l'inconnu), une doc spartiate comparé à celle fournis par Qt Software (avec des exemples non triviaux), l'absence de bindings des APIs complémentaires (Clutter, Gstreamer [3], etc ...) Java-Gnome va encore avoir du mal à se diffuser malgré toutes ses qualités.

          Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.


          [1] Son blog est une mine d'information sur Java-Gnome
          http://research.operationaldynamics.com/blogs/andrew/softwar(...)
          [2] en même temps, j'en ai rien à battre de Windows.
          [3] il y a un binding Gstreamer-Java non officiel mais il ne s'intégre pas vraiment à Java-Gnome.

          • [^] # Re: Utilité de QtJambi

            Posté par  . Évalué à 5.

            > Ça dépends, tu as deux générations du binding Java-Gnome, la branche 2.x et la branche 4.x.

            Je ne connais pas Java-gnome...
            Quand je parlais d'une bonne API, je pensais surtout à Gtk2 (avec glib, cairo, etc).

            > c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie

            En passant, j'ai passé du temps sur Gtkmm, j'ai adoré. Et pourtant j'étais un adèpte de Qt pour coder en C++. Mais Gtkmm c'est du bon et très élégant (d'un point de vu codeur C++).

            > Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).

            On peut dire plus largement que Java ne fait pas un carton dans la communauté. Très utilisé par les entreprises, très peu par la communauté.
            C'est vraiment dommage.

            > Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.

            Je ne crois pas. Sûr on peut dire qu'il manque le binding pour bidule, qu'il n'y a pas de port pour machin, etc.
            Le coeur de problème, à mon avis, est que Java n'est pas perçu comme un language pour les applis graphiques/desktop.
            Voir par exemple http://java-gnome.sourceforge.net/4.0/ qui ne peut s'empêcher de faire un référence au web :
            We believe that while the web is ideal for offering services, only carefully tailored desktop applications can provide a truly rich user experience that is both responsive and usable.
            Aujourd'hui Java est un language quasi idéal pour le libre. Mais l'historique de Java dans le libre est assez mauvais (la java trap, gcj pas très satisfaisant, etc). Java a créé de nombreuses frustrations.
            Tous les projets complexes ont besoin d'être supportés par une entreprise. Red Hat, Sun, IBM pour Java restent concentré sur les serveurs.
            On peut aussi s'amuser à comparer avec Mono. Hors l'aspect brevet/FUD/MS, Mono n'a pas créé de frustration et Novell a (aussi) cblé de suite le desktop. Il y avait une dynamique dans Mono que Java n'a jamais eu dans le libre (Sun y avait la main mise, c'était proprio, etc).

            Le problème est surtout là. A mon avis les raisons que tu avances ne sont que des conséquences. Avis subjectif.

  • # Inquiétude

    Posté par  (site web personnel) . Évalué à -3.

    Ce qui m'inquiète un peu plus, c'est la suite des évènements. Pour cette version Jambi est abandonner, pour la prochaine, ce sera Qt pour Linux/Win32/MaxOs, pour que seul la partie embarqué ne reste, car ils n'ont plus le temps de tout gérer ?

    • [^] # Re: Inquiétude

      Posté par  . Évalué à 6.

      n'importe quoi. nokia laisse qtjambi a la communauté, avec tout les sources. si ce port Qt a des adeptes, il sera maintenu. Après tout, QtJambi est aujourd'hui compris. il suffit "juste" de suivre les évolutions de Qt.

      le choix de nokia est de se concentrer sur Qt. Les bindings de Qt il y en a plein et sont assurés par la communauté.

      • [^] # Re: Inquiétude

        Posté par  . Évalué à 2.

        De plus Nokia est devenu un "Patron" de KDE (http://ev.kde.org/supporting-members.php ). C'est un gage de leur implication je trouve.

        • [^] # Re: Inquiétude

          Posté par  . Évalué à 5.

          Mouais, Mark Shuttleworth aussi est "patron" de KDE , on voit ce que ça donne avec kubuntu ...

          • [^] # Re: Inquiétude

            Posté par  . Évalué à 2.

            On voit que la distribution Kubuntu est officiellement supportée par Canonical. C'est plutôt un engagement fort.

            Si tu veux lancer un troll sur la qualité de distribution Kubuntu, attend vendredi.

            • [^] # Re: Inquiétude

              Posté par  . Évalué à 6.

              "Supporter" est un bien grand mot...
              À la limite, on peut dire que les kubunteros supportent sans (trop) broncher le travail dégueulasse fait par Canonical.
              Mais cette dernière ne supporte pas vraiment KDE : un seul développeur à plein-temps, un travail d'intégration proche du néant, des bugs qui n'existent pas en mainstream...
              Désolé, mais mon expérience de Kubuntu m'a clairement dégouté de cette distrib' et presque dégouté de ce bureau, et c'est en passant à d'autres (Mandriva, OpenSuse puis ArchLinux) que j'ai réalisé qu'en fait c'était l'intégration qui était merdique.

            • [^] # Re: Inquiétude

              Posté par  . Évalué à 6.

              > On voit que la distribution Kubuntu est officiellement supportée par Canonical.

              Définition de supporté par Canonical :
              - "Si on dit que c'est supporté, alors ça l'est !"

  • # Dommage

    Posté par  (site web personnel) . Évalué à 1.

    Pour un projet avec une entreprise, on avait le choix entre une solution Java/Swing, Qt/C++ ou Qt Jambi. Personnellement j'aurais bien aimé Qt jambi mais finalement on a décidé ce matin de choisir Qt C++.

    C'est vraiment dommage que Qt Jambi s'arrête. J'ai un peu programmé avec (des petits programmes exemple) et c'était vraiment agréable. Et niveau langage, je préfère à priori Java à C++ (même si heureusement le C++ utilisé avec Qt est une version simplifiée)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.