Qt 4.5 sera sous licence LGPL 2.1

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
32
14
jan.
2009
KDE
Ce 14 janvier 2009, Qt Software (une branche de Nokia créée suite au rachat de Trolltech en janvier 2008), la fondation FreeQt et KDE e.V. sont fiers d'annoncer que la version 4.5 de Qt, dont la sortie est prévue pour le premier trimestre 2009, ne sortira pas seulement sous les licences "habituelles" GPL 2/3 ou QPL, mais aussi sous la licence LGPL 2.1. Cela permettra donc par exemple de réaliser des applications propriétaires utilisant Qt sans devoir pour autant disposer d'une licence commerciale de Qt. Il s'agit là de la fin définitive d'un troll vieux de plus de 10 ans sur les licences de Qt.

Rappel : Qt est la bibliothèque de base de l'environnement graphique KDE, programmée en C++ et disponible sur la majorité des plate-formes du marché (X11, Microsoft Windows, MacOS X, en embarqué via Qtopia sur GNU/Linux ou encore Windows CE…).

NdM : signalons aussi que la bibliothèque GTK+, considérée comme l'autre grande bibliothèque graphique, est également sous licence LGPL 2.1. Et merci à GeneralZod qui a aussi proposé une dépêche sur le sujet. Ce changement de licence de Qt s'accompagne également d'une ouverture supplémentaire du développement de Qt : désormais, le code source de Qt sera disponible dans un dépôt Git, permettant de suivre plus aisément son développement. Ce changement a été réalisé dans le cadre de l'initiative "Qt Everywhere" : Qt Software s'engage à retirer tout ce qui peut s'opposer à l'utilisation de Qt, quand c'est réalisable. Cela inclut donc les problèmes de licence. Il ne s'agit pas d'un abandon de Qt par Nokia, bien au contraire : Nokia peut se passer des revenus des licences commerciales de Qt, ce que Trolltech ne pouvait pas se permettre.

GeneralZod ajoute :
«
Cette décision est parfaitement cohérente avec la stratégie globale de Nokia de créer un ensemble de briques libres pour l'industrie dont Symbian et Qt sont les fers de lances.

Le rachat puis la libération de Symbian ont permis à Nokia d'avoir une offre logicielle concurrente viable face aux plateformes mobiles Android, LiMo, OpenMoko et les propriétaires Windows CE, iPhone OS tout en redynamisant le développement de celui-ci.
La place de Qt dans tout ça est d'offrir un framework de développement multiplateforme permettant de supporter avec le même code source (ou presque) la plupart des environnements cités précédemment.

Cela est confirmé par les portages de Qt vers Windows CE, S60, la mise en avant de Qt Extended (ex-Qtopia, plateforme embarqué basé sur Linux), l'intégration de composants tels que WebKit (moteur de rendu web), Phonon (framework multimédia), QtAnimation (framework d'animation repoussé à Qt 4.6 mais également disponible séparément).

Qt 4.5 sera accompagné d'un RAD multiplateforme Qt Creator (actuellement en béta), Nokia met clairement le paquet pour faire de Qt LA plateforme de référence pour le développement d'applications mobiles et sur le desktop.
»

