Sortie de Qt 4.5

Posté par . Modéré par baud123.
Tags :
33
3
mar.
2009
KDE
Qt 4.5, la bibliothèque C++ libre et multiplate-forme (UNIX, Mac OS X, Windows et Windows CE) sur laquelle se base KDE vient de sortir.

C'est la première version en LGPL, permettant ainsi de l'utiliser même pour un développement propriétaire.

Cette version apporte nombre d'améliorations après le gros bond en avant de la précédente version majeure, la 4.4. En même temps que la sortie de cette version, Qt Software (qui est un département de Nokia), distribue la première version stable de son environnement de développement intégré, Qt Creator. Qt est une bibliothèque C++ et Java. Mais cette dernière version ne sera plus maintenue officiellement par Qt Software et son évolution sera à la charge de la communauté.

Utilisée principalement en C++, Qt est bien plus qu'une simple bibliothèque graphique car elle regroupe (en vrac) :
  • Du réseau et un moteur de rendu HTML basé sur Webkit ;
  • Du XML ;
  • De la base de données ;
  • Du multimédia via Phonon (uniquement en lecture pour l'instant) ;
  • QtScript, un langage de script (basé sur JavaScript) ;
  • De l'OpenGL ;
  • Qt Linguist, pour l'internationalisation ;
  • La gestion des threads ;
  • Un système de test unitaires ;
  • Qt Designer, un créateur d'interface ;
  • etc.

Pour les nouveautés de Qt 4.5 :
  • Mise à jour de QtWebkit : le nouveau moteur JavaScript est présent, les greffons Netscape sont utilisables (bonjour Flash !), les nouvelles balises du HTML 5 sont utilisables et utilisent Phonon ;
  • Diverses améliorations des performances et l'apparition d'une bibliothèque mesurant les performances, QtBenchLib ;
  • L'utilisation de Cocoa pour la version Mac OS X ;
  • L'utilisation de Phonon et QtWebkit pour Windows CE ;
  • Un moteur de transformation XSLT ;
  • Un débogueur pour QtScript ;
  • L'écriture de fichier OpenDocument ;
  • Une meilleure intégration pour les environnements utilisant GTK ;
  • Diverses améliorations dans Qt Linguist, Qt Designer, les performances graphiques, etc.

En résumé, Qt c'est bon, mangez-en !
  • # Erreurs de français

    Posté par . Évalué à  3 .

    Il n'y a pas moyen de corriger les quelques erreurs/coquilles de ma dépêche. Car il faut avouer que dans le feu de l'action j'ai laissé passer de grosses bévues. Et j'ai honte!!!
    • [^] # Re: Erreurs de français

      Posté par (page perso) . Évalué à  5 .

      en reste-t-il ? j'en ai profité pour wikipédifier un peu ;-)
      Faut pas croire, mais tous les relecteurs ne sont pas forcément bons en orthographe :D ('fin ça peut se faire après coup, la preuve :p).
      • [^] # Re: Erreurs de français

        Posté par . Évalué à  5 .

        Il reste ceci : "Utilisé principalement en C++" qui devrait être au féminin : "Utilisée principalement en C++".

        Merci.
  • # Re: Sortie de Qt 4.5

    Posté par (page perso) . Évalué à  10 .

    « C'est la première version en LGPL, permettant ainsi de l'utiliser même pour un développement propriétaire. »

    Il était déjà possible de l'utiliser pour faire du dévelopement propriétaitaire.
    La différence c'est que avant il fallait payer une licence et que maintenant c'est gratuit.
    (Il est toujours possible de payer une licence si on souhaite du support)
    • [^] # Re: Sortie de Qt 4.5

      Posté par (page perso) . Évalué à  5 .

      Le support n'est pas la seule raison de se payer une licence. Pouvoir fermer tout le code donne beaucoup de souplesse, c'est capital les gros projets. Je ne pense pas que tout le monde est prêt à fournir ses patchs en LGPL.
  • # PyQt

    Posté par . Évalué à  2 .

    J'espère que PyQt passera aussi en LGPL, ça me permettrais d'apprendre à développer en QT au boulot et aussi à faire des applis avec un vrai toolkit multi-plateforme parce que wxPython c'est pas la panacée.
    • [^] # Re: PyQt

      Posté par (page perso) . Évalué à  2 .

      En QT? En QuickTime?

      Maintenant que c'est gratuit, je pense que les SSII ou co vont y penser sérieusement. Il faut juste que les devs réveillent un peu les chefs de projets au moment des choix de techno pour choisir Qt.
      • [^] # Re: PyQt

        Posté par (page perso) . Évalué à  2 .

        Même si PyQt ne passe pas en GPL, la licence ne coûte que 300 livres. C'est dans le budget d'une PME.
        • [^] # Re: PyQt

          Posté par . Évalué à  -1 .

          Même si PyQt ne passe pas en GPL, la licence ne coûte que 300 livres. C'est dans le budget d'une PME.

          D'une PME peut-être, d'une start-up non ...
          • [^] # Re: PyQt

            Posté par . Évalué à  2 .

            Hein, si tu devais développer une application Windows avec les MFC, ce n'est pas 350€ et des poussières qu'il te faudrait débourser.
            Avant la LGPL-isation de Qt 4.5, pour développer un logiciel privateur en PyQt, il fallait débourser le prix de la licence Qt (entre 2000€ et 3000€/développeur) et de la licence PyQt. C'était réellement un frein à la progression de PyQt en entreprise, là, ça l'est beaucoup moins.

            Pour le moment, rien n'est décidé l'unique mainteneur évalue les options qui s'offrent à lui
            Hein, n'oublions que RiverBank n'a pas la solidité financière de Nokia et qu'il faut bien payer les factures à la fin du mois. Ce serait un poil ingrat d'exiger de Phil Thompson de relicencier PyQt sans certitude que son énorme travail soit rétribué à sa juste valeur.

            L'idéal serait que Qt Software décide de sponsoriser PyQt mais on n'aura très probablement la réponse qu'à la sortie de PyQt 4.5
            • [^] # Re: PyQt

              Posté par . Évalué à  2 .

              L'idéal serait que Qt Software décide de sponsoriser PyQt mais on n'aura très probablement la réponse qu'à la sortie de PyQt 4.5

              Evidemment ce serait l'idéal pour les dev Python, mais il ne faut vraiment pas compter là dessus, car entre l'abandon de Qt Jambi et celui de Qt Extended, je doute fort que Nokia ait dans l'idée de promouvoir un autre binding alors qu'ils abandonnent les projets "périphériques" à la louche...
          • [^] # Re: PyQt

            Posté par . Évalué à  6 .

            > > Même si PyQt ne passe pas en GPL, la licence ne coûte que 300 livres. C'est dans le budget d'une PME.

            > D'une PME peut-être, d'une start-up non ...

            c'est une farce ? c'est la moitié ou le tiers du prix d'une machine de dev ou d'un portable pour faire des demos chez les gentils gens qui lacheront les sous ensuite.
            • [^] # Re: PyQt

              Posté par (page perso) . Évalué à  3 .

              Bien que je sois sur le principe d'accord avec toi, je tiens quand même à préciser que dans le cas d'une startup, la machine perso sert souvent de machine de dev ou portable de démonstration (c'est mon cas en tous cas!), et donc que 300€ payé à quelqu'un d'autre, c'est 300€ de moins pour le salaire, et ça peut se voir (dans mon cas, ça aurait été une augmentation de 100% de mon investissement, car j'ai dû payer dans les 300€ de frais d'enregistrement de l'entreprise, et 100% d'augmentation du budget investissement ce n'est pas neutre!)

              Bon, certes, c'est pour chipoter, car si on est à 300€ près, c'est mal parti même pour une startup! (vu toutes les charges qu'il y a ensuite :) )
          • [^] # Re: PyQt

            Posté par . Évalué à  4 .

            Et si je veux diffuser mon logiciel en BSD je peux le faire avec une licence proprio de PyQt?
            • [^] # Re: PyQt

              Posté par . Évalué à  2 .

              Oui, tant que l'ensemble est licencié sous une licence compatible avec la GPL, ce qui est le cas de la licence BSD? c'est OK.
              Là, où ça se corse, c'est si tu incorpore ton code BSD dans un ensemble sous une licence privatrice ou incompatible avec la GPL (ce que te permet la licence BSD), là, tu es obligé d'acheter une licence commerciale de PyQt.

              Tu n'as pas le droit de faire tourner une application GPL avec la version privatrice de PyQt à moins de rajouter une clause d'exception de liens avec des bibliothèques non-libres.

              Donc en résumé:
              * les sources peuvent rester sous licence BSD.
              * si je lie mon application avec la version GPL de PyQt, l'ensemble passe sous GPL.
              * si je lie mon application avec la version privatrice, je fais comme je veux sauf à utiliser la licence GPL nue.
              • [^] # Re: PyQt

                Posté par (page perso) . Évalué à  1 .

                Bon, le terme "privateur" a déjà été débatu ici.

                Mais en quoi la licence payante de PyQt est elle privatrice ?
                Laquelle des 4 libertés prétendues fondamentales n'est pas réspectée ?
                • [^] # Re: PyQt

                  Posté par . Évalué à  2 .

                  > Laquelle des 4 libertés prétendues fondamentales n'est pas réspectée ?
                  Toutes potentiellement. La licence commerciale de PyQt est modelé sur celle de Qt [1]
                  * Liberté d'exécuter le programme.
                  ==> Cf plus bas, royalties
                  * Liberté d'étudier le fonctionnement du programme
                  ==> certains bouts de la version commerciale de Qt/PyQt ne sont pas libres notamment ActiveQt. Si tu veux vérifier, lance la démo webbrower.py dans le répertoire ActiveQt et lis le message qui s'affiche.
                  * Liberté de redistribuer des copies
                  ==> Ce n'est pas systèmatique mais dans certains cas, Qt Software peut demander des royalties pour l'installation de runtime. C'est surtout destiné à l'embarqué mais ça peut également s'appliquer à la version standard de Qt dans certains cas.
                  * Liberté d'améliorer le programme et de publier ces améliorations.
                  ==> la licence commerciale de Qt t'interdit de publier le source de ton application.
                  No source code must be disclosed


                  [1] http://www.qtsoftware.com/products/licensing/licensing#qt-co(...)
                  • [^] # Re: PyQt

                    Posté par . Évalué à  3 .

                    >No source code must be disclosed
                    je crois que tu as mal interprété, c'est pas can ou may mais must. C'est à dire que ce n'est pas obligatoire. (par opposition à la GPL)

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: PyQt

                      Posté par . Évalué à  2 .

                      Je dois être encore stone ... effectivement.
  • # QGtkStyle ?

    Posté par . Évalué à  7 .

    «Une meilleur intégration pour les environnement utilisation GTK »

    Il s'agit bien de QGtkStyle, à priori, attendu par certains Gnomistes/Xfceistes comme le Messie (ou presque) :·D ?

    http://labs.trolltech.com/page/Projects/Styles/GtkStyle

    En espérant que QGtkStyle soit utilisé rapidement dans ma distribution, pour mon plus grand bonheur :·D.
    • [^] # Re: QGtkStyle ?

      Posté par . Évalué à  3 .

      C'est bien cela. En fait c'est le moteur de GTK qui est utilisé à la place de celui de Qt : http://doc.trolltech.com/4.5/qgtkstyle.html

      Par contre je ne sais pas si tous les widgets Qt ont un équivalent GTK. Car si ce n'est pas le cas, j'image que c'est le moteur de Qt qui reprend la main.

      Quelqu'un connait les détails?
      • [^] # Re: QGtkStyle ?

        Posté par (page perso) . Évalué à  3 .

        Je me suis pas penché sur ce style particulièrement mais si c'est comme les autres styles Qt, c'est "juste" un style, c'est-à-dire que tu peux imaginer en gros un CSS pour "habiller" tes widgets.
        Tu n'utilises que le moteur bas-niveau de GTK pour dessiner tes widget Qt mais tu ne fais pas correspondre un bouton Qt par un bouton GTK, une checkbox Qt par une checkbox GTK, etc

        Chippeur, arrête de chipper !

        • [^] # Re: QGtkStyle ?

          Posté par (page perso) . Évalué à  6 .

          C'est exactement ça.

          En interne le style va demander à Gtk+ de dessiner les widgets ou primitives dans des buffers (mis en cache) de manière à dessiner tout exactement comme le fait Gtk+.

          Normalement la différence entre une vrai application Gtk et une application Qt ne devrais quasiment pas se voir.

          (Les applications KDE risquent d'être légèrement moins intégrées qu'une application "pure Qt" car elles ont des widgets qui ne sont pas pris en charge par le style Qt.
          Cette différence devrais toutefois être assez limitée.)
    • [^] # Re: QGtkStyle ?

      Posté par (page perso) . Évalué à  3 .

      D'après les développeurs de GTK ça à l'air de déchirer: http://aruiz.typepad.com/siliconisland/2009/02/gtk-30-themin(...)

      Qui sait, ça poussera peut être GTK à mieux s'intégrer à KDE?
  • # OpenDocument...

    Posté par . Évalué à  3 .

    Apparemment, et si je me suis pas merdé dans ma rapide recherche, la gestion de l'OpenDocument concerne la version ISO/IEC 26300, soit ODF 1.0
    • [^] # Re: OpenDocument...

      Posté par . Évalué à  2 .

      C'est exact (voir le changelog). Pour l'instant il y a uniquement le texte et les images qui sont supportés.
  • # Précisions ?

    Posté par (page perso) . Évalué à  2 .

    Qt est une bibliothèque C++ et Java. Mais cette dernière version ne sera plus maintenue officiellement par Qt Software et son évolution sera à la charge de la communauté.

    Quelqu'un a des précisions sur cette assertion ?
  • # Qyoto/Kimono

    Posté par . Évalué à  -2 .

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

    https://www.ohloh.net/p/qyoto
    http://ekarchive.elikirk.com/david/qyoto/
    • [^] # Re: Qyoto/Kimono

      Posté par (page perso) . Évalué à  4 .

      Sans vouloir vexer les développeurs de Mono, je ne vois vraiment pas l'intérêt. Le support de .Net est très inégal entre l'implémentation de Microsoft et l'implémentation de Mono.

      Faire du .Net cross plateforme est un combat perdu (pour ce que j'ai pu essayer de Mono/Moonlight). Alors que de l'autre coté faire du cross plateforme avec Qt est vraiment simple.
      • [^] # Re: Qyoto/Kimono

        Posté par . Évalué à  2 .

        De plus si mono implémente .net je ne vois pas pourquoi Nokia devrait faire un travail particulier, il parle déjà de .net et de son interaction (plus diverses autres choses) avec Qt : http://doc.trolltech.com/3.3/activeqt-dotnet.html
        • [^] # Re: Qyoto/Kimono

          Posté par . Évalué à  3 .

          Ton lien date un peu (relatif à Qt 3.3), voilà le bon lien
          http://doc.trolltech.com/4.5/activeqt-dotnet.html
          En gros, si tu veux utiliser Qt en .Net, soit tu utilises les outils associés à C++/CLI (pas standard, pas supporté par Mono), soit tu utilises ActiveQt (en gros, tu passes par COM) qui sapusaipalibre.
        • [^] # Re: Qyoto/Kimono

          Posté par (page perso) . Évalué à  1 .

          Y'a 3 façons d'utiliser des bibliothèques "natives" en .NET :
          - si la bibliothèque est bien conçu et exporte des API "plats" portables, les bindings se font de manière portable, directement en C#. Cas de la plupart des bibliothèques C.
          - si la bibliothèque exporte ses API en C++, point de salut : il faut se coltiner de la glue en C++, soit pour exporter un API plat facilement utilisable avec la solution précédente (c'est ce que fait Qyoto), soit directement en utilisant une variante de C++ capable d'intéragir avec les 2 environnements (pas portable comme langage).
          - si la bibliothèque exporte ses API à travers une interface COM, directement en C# en créant un binding automatiquement. Pas portable non plus.
          En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
          • [^] # Re: Qyoto/Kimono

            Posté par . Évalué à  4 .

            Je ne remet rien en cause de ta prose, mais :
            >En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
            De mon point vu Qt est portable, Nokia propose un framework qui est compilable avec des outils standards et portables.
            .net, de mon point de vue, est une solution propriétaire née suite à un désaccord entre deux grands acteurs de l'informatique contemporaine.

            Qt est portable, je ne crois pas que ce soit discutable (?)
            .net c'est propriétaire et non portable, mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.

            Personnellement toutes les discutions autour de mono ne m'ont jamais convaincu de l'intérêt de ce dernier et je ne vois pas plus d'intérêt pour Qyoto.

            A l'annonce de la sortie d'une version de Qt je suis surpris qu'on pose la question sur sa compatibilité avec .net, si .net est mieux pour des raisons X ou Y pourquoi vouloir utiliser Qt, mono existe son choix et probablement plus judicieux si on veut être compatible avec .net.
            • [^] # Re: Qyoto/Kimono

              Posté par (page perso) . Évalué à  -1 .

              net, de mon point de vue, est une solution propriétaire née suite à un désaccord entre deux grands acteurs de l'informatique contemporaine.
              Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.

              Qt est portable, je ne crois pas que ce soit discutable (?)
              la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
              Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.

              mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
              Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
              Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.
              • [^] # Re: Qyoto/Kimono

                Posté par . Évalué à  1 .

                >la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre.
                Tu connais les ABI, elles sont là pour résoudre un problème qui n'est pas spécifique au C++
                >C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
                Pourquoi penses tu que tes jugements de valeurs à 2 balles fassent fois ?
                >Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
                Le framework est portable sur beaucoup d'OS dont MSWindows. Effectivement qu'il y ait un portage sur un logiciel fermée comme .net est surprenant. C'est .net qui devrait être ouvert est capable d'incorporer l'existant sans avoir à ajouter des extensions dans un langage ou limiter son utilisation à quelques fonctionnalités, ce qui est le comble pour un vm qui se ventait d'être utilisable par tous les langages, au final elle ne l'est par aucun en tout cas dans leurs spécifications normalisées.
                • [^] # Re: Qyoto/Kimono

                  Posté par (page perso) . Évalué à  3 .

                  C'est .net qui devrait être ouvert est capable d'incorporer l'existant sans avoir à ajouter des extensions dans un langage ou limiter son utilisation à quelques fonctionnalités,
                  Tu lis ce que je mets ou quoi ?
                  .NET permet le même niveau de réutilisation de l'existant que tous les autres langages comme Java ou Python. Ces derniers ont exactement les mêmes problème que .NET pour faire des bindings sur des API C++ et sont obligés de passer par une couche de glue.
                  Ce qui n'est pas portable, c'est les surcouches intermédiaire écrites en C/C++ que propose d'utiliser Nokia : COM ou C++/CLI. Pas le binding en soit.
                  Donc voilà, y'a moyen, comme en PyQt ou Jambi de faire des bindings portables pour Qt, c'est Qyoto, et Nokia ne veut pas s'y intéresser. (ce que je ne critique pas, c'est leur choix).
              • [^] # Re: Qyoto/Kimono

                Posté par . Évalué à  7 .

                "Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable."

                Qt assure la portabilité au niveau des sources si ton application est 100% Qt et n'utilise pas les rares cas où il y a du "plateform specific" (comme dirait la documentation). Win32, .Net, X11 et autres joyeusetés MacOSiennes disponibles à travers Qt ne sont pas portables et doivent se régler à coup de #ifdef

                Qt Software est très clair sur ce point. Alors les critiquer sur ce point est un peu fort du café.
                • [^] # Re: Qyoto/Kimono

                  Posté par (page perso) . Évalué à  2 .

                  Attend c'est pas de ma faute si Nokia conseille ces méthodes non portable sur son site officiel :
                  http://doc.trolltech.com/4.5/activeqt-dotnet.html
                  Moi aussi je trouve ca fort de café que les équipes de Nokia conseille d'utiliser des glues non portables pour utiliser un framework portable, mais j'invente rien, c'est eux qui l'écrivent hein.
                  • [^] # Re: Qyoto/Kimono

                    Posté par . Évalué à  4 .

                    Je ne dit pas que c'est ta faute, mais j'ai l'impression que tu fais preuve de mauvaise fois en voulant absolument dire que Qt Software a mal fait son boulot.

                    Le contrat est que Qt est portable au niveau des sources. C'est le cas dans quasiment toute son API. Les 2 à 3% restant sont spécifiques à une plateforme (Windows, UNIX, MacOS, Windows CE, S60, etc...). Si quelqu'un veut utiliser du spécifique, Qt Software a pensé à lui mais prévient à chaque fois que ce n'est pas portable.

                    Si tu veux du portable, utilise uniquement Qt.
                    • [^] # Re: Qyoto/Kimono

                      Posté par (page perso) . Évalué à  2 .

                      Je ne critiques pas la portabilité de Qt en soit, je critique juste la doc de Nokia qui préconise des solutions non portables (et pas open-source au passage) pour faire un binding dans un langage pourtant portable.
                      • [^] # Re: Qyoto/Kimono

                        Posté par (page perso) . Évalué à  3 .

                        un langage pourtant portable.

                        Ça c'est toi qui le dit.


                        Mais le but de ActiveQt n'est pas du tout de créé des bindings pour faciliter le dévelopement en .Net. C'est de pouvoir utiliser C++ et Qt tout en s'intégrant dans des applications que d'autres auraient écrit en .Net
                        • [^] # Re: Qyoto/Kimono

                          Posté par (page perso) . Évalué à  -3 .

                          Ça c'est toi qui le dit.
                          C'est pas une idée, une pensée, c'est un fait. Le socle technique de .NET/C# est portable.
                          • [^] # Re: Qyoto/Kimono

                            Posté par (page perso) . Évalué à  4 .

                            Franchement Timaniac, faut arrêter de lire la propagande et essayer par toi même. Microsoft ne respecte pas du tout la norme ISO de .Net, et on fait difficilement moins portable.

                            Avec Mono tu passes ton temps à contourner les différences entre les deux implémentation, ou tu finis par utiliser Mono sur Windows pour avoir quelque chose qui "fonctionne" partout. :(
                            • [^] # Re: Qyoto/Kimono

                              Posté par (page perso) . Évalué à  1 .

                              Je veux bien discuter, mais faut argumenter alors.
                              En quoi le socle technique/C# n'est pas portable ?
                              En quoi MS ne respecte pas du tout la norme ISO correspondante ?
                              • [^] # Re: Qyoto/Kimono

                                Posté par Anonyme . Évalué à  4 .

                                http://tech.slashdot.org/article.pl?sid=09/03/03/1851205

                                C'est rigolo a quel point c'est multiplateforme les logiciels C#/.Net et tout particulierement silverlight... Non non aucun abus de position dominante la dedans naturellement...

                                Companies using software other than Microsoft's are unable to bid at many Portuguese public tenders. This is due to the use of Silverlight 2.0 technology

                                Le problème vient naturellement du retard de mono et moonlight car comme par hasard les technos "portables" de Microsoft ce ne sont jamais eux qui les portes (contrairement à Sun et Adobe pour ce qui est de java et flash) et les projets qui implémentent cela sont "curieusement" en retard. Cela me rappelle les versions doc, dès qu'une version marchottait chez la concurrence une nouvelle déclinaison (incompatible naturellement) faisait son apparition.
                                • [^] # Re: Qyoto/Kimono

                                  Posté par (page perso) . Évalué à  2 .

                                  car comme par hasard les technos "portables" de Microsoft ce ne sont jamais eux qui les portes
                                  MS a porté Silverlight sur Mac.
                                  Quand ils veulent, ils peuvent.

                                  Mais bon on est d'accord que Mono a du retard sur l'implémentation des bibliothèques disponibles dans .NET. Mais c'est pas un problème de technique, c'est essentiellement un problème de moyen.

                                  Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.
                                  • [^] # Re: Qyoto/Kimono

                                    Posté par Anonyme . Évalué à  2 .

                                    MS a porté Silverlight sur Mac.

                                    Pour la version 2.0 uniquement pour la plateforme Intel (amusant comme la portabilité est tout de suite limité...)

                                    Quand ils veulent, ils peuvent.

                                    CQFD Microsoft ne veut pas porter la moindre de ses logiciels ou technologies sous Linux d'où le fait que, de mon point de vue d'utilisateur exclusif de Linux, Microsoft soit un parasite négatif. D'ailleurs j'attend toujours la réponse à ma question sur l'apport direct de Microsoft à Linux de la part des défenseurs de cette entreprise. Il m'attaque en tentant de dénigrer mes propos en les faisant passer pour haineux (je suis probablement un dictacteur en puissance de leur point de vue...) mais n'apporte aucun véritable argument au sujet.

                                    Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.

                                    C'est bien toi qui est venu au secours de .Net et dire que Qt faisait un travail de merde, n'est ce pas? C'est un peu facile de critiquer un et de refuser de parler des "petits"problèmes l'autre.

                                    Qt est multiplateformes, C#/.Net ne l'est pas point barre que ce soit à cause d'une volonté politique et que mono est à la traine personnellement je m'en tape ceci est un fait et montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
                                    • [^] # Re: Qyoto/Kimono

                                      Posté par (page perso) . Évalué à  1 .

                                      Raah tu changes de pseudo mais c'est toujours du même niveau tes propos.
                                      Je ne cherches pas à défendre MS, je n'aime pas leur politique mono-plateforme, je n'aime pas leur politique de brevet, c'est pas pour autant que toutes les technos qu'ils concoivent sont pourris et que rien ne mérite de l'attention.
                                      http://en.wikipedia.org/wiki/Common_Language_Infrastructure
                                      "The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures."
                                      C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non. Que MS ne veuille pas porter son implémentation, c'est son problème, et ce troll ne m'intéresse pas, je parle de logiciel libre, de linux, de mono, de standards, de technique.
                                      Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet, qui est je te le rappel les bindings C# pour Qt. C# est un standard, qui s'appui sur une infrastructure ouverte, standard et parfaitement implémentée sous Linux, on peut se cantonner à ce périmètre sans que tu vomisse sur une implémentation proprio pour un OS proprio non ?

                                      Qt est multiplateformes
                                      Qt propose des briques qui ne sont pas portable et même pas libre, c'est une infime partie qui ne remet pas en cause l'intérêt de Qt, mais qui mérite critique quand on propose cette solution sur LinuxFR il me semble.

                                      montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
                                      A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.
                                      • [^] # Re: Qyoto/Kimono

                                        Posté par Anonyme . Évalué à  0 .

                                        Raah tu changes de pseudo mais c'est toujours du même niveau tes propos.

                                        Et voila encore une tentative de discréditer mes dires uniquement en me liant à d'autres participant de ce site. Ne pourrais tu pas te contenter de mes dires à moi et d'argumenter correctement contre?

                                        C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non.

                                        Ais je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable. Il l'est potentiellement mais il ne l'est pas dans les faits. Le nier c'est propager un mensonge. Toute la différence réside dans le conditionnel et le présent. .Net a presque 10 ans et Microsoft, comme TU le dis si bien, refuse de sortir des versions autres que sur sa plateforme et une partie sur Mac.

                                        Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet

                                        Et voila encore une tentative de discrédit sans aucun argument. Je vais te reposer une question simple à laquelle tu refuses de répondre:

                                        Quel est l'apport direct positif de Microsoft à Linux?

                                        Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.

                                        Qt propose des briques qui ne sont pas portable et même pas libre

                                        Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?

                                        A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.

                                        Je n'ai pas mis d'argument? Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents? Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
                                        • [^] # Re: Qyoto/Kimono

                                          Posté par (page perso) . Évalué à  2 .

                                          Et voila encore une tentative de discréditer mes dires uniquement en me liant à d'autres participant de ce site.
                                          Eh c'est toi qui a pondu tout un paragraphe sur ta personne.

                                          is je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable.
                                          J'ai depuis le départ pris soin de parler du "socle technique" pour faire référence à la technique pure et simple, la CLI quoi. Ca c'est portable. Et c'est ca qui nous intéresse vu qu'on parle technique. Que .NET soit pas porté pour d'obscure raisons marketing, on s'en branle, c'est pas le sujet. Je vois bien que t'as qu'une envie s'est de le crier haut et fort, mais ca n'intéresse pas grand monde je penses dans ce débat.

                                          Quel est l'apport direct positif de Microsoft à Linux?
                                          C'est pas le sujet, et j'en ai rien à péter de toute façon de savoir ce que MS apporte ou non à Linux.

                                          Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.
                                          Mais ca me gène pas, c'est juste que c'est totalement HS. Trouve quelqu'un d'autre pour troller sur le sujet, ca m'intéresse pas de savoir si MS apporte quelque chose à Linux.

                                          Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?
                                          Je suis pas un spécialiste, mais c'est marqué "The ActiveQt modules are part of the Qt Full Framework Edition. They are not part of the Open Source Versions of Qt."
                                          Ca me paraît donc officiel et pas Open source. Après je suis peut être très mauvais en anglais.

                                          Je n'ai pas mis d'argument?
                                          C'est pas une question d'argument, tu dis juste "c'est dangereux" comme ca pif paf comme un cheveu sur la soupe à la fin d'un paragraphe sans queue ni tête.

                                          Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents?
                                          Je vois pas le rapport avec la dangerosité de Mono. Juste une critique de la politique commerciale de MS, mais là encore c'est pas le sujet.

                                          Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
                                          C'est un peu ton problème : tu trouves des arguments qui totalement hors contexte ou hors sujet. Tu affirmes des trucs, parfois vrais et argumentés, mais sans rapport direct avec ce à quoi tu réponds.

                                          Maintenant j'arrête avec ton troll à 2 balles, je préfères mon troll technique initial.
                                          • [^] # Re: Qyoto/Kimono

                                            Posté par Anonyme . Évalué à  1 .

                                            En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.

                                            En gros tu critiques que Qt a utilisé une solution technique non portable pour un truc qui est n'existe que sur une seule et une seule plateforme. T'es tu posé la question sous l'angle:

                                            "A quoi cela sert de faire un truc portable pour un truc qui ne l'est que théoriquement?"

                                            Et si cela se trouve c'est sale mais plus rapide de faire comme ça. Le but de Qt étant d'être multiplateforme ne pas faire d'effort pour un truc monoplateforme et on ne peut plus logique et cela n'a, en effet rien avoir avec la technique quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères, mais comme pour C#/.Net de Microsoft un choix politique. On peut aussi rajouter que l'équipe mono, si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.

                                            Dans ce cas la tu peux en effet t'amuser à descendre Qt pour ses choix politiques cela mais ne vient pas te plaindre si des linuxiens viennent faire la même chose sur des technologies politiquement monoplateforme...
                                            • [^] # Re: Qyoto/Kimono

                                              Posté par (page perso) . Évalué à  2 .

                                              "A quoi cela sert de faire un truc portable pour un truc qui ne l'est que théoriquement?"
                                              Ben Mono me semble une implémentation largement conforme de la CLI, y'a sûrement des bugs mais je n'en ai rencontré aucun. Donc en pratique c'est portable, pas que en théorie.

                                              Et si cela se trouve c'est sale mais plus rapide de faire comme ça.
                                              Oué bah oué, c'est le cas. ActiveQt est une interface pour Windows COM, c'est un effet de bord si c'est facilement utilisable dans .NET. Mais ca reste une techno purement MS (même s'il y a eu des tentatives de portages de COM).

                                              quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères
                                              C'est effectivement plus complexe, et Nokia le dit d'ailleur très clairement dans son article. Mais cette complexité, tous les bindings de Qt l'ont, c'est un problème lié au choix technique de Qt d'exporter ses API sous la forme de classes C++, qui sont par nature beaucoup plus difficile à binder qu'un API C.

                                              si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.
                                              Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.
                                              • [^] # Re: Qyoto/Kimono

                                                Posté par Anonyme . Évalué à  2 .

                                                Donc le choix fait apr Qt est technique en plus d'être politique.

                                                Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.

                                                Pourquoi le projet mono ne le fait pas alors? Est-il trop lié à Gnome/Gtk? Pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme et plus complète que tout ce qui est disponible à côté dans le monde du libre?
                                                • [^] # Re: Qyoto/Kimono

                                                  Posté par (page perso) . Évalué à  2 .

                                                  Pourquoi le projet mono ne le fait pas alors?
                                                  Parcque Qt est chiant à binder :)

                                                  pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme
                                                  Ben c'est un effort qui intéresserait tous ceux qui font des bindings, pas plus Mono que d'autres. Je ne demande pas à Qt de maintenir des bindings pour tous les langages de la terre, mono n'est effectivement pas un langage super répendu sur Linux qui mérite plus leur attention qu'un autre langage. Je trouverais juste ca cool s'ils pensaient à ceux qui ne veulent pas faire de C++ et faciliter la vie de ceux qui créent des bindings pour Mono, Python Ruby ou je ne sais quoi. Il leur suffirait de maintenir un seul binding, en C.
                                                  • [^] # Re: Qyoto/Kimono

                                                    Posté par Anonyme . Évalué à  1 .

                                                    Parcque Qt est chiant à binder :)

                                                    et pas Gtk? Enfin cela semble s'être améliorer mais bon pygtk il est toujours à la bourre par rapport à Gtk actuellement sa dernière version est la 2.2.12 alors que GtK en est à la version 2.14... PyQt en est à la version 4.4 et les snapshot pour la version 4.5 sont disponible. Tiens par contre grâce à ce message je me suis aperçu que la documentation de pygtk était enfin là.

                                                    Il leur suffirait de maintenir un seul binding, en C.

                                                    Ouh le vilain troll C versus C++.
                                                    • [^] # Re: Qyoto/Kimono

                                                      Posté par (page perso) . Évalué à  4 .

                                                      et pas Gtk?

                                                      Gtk est en C, Qt utilise à fond les spécificités du C++.
                                                      Binder une lib C++ en C, c'est pas gagné. Ou alors tu le fais en te plaçant haut dans le binding.

                                                      Chippeur, arrête de chipper !

                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par Anonyme . Évalué à  1 .

                                                        c'est tout de même faisable et fait alors si mono veut se donner la peine ils peuvent très bien le faire mais encore une fois c'est une question de choix.
                                                    • [^] # Re: Qyoto/Kimono

                                                      Posté par (page perso) . Évalué à  2 .

                                                      et pas Gtk?
                                                      Ben de ce que j'ai essayé de faire comme binding, c'est moins chiant.
                                                      Ca s'automatise beaucoup plus simplement.
                                                      En particulier avec Mono qui propose une façon élégante, simple et portable de faire des bindings, pour peu que les ABI de la bibliothèque bindée soit portable. Et c'est tout le problème de C++ et son name mangling.

                                                      Ouh le vilain troll C versus C++.
                                                      Enfin un qui rentre dans le bon troll :)
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par Anonyme . Évalué à  1 .

                                                        Je me demande pourquoi si c'est si facile pygtk est à la traine...
                                                        • [^] # Re: Qyoto/Kimono

                                                          Posté par . Évalué à  2 .

                                                          http://mail.gnome.org/archives/gnome-announce-list/2009-Janu(...)

                                                          Parce que c'est un projet communautaire ? parce que personne n'est payé pour bosser à temps plein dessus ? C'est pas les bonnes raisons qui manquent.
                                                          • [^] # Re: Qyoto/Kimono

                                                            Posté par Anonyme . Évalué à  1 .

                                                            Peut être mais cela montre que ce n'est pas si évident de faire un bindings même pour un truc en C.
                                                            • [^] # Re: Qyoto/Kimono

                                                              Posté par . Évalué à  5 .

                                                              Personne n'a dit que l'écriture d'un binding était simple, loin de là.
                                                              Mais la simplicité du langage C facilite pas mal les choses pour la génération des bindings au niveau technique. De fait, le C est la lingua franca de l'informatique.
                                                              Le C++ étant un langage nettement plus complexe, c'est un peu plus délicat, le débogage est plus difficile (essaie de déboguer un module Python développé en C ou avec Boost.Python, tu m'en diras des nouvelles). Effectivement, si tu fais ton binding à la main, mieux vaut que le langage source soit en C qu'en C++.

                                                              Mais le point que tout le monde semble oublier dans cette enfilade, c'est que des frameworks tels que Qt et Gtk+ possèdent un modèle objet bien établie, imposent des conventions de code qui permettent de générer automatiquement des bindings sans trop de gruikage.
                                                              La totalité des bindings de Qt et Gtk+ sont automatiquement générés à partir du sources que ce soit PyQt avec SIP, QtJambi avec son générateur, PyGtk avec codegen, Gtkmm avec gmmproc etc ...


                                                              Une fois, l'obstacle technique du langage source dépassé, la très grande partie du boulot c'est surtout du peaufinage, rendre les APIs plus agréables et mieux intégrés au langage cible.

                                                              Bref, cette discussion c'est de la sodomisation de mouches.
                                                  • [^] # Re: Qyoto/Kimono

                                                    Posté par (page perso) . Évalué à  2 .

                                                    Parcque Qt est chiant à binder

                                                    http://techbase.kde.org/Development/Languages
                                                    C'est pas comme si on avait pas les outils pour le faire.
                                                    • [^] # Re: Qyoto/Kimono

                                                      Posté par (page perso) . Évalué à  2 .

                                                      Oué enfin quand tu vois que c'est indiqué que les bindings C# sont stables et mature alors que le fameux binding, Qyoto, est même pas déployable sous Windows out-of-the-box, ca fait peur.
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par Anonyme . Évalué à  1 .

                                                        Je dois avouer que je ne vois pas le rapport entre disponible out-of the box pour une certaine plateforme et les notions de stabilité et maturité.

                                                        Voudrais tu dire que parceque C#/.Net de Microsoft n'est pas déployable out-of-the-box (on passera sur le fait que ce n'est même pas dispo d'une autre façon) pour Linux ce n'est ni stable ni mature?
                                          • [^] # Re: Qyoto/Kimono

                                            Posté par Anonyme . Évalué à  1 .

                                            Eh c'est toi qui a pondu tout un paragraphe sur ta personne.

                                            Tu veux dire que non seulement on ne peut plus utiliser le droit de citation (soit disant égale à des attaques ad hominem) mais que en plus l'usage du pronom "je" est interdit sur ce site? Et quels sont les autres règles non écrites auxquelles je le participant dois me se soumettre?
                                      • [^] # Re: Qyoto/Kimono

                                        Posté par (page perso) . Évalué à  3 .

                                        Tu n'aime pas Microsoft pour sa politique mono-plateforme
                                        Mais tu aime Mono malgré sa politique plateforme Microsoft :-)
                                        • [^] # Re: Qyoto/Kimono

                                          Posté par (page perso) . Évalué à  1 .

                                          Bah ca n'a rien de contradictoire. J'aime bien la techno CLI derrière .NET, et j'aime bien les logiciels libres. Mono me propose de combiner les 2, je vois pas pourquoi je cracherais dessus pour d'obscure position anti-MS primaire.
                                          • [^] # Re: Qyoto/Kimono

                                            Posté par Anonyme . Évalué à  1 .

                                            Il n'y a strictement aucun problème à cela (enfin pour moi) par contre je dois avouer que j'ai du mal à comprendre ton insistance à nier le fait que Linux et les autres systèmes sont des citoyens de second zone dans le monde C#/.Net comme le démontre très bien le lien fournit au dessus.

                                            Trouves tu normales que les marchés publics soient interdit au non utilisateur de Microsoft?
                                            • [^] # Re: Qyoto/Kimono

                                              Posté par (page perso) . Évalué à  3 .

                                              Ben comme je l'ai dis, je critique la politique mono-plateforme de MS donc je trouve pas ca normal, non. Que Linux soit soit un citoyen de seconde zone pour Microsoft, je ne le nie absolument pas, c'est un fait.
                                              Mais je vois toujours pas le rapport. On parlait technique bon sang, pas politique Microsoft.
                                              • [^] # Re: Qyoto/Kimono

                                                Posté par Anonyme . Évalué à  1 .

                                                A partir d'un moment la technique devient politique comme mon lien l'a bien montré et je tiens à te faire remarquer que je répondais à un de tes messages ou TU as parlé de Microsoft.

                                                Je veux bien discuter, mais faut argumenter alors.
                                                En quoi le socle technique/C# n'est pas portable ?
                                                En quoi MS ne respecte pas du tout la norme ISO correspondante ?


                                                Tu parles de théorie moi je parle de pratique. La différence est là. En théorie Microsoft peut apporter beaucoup à l'informatique et au logiciels libres, la pratique est toute différente.
                                                • [^] # Re: Qyoto/Kimono

                                                  Posté par (page perso) . Évalué à  2 .

                                                  Ok donc t'es bien conscient que tout ton blabla ne répond absolument pas aux questions que j'ai posé ? Donc je répètes mes questions :

                                                  En quoi le socle technique/C# n'est pas portable ?
                                                  En quoi MS ne respecte pas du tout la norme ISO correspondante ?
                                                  • [^] # Re: Qyoto/Kimono

                                                    Posté par Anonyme . Évalué à  1 .

                                                    Ça on ne peut nier que tes deux questions sont suffisemment vague pour que leurs réponses soit négative. Et si on les tournes de cette façon là cela donne quoi?

                                                    En quoi le socle technique/C# est porté sur différentes plateformes?
                                                    Quel est la proportion de .Net non normalisé ISO?
                                                    • [^] # Re: Qyoto/Kimono

                                                      Posté par (page perso) . Évalué à  2 .

                                                      C'est normalement plus facile de montrer un exemple qui dit que telle affirmation est fausse que de démontrer qu'une affirmation est tout le temps vrai.
                                                      Excuses-moi, mais j'ai la flemme de te faire un rapport de 5000 pages détaillant chaque paragraphe de la spec CLI/C# pour démontrer qu'elle est effectivement portable.
                                                      Moi j'ai pointé un article wikipedia, ca vaut ce que ca vaut, qui dit explicitement que la CLI a été conçu pour être portable.
                                                      Si c'est pas le cas, tu devrais trouver rapidement des exemples montrant que la CLI de Mono n'est pas et ne peut pas être compatible avec le standard.
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par Anonyme . Évalué à  1 .

                                                        Relis bien j'ai répondu à tes questions maintenant répond aux miennes.

                                                        D'ailleurs le point évoquer plus bas: https://linuxfr.org/comments/1013173.html#1013173 est totalement à l'ordre du jour la norme ISO de C# est totalement obsolète certes son implémentations par Microsoft a été respecté mais bon C# a tellement changé depuis (d'après tes propres journaux annonçant les versions succéssives me semble t'il) que cela ne veut presque plus rien dire. C# 3 n'est pas une norme ISO et détrompe moi je crois que ce n'est pas plus le cas pour .Net.
                                                        • [^] # Re: Qyoto/Kimono

                                                          Posté par (page perso) . Évalué à  2 .

                                                          Oui C# 3 n'est pas encore normalisé.
                                                          Mais bon en l'occurrence C# 3.0 s'appuie toujours sur le même socle technique : la CLI, dont la norme ISO est toujours au goût du jour et correctement implémentées par .NET et Mono. La CLI est par nature indépendante du langage (c'est un de ses intérêts) : si tu fais un binding pour la CLI, il sera utilisable dans tous les langages.
                                                          • [^] # Re: Qyoto/Kimono

                                                            Posté par Anonyme . Évalué à  1 .

                                                            si tu fais un binding pour la CLI, il sera utilisable dans tous les langages.

                                                            Comme tu l'as dit toi même c'est complexe et n'intéresse globalement que très peu de monde. Les priorités de Qt sont autres et j'en suis bien content.
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par . Évalué à  2 .

                                                        C'est normalement plus facile de montrer un exemple qui dit que telle affirmation est fausse que de démontrer qu'une affirmation est tout le temps vrai.

                                                        À la seule condition que la première affirmation soit effectivement fausse. Sinon, tu risques de le chercher longtemps, ton exemple.
                                                  • [^] # Re: Qyoto/Kimono

                                                    Posté par (page perso) . Évalué à  5 .

                                                    Je me demande bien où tu vas chercher tes infos. Tu dois être pote avec un commercial et tu crois tout ce qu'on te raconte...

                                                    Tu essayes de faire dériver le débat avec ta première question. C# pourrait être portable, d'ailleurs Mono est portable, mais en pratique .Net ne l'est pas. J'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac. C# pourrait hypothétiquement être portable, personne ne dit le contraire.

                                                    Quand on parle de Java, on parle de l'implémentation de Sun parce que c'est la seule qui a des performances potable et c'est là cible sur lequelle on développe. Sur Java la portabilité est pas trop mal (j'ai dit portabilité, pas intégration), car tu peux te rabattre sur l'implémentation de référence, même sous Linux.

                                                    Quand on parle de .Net, on parle de l'implémentation de Microsoft. Et là rien ne vas plus parce que l'implémentation de référence n'existe que sous Windows, et que la version multiplateforme est bancale (que ce soit en terme de vitesse ou de fonctionnalités). Essaye de faire tourner une application non triviale sur MS.Net et Mono, tu vas te marrer (et je ne dis pas ça contre Mono, ils font un boulot incroyable étant donné la différence de moyen avec Microsoft!).

                                                    Mono n'as vraiment pas aidé Linux pour le moment. Aucune application .Net n'est venu de Windows vers Linux, mais de l'autre côté ça permet à Microsoft de raconter à tout le monde que si ils font du .Net c'est cross-plateforme. Et il y a des gens qui y croient.


                                                    Pour la norme ISO, le problème est que la norme a été soumise il y a longtemps, et elle n'a jamais été mise à jour. Les problèmes de la norme n'ont jamais été corrigé, et les nouveautés n'ont jamais été intégrés.

                                                    Il est ressorti d'une discutions que j'ai eu avec un ingénieur de Microsoft France que la norme est juste là pour donner du poid à son langage sur le papier. Cette norme n'est pas du tout la référence utilisé par Microsoft, et ils n'ont aucune intention de la mettre à jour.

                                                    Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes. Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent. Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.

                                                    .Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
                                                    • [^] # Re: Qyoto/Kimono

                                                      Posté par (page perso) . Évalué à  2 .

                                                      Tu essayes de faire dériver le débat avec ta première question.
                                                      Non, depuis le départ j'essai de parler d'une seule chose : Qyoto, binding .NET/Mono, Qt.
                                                      Les dérives sur la portabilité de l'implémentation propriétaire de la CLI par Microsoft, c'est ton délire et le délire de ____.

                                                      'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac.
                                                      Le problème c'est déjà de trouver des killer-app, ensuite de trouver des killer-app qui tournent exclusivement en .NET et sans utiliser de bibliothèques spécifiques à tel ou tel système. C'est le problème des killer-apps, c'est que généralement elles sont bien car intégrés dans leur environnement, et portabilité rime rarement avec intégration parfaite.

                                                      Quand on parle de .Net, on parle de l'implémentation de Microsoft.
                                                      Je pensais qu'en parlant de Qyoto sur LinuxFR on pouvait ne pas parler de .NET et avoir un débat technique constructif. Visiblement non.

                                                      Aucune application .Net n'est venu de Windows vers Linux
                                                      Applications graphiques, effectivement non. Mais des libs pleins. Et le but n'est pas seulement de porter des applications, c'est aussi d'attirer des développeurs Windows à l'environnement Linux. Ce fut mon cas, et je suis pas le seul.
                                                      Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.

                                                      Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes.
                                                      Ils se basent dessus.

                                                      Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent.
                                                      Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées. Mais pour ce qui est du coeur, à savoir la CLI, franchement tu vois quoi comme écart notable par rapport à la norme dans les implémentations MS et Mono ?

                                                      Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.
                                                      Je vois pas de différence. Aucune implémentation d'un standard est exempt de bug et tout le monde cherche naturellement à être compatible avec l'implémentation de référence.

                                                      .Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
                                                      Ca tombe bien, on s'en branle, on parle de Mono, CLI, binding Qt.
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par (page perso) . Évalué à  3 .

                                                        J'arrête de me prendre la tête avec toi, tu ne réponds jamais qu'à ce qui t'arrange et tu cherches tout sauf une discutions constructive.

                                                        Il ne me reste qu'à te souhaiter bon courage pour développer des applications multiplateforme avec .Net.
                                                        • [^] # Re: Qyoto/Kimono

                                                          Posté par (page perso) . Évalué à  1 .

                                                          tu ne réponds jamais qu'à ce qui t'arrange et tu cherches tout sauf une discutions constructive.
                                                          Je te retourne la critique : moi je chercherais à discuter technique de binding, portabilité, vous préférez troller sur MS.NET.
                                                          Désolé de ne pas vouloir troller sur ce que tu veux.
                                                      • [^] # Re: Qyoto/Kimono

                                                        Posté par Anonyme . Évalué à  1 .

                                                        Les dérives sur la portabilité de l'implémentation propriétaire de la CLI par Microsoft, c'est ton délire et le délire de ____.

                                                        Relis bien ce que nous avons dit car je crois qu'il y a clairement soit un effort de déformation de nos dire soit un problème interface chaise/clavier. Ni l'un ni l'autre n'avons nié la portabilité théorique mais la portabilité pratique. Qui plus est dans mon cas je précise bien de façon systématique C#/.Net et si j'ai tord donne moi le lien ou je peux récupérer un environnement C#/.Net complet pour Linux. Encore une fois tu mélanges la théorie et la pratique! Et tu commences à me casser les couilles sur le coup à vouloir systématiquement me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!

                                                        Ils se basent dessus.

                                                        Et uniquement dessus où ils n'implémenteraient pas aussi des trucs non normalisés?

                                                        Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.

                                                        On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono et c'est assez rassurant de voir ces dernières être remplacé lorsque c'est possible (exemple beagle qui a disparu de l'installation par défaut des distributions).

                                                        Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées.

                                                        Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela? Tu semble dire d'un côté que C#/.Net c'est normalisé et puis par la suite tu dis que non et tu restreints le tout à CLI que personne dans ce fil n'a dit que ce ne l'était pas... Ce que tu fais c'est noyer le poisson et faire passer une sardine (CLI) pour une baleine (C#/.Net).
                                                        • [^] # Re: Qyoto/Kimono

                                                          Posté par (page perso) . Évalué à  1 .

                                                          Qui plus est dans mon cas je précise bien de façon systématique C#/.Net et si j'ai tord donne moi le lien ou je peux récupérer un environnement C#/.Net complet pour Linux.
                                                          C'est tout à fait ce que j'ai voulu dire : vous parleinz de MS .NET, c'est votre délire trollesque à tous les 2, et n'insistez pas, ca m'intéresse pas comme débat de discuter d'un produit proprio qui ne tourne que sur des plateformes proprios.

                                                          me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!
                                                          Eh ca m'arrive de délirer sans aller à l'asile :) Sérieux, je passe mon temps à essayer de recadrer le débat sur la partie technique normalisée, la CLI, qui m'intéresse et intéresse sans doute du monde sur LinuxFR parcqu'implémenté par Mono et Portable .NET. T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.

                                                          On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono
                                                          Oué chacun son desktop effectivement. Moi mon Ubuntu avec son environnement de base, cad Gnome, vient avec F-Spot, Banshee et Tomboy. Sans chercher à faire de comparaison avec Java, ca reste que des développeurs ont visiblement trouvés un intérêt à coder des applications avec mono, et les utilisateurs ont trouvés suffisament d'intérêts dans ces applications pour qu'elles soient utilisées dans une distribution populaire. Bref, mono n'a plus à démontrer son intérêt.

                                                          Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela?
                                                          A part les gens qui codent pour un produit proprio (MS.NET) sur une plateforme proprio (Windows), ca gène qui sous Linux ?

                                                          Tu semble dire d'un côté que C#/.Net c'est normalisé
                                                          Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.
                                                          • [^] # Re: Qyoto/Kimono

                                                            Posté par Anonyme . Évalué à  0 .

                                                            Moi mon Ubuntu avec son environnement de base, cad Gnome, vient avec F-Spot, Banshee et Tomboy.

                                                            Je sais la première que je fais c'est justement de dégager ce merdier. De tout de façon Digikam est mieux que F-Spot (à mon avis), Banshee (non installé par défaut à moins que cela ait changé dans intrepid) c'est pas mieux que amarok et de tout de façon j'utilise mpd et quand à tomboy je ne vois pas trop ce que cela apporte par rapport à basket tellement c'est basique.

                                                            Bref, mono n'a plus à démontrer son intérêt.

                                                            Son intérêt peut être pas mais par contre son danger si. Je me demande pourquoi Novell a passé un accord avec Microsoft si c'était si sécure que cela sinon... Juste pour se mettre une partie de la communauté à dos?

                                                            T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.

                                                            TU es le premier de nous deux à avoir parlé de Microsoft alors rendons à César ce qui est à César ne te plains pas après de te voir ce genre d'argument utilisé dans le sens oposé de tes désirs (comme si cela était une surprise sur ce site qui plus est...). Que veux tu que j'aille foutre sur windowsFR? Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.

                                                            Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.

                                                            La base technique de la version 2 car la version 3 n'est pas normalisé donc vers quoi doit se faire le bindings? Une version obsolète ou une version non normalisé? Et comme dit auparavant si tu n'est pas content des bindings Qt pour C# fait les, le code est opensource.
                                                            • [^] # Re: Qyoto/Kimono

                                                              Posté par (page perso) . Évalué à  3 .

                                                              Je me demande pourquoi Novell a passé un accord avec Microsoft si c'était si sécure que cela sinon...
                                                              troll FUD patent detected. bip bip.
                                                              L'accord concerne pas uniquement mono mais tous les logiciels inclus dans les distributions Linux de Novell.
                                                              Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft : les foutus codecs bourrés de brevets (et pas uniquement des brevets de MS). Mais c'est pas le sujet, Moonlight ne m'intéresse pas, et n'a vraiment aucun rapport avec ce Qyoto.

                                                              Juste pour se mettre une partie de la communauté à dos?
                                                              Je suppose que dans la tête des commerciaux de Novell, ca rassure les clients, quitte à se mettre à dos la communauté. Je dis pas que c'est malin mais je suppose que c'est le raisonnement.

                                                              Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.
                                                              Eh ben c'est parfait ! t'en à rien à branler de MS.NET alors ! Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET ! Rien à péter des bindings Qt proprios pour COM/.NET ! Que du bonheur, on va enfin pour en revenir à ce qui nous intéresse, Qt open source et le binding Qyoto !

                                                              La base technique de la version 2 car la version 3 n'est pas normalisé
                                                              Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles. Le socle technique n'a pas bougé depuis 4 ans et est toujours en version 2.0. Son implémentation dans mono est stable depuis un bon moment, la norme ISO est toujours d'actualité, tout va bien.
                                                              Le socle technique s'appelle CLI pour Common Language Runtime, autrement dit, rien à péter de la version de C#, de VB ou d'IronPython au dessus, si tu fais un binding pour la CLI, c'est un problème parfaitement indépendant du langage, la CLI a été conçu pour ça.
                                                              • [^] # Re: Qyoto/Kimono

                                                                Posté par Anonyme . Évalué à  1 .

                                                                troll FUD patent detected. bip bip.

                                                                voyons tu sais bien que mono a bien été mis en avant au moment de l'accord.

                                                                Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET

                                                                Sauf si les cas comme celui du portugal se généralise.

                                                                Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft

                                                                Ah ben c'est encore pire que je croyais...

                                                                Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles.

                                                                Excuse moi de ne pas être spécialiste de mono et de te laisser nous parler de ta spécialité...
                                                                Il est vrai que je ne connais pas le sujet mais d'après la FAQ The Mono API today is somewhere in between .NET 2.0 and .NET 3.5 donc il semblerait bien qu'il y ait pas mal de chose non normalisé dans le framework qui si j'ai bien compris comprend un tout petit peu plus que CLI... Enfin pour en revenir au sujet Qt a un bindings que tu n'aimes pas la façon dont il fait c'est pas trop un problème tu n'as qu'à le faire proprement toi même. Vive les logiciels opensource pour cela!
                                                                • [^] # Re: Qyoto/Kimono

                                                                  Posté par (page perso) . Évalué à  1 .

                                                                  Non non j'aime comment est fait le binding Qt, Qyoto, qui se base sur les outils de binding de KDE. Ce que j'aime pas, c'est l'attitude de Nokia qui ne facilite pas vraiment la tâche des binders en proposant une API uniquement en C++ et qui conseille dans la doc des solutions proprio comme s'il existait que des CLI proprios sous un OS proprio. Je trouve pas ca dans l'esprit de Qt qui est un framework multiplateforme et bien plus mis en avant sous Linux à travers KDE que sous un certain environnement proprio.
                                                                  • [^] # Re: Qyoto/Kimono

                                                                    Posté par (page perso) . Évalué à  6 .

                                                                    Non non j'aime comment est fait le binding Qt, Qyoto, qui se base sur les outils de binding de KDE. Ce que j'aime pas, c'est l'attitude de Nokia qui ne facilite pas vraiment la tâche des binders en proposant une API uniquement en C++.

                                                                    Mais tout Qt est fait en C++, je pense pas que tu te rends compte de la masse de travail que c'est de faciliter la taches de binders en ayant une autre API, et la maintenance.

                                                                    Qt est un produit en C++. Nokia développe son produit qui est Qt. PyQt et co sont d'autres produits. C'est pas le rôle de Nokia de faire ça, de faciliter le binding puisque a la base le produit Qt est fait en C++. Les gens se sont lances dans des bindings, très bien mais on peut pas demander a Nokia de supporter un truc qu'il ont pas décide, supporte, voulu.

                                                                    Et puis honnêtement pourquoi se faire chier a faire des APIs pas géniale pour matcher avec des langages comme C et faciliter le binding. On en veut pas, si c'est pour se retrouver avec des APIs a la GTK ma_fct_qui_s_appelle_super. Non merci!!!! Et puis chaque langage est spécifique ça deviendrai l'usine a gaz.

                                                                    qui conseille dans la doc des solutions proprio comme s'il existait que des CLI proprios sous un OS proprio
                                                                    Ils te conseillent pas de l'utiliser bien évidemment.

                                                                    "Qt's ActiveX and COM support allows Qt for Windows developers to:"

                                                                    Je pense que la phrase est claire que ca tue le cross platform de ton appli. Ils supportent pas les autres plate-formes (même si y'a Mono sous linux dans l'absolu), c'est juste pas teste. Il a jamais été marque qu'il faut l'utiliser, c'est un hack pour certaines applis Windows qui veulent du .Net/COM et co.

                                                                    Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple.

                                                                    Tu t'égares la. Un langage ne s'appuie pas sur des librairies , ERREUR. Un langage peut parfois fournir une librairie (exemple la std que tu dois implémenter sur ta plate-forme si tu veux qu'elle soit C++ compliant). Un framework utilise des librairies.
                                                                    .Net n'est pas un langage mais un framework qui s'appuie entre autre sur le C# et des librairies (non portables pour certaines).
                                                                    Qt est un framework aussi s'appuyant sur le langage C++ utilisant des libs mais dont Nokia s'assure qu'elles sont cross platform.

                                                                    Un langage tu peux écrire la grammaire sans même parler de OS, librairies ou architecture.
                                                                    On peut écrire la grammaire de Java, C++, C, C#.

                                                                    Mais hélas pour le C# la frontière devient mince avec le langage proprement parle et un framework. C# inclue désormais tout un tas de concept qui ne collent plus avec l'idée originale et qui en vient a utiliser des libraires. Ex : Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.

                                                                    Donc oui dans l'absolu ActiveQt pourrai dire, ah mais sous Nunux tu as Mono ca marche. C'est tout simplement pas supporte et teste, pas dans les priorité de Nokia (ce que je comprends) et de plus tu n'as aucun contrôle puisque c'est un autre framework.

                                                                    Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5. Niquel ca marche. Ah c'est Qt cross platform il disent mono sous linux parfait je recompile sous Nunux et la ça se branche sur Mono mais la fct A est pas implémenté, Craboum. Problème. Je comprends parfaitement que ça soit pas mis en avant car pas supporte et de plus c'est un hack, c'est une feature qui est que pour Windows dans des cas très précis (interfacage) et pour des raisons historique (des clients ont du demander) et cela est absolument pas garanti cross plate-forme. En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
                                                                    • [^] # Re: Qyoto/Kimono

                                                                      Posté par (page perso) . Évalué à  2 .

                                                                      Mais tout Qt est fait en C++, je pense pas que tu te rends compte de la masse de travail que c'est de faciliter la taches de binders en ayant une autre API, et la maintenance.
                                                                      C'est tout le problème de la philosophie Qt. Si tu veux pas faire de C++, ben pas d'bol, t'es considéré comme un développeur de seconde zone.
                                                                      C'est effectivement un choix de Nokia, ils font comme ils veulent, je trouve ca juste dommage, je peux ?

                                                                      Ils te conseillent pas de l'utiliser bien évidemment.

                                                                      "Qt's ActiveX and COM support allows Qt for Windows developers to:"

                                                                      Comme déjà dis, ils le conseillent officiellement, et j'ai rien vu concernant la portabilité, notamment dans la section limitation, sur la page concernée :
                                                                      http://doc.trolltech.com/4.5/activeqt-dotnet.html
                                                                      On est quand même en droit de trouver ca dommage de conseiller d'utiliser un truc pas portable avec un framework portable non ?

                                                                      Un langage ne s'appuie pas sur des librairies , ERREUR.
                                                                      T'es comique, tu cites juste LINQ qui est le parfait contre exemple de ce que tu dis :)
                                                                      Enfin quand je disais langage, je parlais de plateforme, on se comprend.

                                                                      Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.
                                                                      Etrange ou innovant ? Moi je trouve ca génial à l'utilisation : ca pousse à écrire du déclaratif / fonctionnel plutôt que l'impératif classique, et je trouve ca pas plus mal.
                                                                      Quand à la difficulté d'implémentation sous Linux, laisse moi rire, Mono l'implémente très bien C# 3.

                                                                      Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5.
                                                                      ActiveQt est une interface COM, technologie vieille de 10 ou 20 ans, qui tourne concrêtement que sous Windows aujourd'hui. C'est pas un problème de .NET Mono ou autre. C'est un problème de portabilité de ActiveQt en soit, qui fait que ce n'est une solution utilisable que sous Windows.

                                                                      En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
                                                                      Mais je suis d'accord avec ca, je critique pas le fait que y'es des trucs pas cross-plateforme par ci par là, ce que je critique c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.
                                                                      • [^] # Re: Qyoto/Kimono

                                                                        Posté par (page perso) . Évalué à  2 .

                                                                        c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.

                                                                        Essaye PyQt, tu verras si Qt ne tourne correctement qu'avec C++. L'intégration à Python est nickel.
                                                                        Je peux dire la même chose pour Qt Jambi.
                                                                        Et dans une certaine mesure j'aime bien aussi Qt Script, qui n'est jamais que du Javascript pour Qt.

                                                                        Mais oui, peu de gens aiment .Net, et du coup les bindings sont pas terrible parce que personne n'a envie de bosser pour cette plateforme. Bienvenu dans le monde réel.
                          • [^] # Re: Qyoto/Kimono

                            Posté par . Évalué à  6 .

                            Oui mais faut reconnaître que en pratique, le très gros morceau qu'est l'API (celle que Microsoft documente sur le MSDN et que les développeurs C# sous Windows utilisent) ne l'est pas. Sinon Mono n'aurait pas besoin de se baser sur GTK pour l'interface.

                            Et encore c'est parce que l'interface est la première chose qui me vient à l'esprit. Mais quelqu'un plus au fait de la question devrait me donner tout une liste de trucs qui sont spécifiques Windows et pourtant généralement essentiel lors du développement d'une application.

                            Que le langage soit très bien, que l'adaptation de Mono soit très bien pour développer des applications je n'en disconvient pas (eu égard des commentaires de développeurs et des quelques applications que j'ai pu voir). Mais il faut arrêter de dire que ce que pond Microsoft est portable. L'API n'est généralement pas portable et spécifique sur bien des points à Windows.

                            Ce qui est relativement portable c'est Mono, pas le .Net de Microsoft.
                            • [^] # Re: Qyoto/Kimono

                              Posté par (page perso) . Évalué à  4 .

                              Y'a 2 trucs qui limite la portabilité dans .NET :
                              - une raison technique : certains API s'appui sur des libs Windows et sont donc difficilement portable. Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple. Après ca ne concerne pas grand chose dans .NET, voir quasiment rien. Le problème est ailleur, voir ci-dessous.
                              - une raison commerciale : la licence de l'implémentation de .NET ne permet pas de réutiliser les composants sur autre chose qu'un OS Windows. Ca pu c'est pas libre. C'est pas pour ca que c'est pas portable. Et c'est ce que fait Mono : elle propose une implémentation alternative libre sans limitation de plateforme.
                              Mais techniquement je le répète, le socle technique de .NET/Mono est parfaitement portable. Y'a une abstraction de tout : les instructions machines, la mémoire, les threads, etc.
                              Et c'est bien de technique dont on parle ici quand on parle de binding. Et on est sur LinuxFR, donc on s'intéresse à Mono, qui est une plateforme portable ET portée.
                              • [^] # Re: Qyoto/Kimono

                                Posté par . Évalué à  2 .

                                "donc on s'intéresse à Mono"

                                En fait l'article c'est sur Qt (c'est juste pour avoir le fin mot de l'histoire!)

                                Mais je suis d'accord sur le principe : Mono est portable. Mais le .Net que fournit Microsoft ne l'est pas car trop lié à Windows. Maintenant l'utilisation de .Net dans Qt n'est pas destiné à ceux qui veulent être portable, mais bien à ceux qui développent pour Windows avec Qt en voulant s'interfacer avec du .Net sous Windows.

                                Si Qt le propose, c'est qu'il y a un besoin et ActiveQt est là pour y palier.

                                PS : En tout cas j'ai l'impression que l'on a un nouveau troll : Qt vs Mono. A moins qu'il existait déjà...
                          • [^] # Re: Qyoto/Kimono

                            Posté par . Évalué à  1 .

                            Il est portable, mais ne fonctionne (dans son intégralité donc pas Mono) que sur MSWindows son environnement d'origine. Au niveau portabilité on a vue mieux.
                      • [^] # Re: Qyoto/Kimono

                        Posté par . Évalué à  1 .

                        Très bien comment ferais tu mieux ?
            • [^] # Re: Qyoto/Kimono

              Posté par (page perso) . Évalué à  5 .

              J'ajouterai que le socle technique de .NET/Mono normalisé ISO propose une méthode pour écrire des bindings bien plus portable qu'en Java par exemple.
              Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
              Mais tout ca suppose des API binaires portables et standardisés, ce que n'offre pas C++ avec son foutu nommage à la con des méthodes.
              http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_(...)
              • [^] # Re: Qyoto/Kimono

                Posté par . Évalué à  -4 .

                >J'ajouterai que le socle technique de .NET/Mono normalisé ISO propose une méthode pour écrire des bindings bien plus portable qu'en Java par exemple.
                Ca ce passe de commentaire...
                >Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
                Tu dis vraiment n'importe quoi.
                • [^] # Re: Qyoto/Kimono

                  Posté par (page perso) . Évalué à  2 .

                  Ce qui est quand même hallucinant, c'est que je te donne un exemple concrêt de binding portable, que j'utilise de manière portable, bref la vraie vie, et tu trouves le moyen de dire que je dis n'importe quoi.
                • [^] # Re: Qyoto/Kimono

                  Posté par . Évalué à  4 .

                  >J'ajouterai que le socle technique de .NET/Mono normalisé ISO propose une méthode pour écrire des bindings bien plus portable qu'en Java par exemple.

                  Faut le reconnaitre, Timaniac marque un point.
                  Invoquer du code natif en Mono avec P/Invoke c'est nettement plus simple que de passer par la JNI. D'ailleurs, la communauté Java a fini par pondre JNA (Java Native Access) qui s'inspire ouvertement des P/Invoke mais également ctypes (Python).

                  Un billet que j'ai lu il y a un moment et qui résume bien pourquoi JNI sapugrave.
                  http://www.koushikdutta.com/2009/01/jni-in-android-and-forew(...)
                • [^] # Re: Qyoto/Kimono

                  Posté par (page perso) . Évalué à  5 .

                  He les gens je voudrais rappeler que toute les applis ont pas un but cross platform. Certaines se foutent de Linux, Mac OS ou même vice-versa. Ces applications utilisent Qt juste parce que l'API est bien et les fonctionnalités présentes.

                  Si y'a moyen de faire de l'ActiveQt c'est pour certaines applis sous Windows et SEULEMENT sous Windows qui veulent bricoler du .Net. C'est purement pour faire parfois parler des applis .Net avec des applis Qt.

                  Ah oui et je rappelle que ActiveQt ou ce que c'etait avant existe depuis 2002 bien avant Mono (avec COM, MFC et co). Donc aucun rapport avec Mono.

                  Utiliser ActiveQt c'est comme avoir un XPixmap dans son code tu tue le cross-platform de ton applis. Après a coup de ifdef tu peux t'en sortir. Tu te plains de la doc qui prône le fait que ça soit crado mais bon c'est pour ça que tu as Qt, pour pas utiliser .Net et son implémentation incomplète sur Linux avec Mono.

                  Qt a ses avantages et ses défauts (binaire pas facilement deployable sur certaines archi par exemple).

                  Honnêtement je pense pas que c'est dans le scope de Qt de s'occuper de ce genre de bindings. Laissons la communauté le faire si ils ont besoin et le veulent. Je trouve que c'est juste inutile mais c'est mon avis.
                  • [^] # Re: Qyoto/Kimono

                    Posté par (page perso) . Évalué à  2 .

                    Je suis d'accord qu'il faut laisser la communauté développer les bindings dont elle a besoin.
                    Mais Nokia pourrait tout de même faire un truc de base qui intéresserait tout le monde : un binding C officiel et maintenu. Ca simplifierait les bindings dans tous les langages.
      • [^] # Re: Qyoto/Kimono

        Posté par (page perso) . Évalué à  -1 .

        Le support de .Net est très inégal entre l'implémentation de Microsoft et l'implémentation de Mono.
        D'où l'idée d'utiliser des frameworks comme Qt dont l'implémentation de référence elle-même est portable.
        Ca marche très bien avec GTK+mono, parcque l'implémentation de référence de GTK est portable.
      • [^] # Re: Qyoto/Kimono

        Posté par . Évalué à  4 .

        Sans vouloir vexer les développeurs et les fanboys Mono, avec le procès TomTom, ça sent le paté cette techno.
        • [^] # Re: Qyoto/Kimono

          Posté par (page perso) . Évalué à  3 .

          Sans vouloir vexer les FUdeurs anti-mono, avec le procès TomTom on voit clairement qu'il est aussi dangereux d'utiliser Linux que Mono.
          • [^] # Re: Qyoto/Kimono

            Posté par . Évalué à  2 .

            D'ailleurs, il semblerait que le fait de respirer puisse avoir des conséquences mortelles à long terme.
          • [^] # Re: Qyoto/Kimono

            Posté par Anonyme . Évalué à  1 .

            Ah ah ah très drôle. Franchement j'aimerais voir Microsoft attaquer de front Linux , pas comme des petites tapettes (Précisons que Microsoft dit qu'elle n'attaque pas le FAT de Linux mais l'implémentation particulière de FAT faite par TomTom (inexistante comme précisé dans un des journaux sur le sujet)) mais ça ils sont pas assez débile pour le faire car cela serait direct un démantèlement de la boite dans le cadre de la loi anti-trust.
  • # Qt Extended abandonné à son tour

    Posté par . Évalué à  3 .

    C'est apparemment passé inaperçu, mais Qt Extended (ex Qtopia, la plateforme de dev pour l'embarqué) subit le même sort que Qt Jambi : la dernière version officielle sera la 4.5, puis le bébé sera donné à la communauté.
    Il semble donc que Nokia fasse le ménage dans ses plateformes pour embarqué, mais entre Maemo, Symbian et Qt extended, il aurait peut-être fallu en supprimer une autre ...
    • [^] # Re: Qt Extended abandonné à son tour

      Posté par (page perso) . Évalué à  6 .

      Qt Extended était la platforme contenant des applications pour téléphone mobile

      En gros, depuis quelques années déjà, le code utile de Qtopia est déplacé progressivement dans Qt lui-même (Qt Embedded Linux, ...)

      Avec Qt Embedded Linux, Qt Windows CE, Qt S60. Cela fait 3 platforme de dev pour l'embarqué pris en charge par Qt

Suivre le flux des commentaires

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