Aller plus loin

  • # Qt passe en LGPL et adopte un modèle de dévelopement ouvert

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

    Je me suis fait doubler pour ma dépêche, voilà le texte comme ça ce n'est pas perdu:

    Qt_Software (anciennement Trolltech) a annoncé aujourd'hui que la prochaine version de Qt vera l'ajout de la licence LGPL v2.1. L'annonce indique aussi qu'un nouveau mode de développement sera bientôt mis en place, permettant des contributions directes au dévelopement de Qt.

    Pour rappel, Qt est un framework multi-platforme qui facilite la création d'applications de bureau. Ce framework est connu pour être à la base de KDE mais il est aussi utilisé dans de nombreux projets hors KDE (VLC, Skype, Google Earth, etc).

    À partir de la version 4.5, qui devrait sortir en mars, Qt sera sous triple licence: LGPLv2.1, GPLv3 et commerciale. L'ajout de la licence LGPL vient apporter un changement fondamental pour les développeurs qui commercialisent une version fermée de leur logiciel, il leur sera désormais possible d'utiliser Qt sans payer de licence.

    La licence GPL devrait rester la licence la plus populaire pour les projets libre mais il est probable que de nombreux projets adopteront la LGPL à cause de leur modèle de distribution (Mozilla Firefox par exemple).

    Qt Software prévoit aussi d'ouvrir le développement de Qt. Il sera bientôt possible de contribuer directement à la base de code de Qt. Ce changement risque d'être déterminant pour la réactivité de correction de bugs, et les nouvelles fonctionnalités de la bibliothèque.





    Avec ce changement de licence, Nokia espère multiplier le nombre de dévelopeurs utilisant Qt. Plus de développement sur Qt devrait amener plus d'application (commerciale ou libre) sur Linux. De nombreux client de Nokia ont choisissent Qt pour la facilité de développement sous Windows ou Mac, et fournissent finallement un version Linux de leurs logiciels.

    La licence commerciale est conservée pour les développeurs d'application qui ne souhaitent pas se soumettre aux obligations de la LGPL. Et Nokia continuera à vendre du support.

    Concernant l'ouverture du mode de développement, peut d'informations sont encore dévoilées. D'après le site web, les dépots seront ouverts (probablement comme on a pu le voir avec Qt creator).

    On a pu voir une intenssification du dévelopement avec Qt 4.5, et il est probable que l'ouverture des dépots accellerera encore les choses. La FAQ indique aussi que ces changements visent aussi à améliorer encore la qualité de Qt.

    La licence des version de Qt inférieure à 4.5 restera inchangée.


    http://www.qtsoftware.com/about/news/lgpl-license-option-add(...) Annonce officielle
    http://dot.kde.org/1231920504/ Annonce de KDE
    http://www.qtsoftware.com/about/licensing/frequently-asked-q(...) FAQ

    http://aseigo.blogspot.com/2009/01/qt-goes-lgpl.html Blog du président de KDE eV
    http://labs.trolltech.com/blogs/2009/01/14/nokia-to-license-(...) Blog du dirrecteur de Qt Software
  • # Ha zut...

    Posté par  . Évalué à 8.

    Heureusement, il reste de bon vieux trolls bien poilus et indestructible.

    Vi rules, Emacs sucks!

    A vous :D

    Plus sérieusement, ce passage sous LGPL est une bénédiction pour les microISV/startups qui ne peuvent se payer la licence pour chaque développeur, même si ladite licence n'est pas si chère comparée au gain de productivité obtenu avec Qt.
    • [^] # Re: Ha zut...

      Posté par  . Évalué à 4.

      Ou tout simplement (pour rester dans le débat autour de Qt) :
      "Gnome ça pue y a qu'un bouton, KDE ça roxxxe y a plein d'options partout !"
      • [^] # Re: Ha zut...

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

        Il reste toujours le très classique « Qt ça pue, c'est pas du vrai C++ » :D
        • [^] # Re: Ha zut...

          Posté par  . Évalué à 3.

          Pour certains, ne pas être du vrai C++ est plutôt une qualité. Enfin pour tout le monde, en fait, à l'exception des "vrais" pluspluseurs, pour qui un bon programme est un programme fait à plus de 95% de templates :)
          • [^] # Re: Ha zut...

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

            Le but n'est pas d'augmenter la quantité de template, mais d'augmenter la quantité de RAII pour réduire, entre autres, la quantité de pointeurs (bruts).
        • [^] # Re: Ha zut...

          Posté par  . Évalué à 2.

          Regarde après le traitement du moc, c'est bien du vrai C++ (d'ailleurs G++ ne s'en plaint pas). Le moc est juste là pour permettre au développeur de coder certaines choses plus clairement et simplement.

          Comment ça j'ai marché dedans!
          • [^] # Re: Ha zut...

            Posté par  . Évalué à 2.

            Le seul truc que je me souviens de Qt et de KDE.

            C'est le temps de compilation pour un pauvre projet qu'on avait délloppé.

            Le passage pré-processor qui génère plein de ligne de code , çà me fait penser à la news/fiction sur le développement LFR en J2EE.

            Enfin ,je dis çà mais çà a probablement changé. C'était à l'époque de QT 2...

            PS: Mince, moli aussi j'ai marché dedans.
            • [^] # Re: Ha zut...

              Posté par  . Évalué à 3.

              Dans un projet QT tu as interet à utiliser des headers precompilés sinon effectivement les temps de compilation peuvent devenir abominables.
              Mais avec les headers precompilés (pour éviter de reparser et les temps de compilations redeviennent raisonnables.

              Dans ton fichier .pro, il suffit d'ajouter:

              CONFIG += precompiled_header
              PRECOMPILED_HEADER = mon_fichier_entete.hpp
        • [^] # Re: Ha zut...

          Posté par  . Évalué à 4.

          Oui mais le C++ c'est pas du vrai C.
          • [^] # Re: Ha zut...

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

            Et le C, c'est pas de l'assembleur
            • [^] # Re: Ha zut...

              Posté par  . Évalué à 2.

              Et l'assembleur c'est pas du binaire!

              On est arrivé au bout je crois.
              • [^] # Re: Ha zut...

                Posté par  . Évalué à 5.

                .. et non pas encore : le binaire, ça n'est pas du silicium ;o)
  • # Version

    Posté par  . Évalué à 3.

    LGPL 2.1 et pas 1.2, si ? (dans le texte et le titre)

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Version

      Posté par  . Évalué à 3.

      En effet, j'ai rédigé la dépêche hier soir à partir du mail d'Aaron Seigo, et il a fait la faute de frappe, que j'ai bêtement copié...
  • # Sauf que ...

    Posté par  . Évalué à 2.

    sous la licence LGPL 1.2. Cela permettra donc par exemple de réaliser des applications propriétaires utilisant Qt sans devoir pour autant disposer d'une licence commerciale de Qt

    La LGPL ne semble pas être très appréciée par les vendeurs de logiciels propriétaires (contrairement aux BSD, Apache et autres MIT).

    Du moins c'est ce que je constate dans le monde Java (oui ce n'est pas le sujet ici).
    Et ne me demandez pas pourquoi le sujet semble complexe, en tout cas trop pour moi :-)
    • [^] # Re: Sauf que ...

      Posté par  . Évalué à 3.

      Pour la plupart des entreprises, la licence LGPL passe relativement bien. Contrairement à Qt Extended, très peu d'entreprises ont besoin de patcher Qt, et encore moins ont d'intérêts à ne pas publier ses patchs.
      Pour les plus réfractaires, Qt offre toujours une licence commerciale.
      Personnellement, je suis curieux de savoir si Qt Software compte libérer tout les add-ons (notamment ActiveQt, ou bien l'intégration à Visual Studio), qui propulserait encore plus l'adoption de Qt.
      • [^] # Re: Sauf que ...

        Posté par  . Évalué à 2.

        Qt Extended ne passe pas LGPL d'apres la FAQ:
        Does the licensing change apply to Qt Extended?
        No, the licensing change does not apply to Qt Extended.

        Vous etes bien d'accord avec moi? contrairement à ce qui est écrit dans la dépèche....

        Pour une entreprise qui fait de l'embarqué par QT Extended en LGPL, est-ce la seule contrainte est le non-support et la diffusion des modifs de QT Extended?
      • [^] # Re: Sauf que ...

        Posté par  . Évalué à 2.

        Je précise ce que je voulais dire.
        Dans le monde dans lequel je bosse (Java donc), j'ai l'impression que la licence LGPL n'est que très rarement acceptée par les éditeurs de propriétaire, y compris quand ils ne font qu'utiliser, et ne modifie pas la librairie.
        • [^] # Re: Sauf que ...

          Posté par  . Évalué à 1.

          C'est effectivement étrange, pourquoi ce refus de la LGPL ? Confusion avec la GPL ? frilosité ? absence de support ?
          • [^] # Re: Sauf que ...

            Posté par  . Évalué à 3.

            Je réponds par la même occasion à trois_1 qui pose une question similaire en dessous.

            Je pense que c'est principalement du à une mauvaise compréhension de la LGPL.
            Les éditeurs de logiciels proprio sont très frileux (du moins leurs avocats) quant aux impacts que peut avoir la licence d'une bibliothèque utilisée sur l'ouverture ou non de leur code. Et sur l'impact que cela peut éventuellement avoir sur le code de leurs clients.
            On va dire qu'ils préfèrent prévenir que de se taper des complications.
            La LGPL en fait les frais à cause de l'ambiguité qu'il y a eu à une certaine époque sur la notion de "lien" qui est plutôt claire en C ou C++ par exemple mais pas en Java.
            Même si il y a eu des précisions depuis ça reste dans l'air.

            De plus je viens de jeter un oeil à http://www.gnu.org/licenses/lgpl-java.fr.html pour avoir plus d'infos.
            Et quand je lis :

            Les applications ne doivent suivre que les conditions de la section 6 de la LGPL : autoriser de nouvelles versions de la bibliothèque à être liées avec l'application et de permettre la rétro-ingénierie pour déboguer cela.

            Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.
            La licence Apache (au hasard) n'a pas ce genre de contraintes ou d'ambiguités.

            J'espère que ça vous éclaire un peu sur mon contexte :-)
            • [^] # Re: Sauf que ...

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

              Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.

              Ah bah ils arrêtent de distribuer en France alors ? Parce qu'en France, il est encore autorisé de procéder à de la rétro-ingénierie à des fins d'interopérabilité. Les clauses l'interdisant sont illégales et sautent d'elles-mêmes...
              • [^] # Re: Sauf que ...

                Posté par  . Évalué à 1.

                Ne pas souhaiter ne veut pas dire que tu peux l'interdire, ni que tu vas arrêter de distribuer pour autant :-)
            • [^] # Re: Sauf que ...

              Posté par  . Évalué à 1.

              Auriez-vous une explication sur ce que j'ai noté avec Qt extended (ex-QTopia)??

              Est-ce aussi LGPL?
              • [^] # Re: Sauf que ...

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

                Ils se gardent une source de revenu. Si tu veux mettre du Qt Extended dans ton téléphone, il faut négocier avec Qt Software. Cela dit, aujourd'hui, la plupart des matériels n'ont plus besoin de la version extended.
                • [^] # Re: Sauf que ...

                  Posté par  . Évalué à 2.

                  A quel seuil de ressource estime-tu ne plus avoir besoin de QT-extended?

                  En RAM, ROM, puissance?
            • [^] # Java par définition s'est Open Source

              Posté par  . Évalué à 1.

              Java :proprietaire ou non.

              Si tu veux faire de la rétro-ingénierie. Tu n'es pas trop ennuyer.
              Un programme qui a même été brouillé reste très lisible.

              Il suffit de partir du mapping sur un SGBDR. Tu utilises outil qui te permet du refactoring dans tous les sens et le tour est joué.

              En plus, si l'éditeur a utilisé des lib qui utilise la réflexivité dans tous les sens (Hibernate, Struts, Tags jsp). Une grande partie des méthodes ne seront pas brouillé.

              Bref un programme Java, c'est par définition Open Source.

              A côté un programme PHP peux être vraiment illisible(... même sans le passage par le brouilleur).
              • [^] # Re: Java par définition s'est Open Source

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

                Un programme java peu tout aussi bien être codé avec les pieds qu'un programme PHP et inversement.

                Rien ne m'empêche de placer du html au milieu de mon code java en mélangeant tout au total méprit du sacro saint MVC.

                Avoir le bytecode d'un code propre, ce n'est pas de l'OpenSource, qui à une définition précise.
                • [^] # Re: Java par définition s'est Open Source

                  Posté par  . Évalué à 2.

                  > Avoir le bytecode d'un code propre, ce n'est pas de l'OpenSource, qui à une définition précise.

                  Ce n'est pas un critique sur le langage que je soumettais même si j'en pense pas moins.

                  Il existe des brouilleurs automatique de code PHP qui peuvent rendre le code réellement illisible.

                  Il te sera au final plus facile de faire du reverse sur code Java que sur un code PHP.

                  - Le nom typage des variables.
                  - L'interprétation dynamique

                  aide beaucoup pour réaliser un bon brouilleur.
        • [^] # Re: Sauf que ...

          Posté par  . Évalué à 1.

          Pourquoi est-ce qu'ils n'acceptent pas la licence LGPL? quels contraintes?
    • [^] # Re: Sauf que ...

      Posté par  . Évalué à 1.

      expliquez moi, je suis pas très familier avec toutes ces histoires de de licences...

      donc avant, un mec qui voulait faire un programme propriétaire (donc ne fournissant pas ses sources, mais pas nécessairement payant) devait payer une licence

      maintenant, on peut faire un programme proprio et le vendre sans payer de licence? ou la gratuité est valable seulement si tu ne fais pas de pognon avec... (parce que ça me semblerait normal que si quelqu'un veut faire du pognon avec ton travail... qu'il te remercie de ton travail par une petite dringuelle!)
      • [^] # Re: Sauf que ...

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

        En gros il peut faire un logiciel proprio et le vendre sans payer de licence, à condition:
        - de fournir Le code source des modifications apporté dirrectement à Qt s'il y en a;
        - de permettre à l'utilisateur d'utiliser son logiciel avec une version modifiée de Qt (i.e: pas de liaison statique)

        [Gros résumé]
      • [^] # Re: Sauf que ...

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

        C'est tout à fait ça, avant il y avait les licences GPL et proprio.

        Avec la GPL, tu peux faire du libre, tu ne payes pas, mais ça doit rester GPL.
        Avec la licence proprio, tu peux faire ce que tu veux, mais tu payes.

        Avec la LGPL, tu ne peux pas faire ce que tu veux (le code de Qt doit rester libre), mais tu peux lier ton programme proprio à Qt sans payer.

        Pourquoi est-ci si important d'éviter de payer une licence?
        Premièrement pour les petits développeurs qui se lancent sans savoir si leur projet va réussir, ils pourront se lancer sans payer les frais d'entrées d'une licence.
        Deuxièmement pour toutes les entreprises radines qui ferait tout pour payer moins (et ils y en a beaucoup). Eux j'espère que si ils profitent de Qt, ils auront la décence de publier aussi des binaires pour Linux, ce qui augmentera la force de l'écosystème.

        Finalement, les entreprises qui ne veulent pas prendre trop de risques continueront à payer du support et à acheter des licences pour être sûr que leurs problèmes soient réglés rapidement.
        • [^] # Re: Sauf que ...

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Deuxièmement pour toutes les entreprises radines qui ferait tout pour payer moins (et ils y en a beaucoup). Eux j'espère que si ils profitent de Qt, ils auront la décence de publier aussi des binaires pour Linux, ce qui augmentera la force de l'écosystème.

          Je présume que les boîtes radines ne changeront pas leur plateformes cible simplement parce que QT a changé de licence. Lorsqu'on vend une application et qu'on souhaite la distribuer sur différentes plateformes, il y a d'une part le développement qui doit être multi-plateforme, mais il y a aussi les installeurs, le support, etc. Et le développement, au final, c'est la partie visible de l'iceberg (je ne parle même pas de société radine, là, en fait).

          Dans ma boîte, on développe des applis qui tournent sous linux et windows. On supporte Windows XP et la série des OS à base RedHat (RedHat, CentOS, Fedora, etc). Mais pas Mandriva par exemple. Ni Debian, ni Ubuntu, ni ... Pourtant ça compile et ça tourne sous Debian. C'est une question de packaging, de support. Quand un client a un problème, il faut le reproduire. On est une petite structure, donc on n'a pas toutes les plateformes/tous les OS à disposition, et/ou les compétences spécifiques à chaque OS/distribution.
          • [^] # Re: Sauf que ...

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

            Je me suis laissé emporté par mon optimisme :)

            Ce que je vois maintenant, c'est des amis qui galère sur des trucs comme MFC ou Carbon+Cocoa. Leur boîte ne proposera jamais de solution en dehors de l'OS de départ parce qu'ils ont fait l'erreur de se bloquer sur une plateforme.

            Si ils commencent sur la plateforme X avec Qt (puisque maintenant c'est gratuit), et qu'un client demande si ils peuvent l'utiliser sur la plateforme Y, ce sera du domaine du possible. Et j'espère que Y ce sera Linux :)

            J'avoue que tout n'est pas aussi facile, il suffit de voir le nombre d'application Java qui ne fonctionnent que sur une seule plateforme...
  • # rms ?

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

    Qu'en pense RMS ? N'est-ce pas plutot une mauvaise nouvelle pour tous les purs à durs à poil long du Logiciel Libre ?
    • [^] # Re: rms ?

      Posté par  . Évalué à 4.

      Il doit s'en battre les roubignoles:
      1. la licence GPL est conservée.
      2. la licence LGPL reste une licence GNU.
      3. même si la LGPL est moins appréciée que sa grande soeur la GPL, c'est considéré comme un mal nécessaire pour permettre l'interopérabilité entre le libre et le propriétaire.
      4. RMS cherche à créer un écosystème libre auto-suffisant et utilisable par tous, et non pas à exterminer le logiciel propriétaire.
    • [^] # Re: rms ?

      Posté par  . Évalué à 2.

      Il n'aime pas la LGPL, sur le fond je pense qu'il n'a pas tord.
      J'attends avec impatience sa réaction.
  • # arrêter de comparer les carottes aux poireaux !!

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

    Un jour il faudra arrêter de comparer une bibliothèque sympa de graphique : GTK+ avec une bibliothèque multiplateforme complète de développement de logiciel, gérant nativement : le son, les vidéos, le svg, le tout en restant multiplateforme : Qt.
    • [^] # Re: arrêter de comparer les carottes aux poireaux !!

      Posté par  . Évalué à 8.

      La comparaison Gtk+/Qt est à la fois non pertinente et pertinente.
      Non pertinente, parce que l'équivalent de Qt c'est GLib/Cairo/Gtk+/GStreamer/GtkWebKit/libxml2 etc ...
      Pertinente, car si Qt est un framework unifié maintenue par une entité (Qt Software), on peut considérer que l'ensemble des bibliothèques autour de Gtk+ constituent un framework à part entière dont le ciment est GObject et qui offre (en pratique) également une vraie cohérence.

      Moi, j'apprécie les 2 plateformes, la première pour son côté tout-en-un (framework extrêmement complet, outils associés performants), la seconde pour la possibilité de réutiliser séparément les différents composants, son dynamisme (D-Bus, Telepathy, GEGL, Gnome-Scan etc ...).
      La différence principale c'est le modèle de développement, Qt est clairement une cathédrale (et une magnifique!), alors que Gtk+ & cie c'est le bazar. Chaque modèle à ses qualités et défauts, et Qt s'ouvre un peu plus au bazar.
      • [^] # Re: arrêter de comparer les carottes aux poireaux !!

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

        Il y a quelques approximations dans ce que tu dis.

        Ni cairo, ni libxml2 ne sont basés sur GObject (<troll>et tant mieux</troll>).

        Qt est très bien séparé en module et les modules sont tous indépendants.
        • [^] # Re: arrêter de comparer les carottes aux poireaux !!

          Posté par  . Évalué à 4.

          Certes, mais ils font quant même partie de la toolbox du développeur Gtk+, Gtk+ s'appuie principalement sur les primitives de dessins de Cairo (le GDK fournit des fonctions d'interopérabilité avec Cairo), et libxml2 c'est le parseur xml du projet GNOME. ;-)
          Si il n'y a pas de wrappers GObject, c'est que d'une part, l'utilité ne s'est pas fait sentir, d'autre part pour des raisons de performances. Par exemple, GStreamer utilise en interne GstMiniObject (GObject moins les fonctionnalités inutiles pour GStreamer) et non GObject comme classe de base pour des raisons de performances.

          > Qt est très bien séparé en module et les modules sont tous indépendants.
          Seulement depuis Qt4, c'était beaucoup moins drôle avec Qt3.
          Ce que je voulais dire, c'est qu'il est plus facile d'introduire dans un projet une bibliothèque GObject qu'une bibliothèque Qt même si c'est faisable.
    • [^] # Re: arrêter de comparer les carottes aux poireaux !!

      Posté par  . Évalué à -3.

      Je n'ai pas bien compris ce que tu voulais dire.
      Tu peux être plus clarifié, stp ?
  • # Qt4 dans OpenOffice.org

    Posté par  . Évalué à 9.

    Il y a une demande des utilisateurs qu'OpenOffice.org soit programmé en Qt4 mais c'était impossible car OOo est sous LGPL et Qt était uniquement sous GPL. Désormais, c'est possible. La communauté n'a plus qu'à se réfléchir à cela.
    • [^] # Re: Qt4 dans OpenOffice.org

      Posté par  . Évalué à 1.

      Je ne vois pas le problème la LGPL étant 100% compatible avec la GPL. Le seul truc serait qu'un port de la VCL (le toolkit d'OOo, à ne pas confondre avec le machin de Borland) vers Qt4 aurait été sous GPL (et là encore, je ne vois pas le problème).
      Néanmoins, je vois pas vraiment l'intérêt de ce port, OOo est une usine à gaz, KOffice 2.0 (ainsi que la plupart des applications KDE4) est censé être multiplateforme et Qt 4.5 intégrera un support d'OpenDocument (Suffisant pour écrire un mini-traitement de texte sur plateforme mobile ;o) ). Quant à l'intégration visuelle, il y a le moteur de style gtk-qt ou on peut opter pour QGtkStyle.
      Même en chargeant les libs KDE4, KOffice 2.0 reste moins lourdingue qu'OOo
      • [^] # Re: Qt4 dans OpenOffice.org

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

        Même si je suis d'accord qu'un suite office directement en Qt serait bien mieux, il n'en reste pas moins qu'avoir OOo en Qt serait génial.

        OOo est une usine à gaz, mais il est bien répandu et il a plus de fonctionnalité que KOffice 2. Utiliser Qt pour OOo aurait du sens selon moi.
      • [^] # Re: Qt4 dans OpenOffice.org

        Posté par  . Évalué à 1.

        Sun voulait peut-être pouvoir continuer à vendre StarOffice sans avoir à en donner le code source ?
        • [^] # Re: Qt4 dans OpenOffice.org

          Posté par  . Évalué à 4.

          Maintenant ils peuvent faire cela.

          Maintenant niveau travail. Un portage vers Qt est énorme et donc long, mais cela peut offrir nombres d'avantages comme faire du nettoyage dans le "bouzin" (dixit les nombreux commentaires sur le code) et très certainement le rendre plus réactif.
          • [^] # Re: Qt4 dans OpenOffice.org

            Posté par  . Évalué à 1.

            Cela se fera sûrement pour OpenOffice.org 4.0 !
          • [^] # Re: Qt4 dans OpenOffice.org

            Posté par  . Évalué à 2.

            Il me semblait qu'un certain nombre de composant d'OO étaient ou devaient être en Java, qu'en est-il ?

            Au fait Qt Jambi va t'il lui aussi être distribué sous LGPL ?
            Ca va peut-être booster son adoption sur Java face à l'ugly SWT et au heavy Swing
    • [^] # Re: Qt4 dans OpenOffice.org, et FireFox ?

      Posté par  . Évalué à 2.

      Firefox et Thunderbird qt pour une meilleure intégration dans kde ça serait génial aussi :)
      Il semble que Nokia travaille dessus mais ce n'est pas intégré à ce jour dans les distro principales.
      http://www.paperblog.fr/973155/mozilla-firefox-3-porte-sous-(...)
    • [^] # Re: Qt4 dans OpenOffice.org

      Posté par  . Évalué à 6.

      Bonjour,

      Ayant moi-même beaucoup contribué au port natif Mac OS X (aka Aqua), je connais bien vcl ( voir les liens plus bas), et ayant découvert aujourd'hui seulement l'éxistence du passage à la LGPL de Qt, grâce à Eric Bischoff (cf mon blog : http://eric.bachard.free.fr/news ), je pense que ce n'est pas si simple :

      1) pour les widegets : ok, ca doit marcher, et c'est portable. Tout le monde est d'accord avec ça.

      2) pour les polices et les devices virtuels, et plein d'autres choses qui sont utilisées par tout OpenOffice.org, c'est déjà moins clair

      3) l'interaction avec svx et sfx2 est pour le moins problèmatique

      4) enfin, comme l'a bien mis en évidence Malte Timmermann, qui gère l'accessibilité (une grande force de la version 3.0 sous Mac OS X ! ), dans le mail que j'indique sur mon billet de blog, et bien là, c'est pas sûr du tout : la faisabilité dépend a priori du port concerné.

      Dans tous les cas, c'est un boulot monstre qui attend les dévs d'OpenOffice.org, qui ne sont pas si nombreux, enfin, vous voyez ce que je veux dire ...

      Désolé d'avoir modéré l'enthousiasme de certains, mais à part un gros changement, je ne vois pas ça dans un futur proche pour OpenOffice.org

      Une vieille documentation sur vcl, sans code :
      http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_(...)

      Note: SalOpenGL et SalSound sont obsolètes aujourd'hui, et pour OpenGL (surtout pour Impress), on fait autrement .

      Une documentation assez vieille, mais faite avec Doxygen (attention, décompressé, c'est assez énorme :
      http://eric.bachard.free.fr/mac/aquavcl/documentation/doc_06(...)

      Me demander pour quelque chose de plus récent
  • # Et on est pas le 1er avril !

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

    J'ai hâte d'être dans un an ou deux pour voir ce que cela va donner : j'espere qu'il y aura un bon "écosystème", plus de développeurs, plus de librairies tierces, plus de logiciels multiplateformes.

    En tout cas ils veulent créer une vrai communauté cf FAQ : pourrais je contribuer à Qt ? Oui, absolument. Nous travaillons sur les détails finaux de notre modèle de contribution

    Il est prevu que Qt-4.5 sorte en mars cf FAQ

    D'après http://labs.trolltech.com/blogs/2009/01/14/nokia-to-license-(...)
    Nous continuerons d'évaluer l'adoption, l'utilisation et l'interprétation légale de la LGPLv3 par la communauté et
    peut être utiliser la LGPLv3 pour les prochaines releases


    Pendant un quart de seconde j'ai pensé qu'on était un 1er avril :D
    Finalement c'est une bonne chose que Nokia est racheté Trolltech !
  • # S'ils avaient voulu il y a wxWidgets qui est en LGPL

    Posté par  . Évalué à -1.

    S'ils avaient voulu tout aurait pu être codé en utilisant wxWidgets et qui n'est pas si mal que ça même comparé à Qt. Donc pourquoi ils changeraient maintenant...
    • [^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL

      Posté par  . Évalué à 5.

      A côté des fonctionnalités de Qt, wxWidgets fait très primaire. Sans oublier la documentation qui est une des grandes forces de Qt.

      Concernant la qualité de l'API de wxWidgets (que je n'ai pas utilisé), j'ai lu à plusieurs reprise qu'ils avaient voulu trop copier les MFC et qu'au final la qualité n'était pas souvent au rendez-vous.

      En résumé, Qt est sur bien des points très en avance sur tous ses concurrents.
      • [^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL

        Posté par  . Évalué à 6.

        En particulier un des reproches fait à wxWidgets est son mécanisme de callback qui s'apparente aux MFC en face du mécanisme de signaux/slot de Qt.

        Le leader du toolkit FOX en parle mieux que moi
        http://www.fox-toolkit.org/faq.html#CALLBACKS

        Il y a aussi le fait que wxWidget s'appuie(yait) pas mal sur les toolkits natifs au lieu de s'appuyer que sur un noyau de primitives graphiques portées pour chaque plateforme.
        Ceci a l'inconvénient d'avoir un aspect et un comportement moins homogène pour les widgets réutilisés et pas réécrits. Et la création d'un nouveau widget pas commun à plusieurs plateformes nécessite une réécriture pour chaque plateforme au lieu de s'appuyer sur les primitives de base.

        Je crois que ca a changé avec les dernières versions mais ces erreurs de jeunesse pèsent et laissent une impression d'API héteroclite
        • [^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL

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

          Il y a aussi le fait que wxWidget s'appuie(yait) pas mal sur les toolkits natifs au lieu de s'appuyer que sur un noyau de primitives graphiques portées pour chaque plateforme.
          Ceci a l'inconvénient d'avoir un aspect et un comportement moins homogène pour les widgets réutilisés et pas réécrits.


          Tiens, c'est justement ce qui me plait chez WxWidgets: l'application semble plus "native" que sous Qt (qui est déja bien, mais moins "native" parfois)

          Comme quoi, les goûts et les couleurs ;-)

          Mais effectivement, en pratique, ça amène quelques galères, comme la limitation au plus petit commun dénominateur graphique (ça plus le manque dévolution comparé à Qt... A force, je vais basculer, j'y passerai bientôt!)
          • [^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL

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

            Pour mon information, aurais tu un exemple de chose qui parait plus « native » avec WxWidgets que avec Qt ?
            • [^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL

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

              Pour un exemple basique de chez basique, sous Windows (sans prendre les nouvelles barre à la Office, encore différentes, le Toolkit Windows évoluant aussi):
              - Une application "native" ou Wx aura le menu ouvert (Ouvrir, Fermer...) avec une couleur légèrement différente de la barre de menu. Sous Qt, même couleur.
              - Quand on passe la souris sur un menu avec une icône, une application aura le fond du texte en bleu, le fond de l'icône en gris. Sous Qt, l'ensemble (Texte + icône) a un fond bleu.
              J'ai pris vite fait ces exemples sur VLC pour Qt, il y en a plein comme ça.

              C'est du détail, vraiment du détail, mais c'est ce qui fait qu'un utilisateur se sens "chez lui".
              Et je re-précise : c'est du détail. Car comparé à GTK, on est sauvé (un windowsien touchant à une appli GTK qui n'a pas pris la peine de changer la boite "Ouvrir un fichier" et de changer le thème par défaut va s'enfuir en courant au bout de 30s à cause l'interface horriblement non intégrée et du menu "Ouvrir"...), une interface Qt n'est pas si dérangeante que ça et je me motive depuis quelque temps pour mettre mon passage à Qt dans le haut de ma ToDo list.
  • # Youhouu !

    Posté par  . Évalué à -2.

    Chouette, on va peut-être enfin voir la fin de GTK. Et surtout de ses prosélytistes à la con qui se croient obligés d'y faire référence alors que la dépèche ne concerne que QT.
    • [^] # Re: Youhouu !

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

      Et peut être même qu'un jour on verra la fin des commentaire de personnes qui se sentent obligé de parler de GTK dans les news de Qt juste pour cracher sur les personnes qui apprécient le premier.

      L'espoir fait vivre.
    • [^] # Re: Youhouu !

      Posté par  . Évalué à 6.

      Et pour ceux qui parlent de QT (c'est à dire QuickTime) dans une dépêche sur Qt, on fait quoi ?
  • # Qt == killer app ?

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

    Et si finalement Qt était la killer app [1] tant attendue ? celle qui permettrait à Linux d'être crédible et de percer enfin (cad de mon point de vue atteindre entre 5 et 10% de PDM)

    On a longtemps cru que ce serait une application classique genre Amarok, Gimp ou Apache, pourquoi pas une librairie ou un langage (PHP par ex) ?
    Pour reprendre un commentaire sur Slashdot :
    having used GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt, I have to say that Qt beats the others [2]

    On a donc :
    - un toolkit bien meilleur que les autres
    - gratuit et libre pour tous
    - des supers outils (Qt Creator, Qt Designer)
    - disponible partout même sur les téléphones
    - supporte plein de langages (C++, Java, Python...)
    - et surtout financé par Nokia qui a les moyens de ces ambitions : "Qt Everywhere"
    Et je pense que Nokia a beaucoup d'ambitions pour Qt : LGPL, recrutement de développeurs, portage sur pleins de nouvelles plateformes...

    On peut toujours rêver mais l'idée me plait :-)
    Et la cerise sur le gâteau : un Windows 7 pire que Vista :p

    [1] http://fr.wikipedia.org/wiki/Killer_app
    [2] http://tech.slashdot.org/comments.pl?sid=1091547&cid=264(...)
    • [^] # Re: Qt == killer app ?

      Posté par  . Évalué à 3.

      C'est clair à mon avis que Qt a un potentiel énorme. Tant mieux si ça permet de mettre tout le monde d'accord :).

Suivre le flux des commentaires

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