Journal Un équivalent libre de flash grace à Qt?

Posté par  (site Web personnel) .
Étiquettes : aucune
0
27
avr.
2006
Pour Qt 4.2, les gens de trolltech sont en train de nous coder un nouveau canvas nommé QGraphicsView permettant de manipuler des images, vidéos et bientot du svg!

http://www.kdedevelopers.org/node/1927

Pour l'instant, c'est pas fini mais l'objectif est d'avoir un équivalent à flash grace à svg et à QGraphicView.

Bon, ca risque de rester sur le bureau Kde (dépendance Qt oblige) mais ca promet de bonne chose pour plasma qui va utiliser ca!

Bref, vivement kde 4.0!
  • # Et pendant ce temp là....

    Posté par  . Évalué à 7.

    ... Gnash avance de son coté : http://www.gnu.org/software/gnash/
    • [^] # Re: Et pendant ce temp là....

      Posté par  . Évalué à 4.

      Tu en sais un peu plus ? i.e. le status, des screenshot...
      • [^] # Re: Et pendant ce temp là....

        Posté par  . Évalué à 1.

        La première étape qui consistait à reprendre le code de GameSWF et y faire un peu de ménage est terminée. J'en étais resté à la deuxième étape : le développement des plugins firefox et konqueror. Et récemment (le 26 avril), sur la mailing list (dans un fil de discussion à propos de la création d'un paquet debian) Rob Savoye a indiqué :
        I'm hoping to do the official release soon. I'm only now waiting to hear
        back from the Mozilla Foundation about the specific wording of the
        GPL exemption, since I'd hate to make a release with an unsatisfactory
        license clause. All the other paperwork is done, and the FSF has
        accepted the copyright assignment for this project.


        Si j'ai bonne mémoire, l'étape suivante consistera en une réorganisation en profondeur du code.
  • # encore un !

    Posté par  (site Web personnel) . Évalué à 8.

    C'est dingue comment les gens ne peuvent s'empêcher de troller dès qu'ils parlent de KDE :

    "Bon, ca risque de rester sur le bureau Kde (dépendance Qt oblige)"


    Depuis quand une dépendance Qt empêche d'utiliser un logiciel sous un autre environnement que KDE ?
    De même que c'est pas parce que je suis sous KDE, que je ne peux pas utiliser de logiciel dépendant de GTKtruc !! (je le fais)

    Bon à part ça, intéressant ce journal :-)
    • [^] # Re: encore un !

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

      T'as pas compris le sens de ma phrase ;)

      Je voulais dire que ca va pas permettre de présenter une vrai alternative à flash vu que c'est un techno propre à Qt et donc impossible d'avoir ca sur le web...

      C'était tout ce que ca voulait dire, faut pas chercher le troll partout ;)
      • [^] # Re: encore un !

        Posté par  (site Web personnel) . Évalué à 8.

        Merci de ton éclaircissement, je comprends mieux ce que tu veux dire.
        Cependant :
        «ca va pas permettre de présenter une vrai alternative à flash vu que c'est un techno propre à Qt»

        Et flash, ce n'est pas une techno propre à macromedia ?
        QT est disponible sur plusieurs plateformes (windows, Mac et X11, sans parler des dérivés pour l'embarqué par exemple). Flash (depuis la version 8) n'est officiellement disponible que pour windows et Mac : http://www.macromedia.com/fr/software/flashplayer/productinf(...)

        Donc je voit pas ce qui pourrait empêcher cette techno de concurrencer flash ! Après, il faut voir ce que ça donne bien sûr ...
        • [^] # Re: encore un !

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

          Ben intégrer du Qt dans un navigateur GTK ou Win32, ca risque d'être... lourd et pas intégré ?
          • [^] # Re: encore un !

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

            Et pourquoi serait-ce plus lourd et moins intégré que du flash ?
            • [^] # Re: encore un !

              Posté par  (site Web personnel) . Évalué à 7.

              J'ai jamais dis que Flash était mieux :)
              Mais bon je trouve dommage de devoir charger des libs Qt dans un navigateur écrit avec d'autres libs... Comme si le pauvre Firefox bouffait déjà pas assez de ressources comme ca avec son propre toolkit qui tente d'utiliser le toolkit sous-jacent :)
              • [^] # Re: encore un !

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

                Bon d'accord
                Mais il y a une différence entre trouver ça dommage, et dire que «ca risque de rester sur le bureau Kde».

                Sur le fait de trouver ça «dommage de devoir charger des libs Qt [...]», on retombe dans un débat qui ne pourrait avoir raisonnablement lieu avant demain ... ;-)

                Perso je trouve pas dommage d'avoir à charger des libs libres plutôt que d'autres qui ne le sont pas !

                Mais effectivement un protocole basé uniquement sur du SVG + ECMAScript avec des implémentations intégrées pour les différents bureau serait l'idéal.
                • [^] # Re: encore un !

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

                  Le truc c'est que d'un point de vue technique rien n'oblige à utiliser un framework essentiellement orienté widgets graphiques (je dis pas que y'a que ca) comme, j'ai un peu du mal à voir ce que la dépendance à Qt apporte pour faire de la composition telle qu'on la voit dans ce nouveau widget... Surtout qu'il y a des moteurs de rendus existants et plus "indépendant" comme Cairo, OpenGL, SVG, y'avait quand même moyen de faire avec l'existant non ?
                  C'est un peut pareil pour le moteur Kat, je vois vraiment pas l'intérêt de rendre toute la partie recherche/indexation dépendante de Qt/KDE... Ca limite toute de suite son exploitation dans d'autres contextes.
                  Voilà c'est peut être à cause de gars avec des idées comme moi qu'on retombe dans des trolls classique KDE :-p (pour répondre à ton premier post)
                  • [^] # Re: encore un !

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

                    1) Si tu lis les articles, ce composant utilise OpenGL et SVG. Je pense que justement il essaye de fusionner différentes technos, mais bon je n'en sais pas plus non plus donc je ne m'avancerai pas plus.
                    2) Pour Kat, je pense tout simplement que si il est dépendant des libs KDE, c'est peut-être tout simplement parce qu'il les utilise !
                    3) Tu mélanges un peu tout
                    4) Ça devient lourd cette manie de remettre en question l'utilisation de libs !
                    • [^] # Re: encore un !

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

                      1) En fait il aurait fallu corriger ma phrase par : y'a déjà des implémentations de OpenGL, de SVG, y'a Cairo, autant d'implémentation qui sont indépendantes de Qt. Y'avait moyen de continuer dans cette voie pour fusionner le tout sans ajouter une dépendance à Qt/KDE, ca aurait profité à tout le monde. A moins que tu m'expliques enfin en quoi Qt/KDE est utilisé dans ce cas précis.

                      2) Pour Kat : j'ai bien compris qu'il était dépendant de KDE et qu'il l'utilise, c'est justement ma remarque, mais explique moi en quoi cette dépendance est utile ? Qu'apporte Qt et/ou KDE pour faire un moteur d'indexation/recherche ?

                      3) Sûrement :)

                      4) Bah tu sais, chez KDE ils ont pas voulu utiliser Beagle parcque dépendant de Mono alors bon :) Enfin c'est rigolo toi tu te bas pour qu'on arrête de râler sur la dépendance envers Qt/KDE, moi j'ai exactement le même combat avec Mono ;) (et comme quoi je suis pas logique pour 2 sous)

                      Utiliser des libs, ok, mais quand c'est pertinent ! Je vais encore me faire moinsser à insister, mais explique moi en quoi il est utile et pertinent d'utiliser Qt/KDE dans l'exemple de ce journal et dans Kat ? Si tu m'expliques l'intérêt d'utiliser Qt/KDE, pas de problème ! Mais on peut quand même s'interroger sur l'utilité de cette dépendance quand elle ne saute pas aux yeux non ? (surtout qu'on a toujours pas les explications)
                      • [^] # Re: encore un !

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

                        Je ne te moinsserai pas, ton argumentaire est bien exposé :-)

                        Je voudrais ajouter quelques éléments au 4) et au dernier paragraphe.

                        Je suis d'accord pour dire que vu de haut, on dirait une guerre des librairies, toolkits et autres frameworks, comme pour l'exemple de kat que tu cites. Moi je pense qu'il faut garder à l'esprit que les devs impliqués dans les applications du projet KDE (par exemple), sont généralement là parce qu'ils sont tombés amoureux du framework proposé. Ça se discute, certes, mais je pense que c'est un fait indéniable. Alors forcément en tant que développeur, je peux comprendre qu'ils aient envie de produire des choses conceptuellement et technologiquement unifiées, ou consistantes pour employer un anglicisme. De plus, les développeurs maitrisent leur technologie, ce qui leur garantit de faire moins d'erreurs et de mieux communiquer entre eux, je pense.

                        Voilà mon point de vue.
                        Mais je comprends ce que tu veux dire. Je n'ai a priori rien contre mono, mais je ne le connais pas.
                        • [^] # Re: encore un !

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

                          Je comprend tout à fait ce point de vue, chacun est libre de coder avec la plateforme qu'il aime/connaît/maîtrise. Mais je suis persudader que cela ne doit aller pour autant à l'encontre de la réutilisation/unification. On peut très bien utiliser un toolkit/framework particulier mais exposer des APIs "indépendant" qui forment une sorte de couche d'abstraction.

                          Mais là encore tout dépend de la nature du service fournit. En l'occurence la valeur ajoutée du widget proposé ne semble pas être dans le rendu proprement dis (si j'ai bien compris après quelques investigations) mais plus dans l'intégration dans un widget Qt justement de technos déjà Qt. La dépendance me paraît donc justifiée (mais bon je pensais que tu me l'aurais dis ;) )

                          Dans le cas de Kat par contre je trouve ca abbérent. D'un côté on a des initiatives comme freedesktop ou linuxstandardbase qui tente d"unifier des points communs entre les desktop/distri pour faciliter grandement l'interopérabilité et plus généralement le succès des technos/protocoles ainsi "standardisés", et d'un autre côté on se retrouve avec de nouveaux cloisonnement technologiques : on aurait pu avoir un serveur d'indexation unifié avec une base de données standard, mais non, le projet KDE préfère se diriger vers sa propre solution "proprio" alors qu'une solution "ouverte" existe déjà. Je trouves que ca va à l'encontre d'efforts fait par ailleur. C'est sans doute à cause de mauvais exemple comme Kat que certains deviennent "méfiant" à chaque nouvelle "techno" Qt/KDE.
                          Enfin voilà, j'espère que dans l'avenir on aura pas à faire "F11" pour rechercher dans ses documents Gnome et "F12" pour rechercher dans ses documents KDE, avec en prime 2 moteurs d'indexations qui bouffe le double de ressources en permanence.
                          • [^] # Re: encore un !

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

                            on aurait pu avoir un serveur d'indexation unifié avec une base de données standard, mais non, le projet KDE préfère se diriger vers sa propre solution "proprio" alors qu'une solution "ouverte" existe déjà.


                            Déjà, Kat, c'est du LGPL/GPL, donc j'aimerai bien que tu m'explique en quoi c'est du proprio, ou alors en quoi c'est + proprio que Beagle?

                            Ensuite, Beagle est à la base un port mono de Lucene. dans ta logique, pourquoi ne pas avoir gardé Lucene et recodé ça en ajoutant une dépendance "proprio". C'est exactement pareil.

                            En réalité, tu sais bien que si le démon Beagle avait été fait sans dépendance style java/mono (genre c ou c++), avec une interface mono, Kat n'aurait été aussi qu'une simple interface aussi, et tout aurait été propre et freedesktop ready. Simplement, les gas de Beagle ont foutu du mono dans l'unique but de promouvoir cette techno, donc faut pas etre étonné de ce qui arrive hélas.
                            • [^] # Re: encore un !

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

                              Déjà, Kat, c'est du LGPL/GPL, donc j'aimerai bien que tu m'explique en quoi c'est du proprio, ou alors en quoi c'est + proprio que Beagle?
                              J'ai mis des guillemets pour bien indiquer que c'était pas le terme "proprio" habituellement utilisé au sens des licences. C'est proprio au sens où ca n'encourage pas l'interopérabilité en dehors de KDE.

                              Ensuite, Beagle est à la base un port mono de Lucene
                              Pas du tout. Beagle "utilise" une lib d'indexation qui est à la base un port en .NET de Lucene. Mais Beagle n'est pas Lucene. Beagle c'est lui qui "donne" à manger à Lucene si tu préfères. De la même manière d'ailleur que Kat utilise cLucene. Lucene n'est absolument pas le problème.
                              Mais Beagle est parfaitement exploitable dans d'autres environnements que Mono : en C, en python, en C++, etc. Beagle est même interrogeable par web-services, question interopérabilité tu veux quoi de plus ? C'est une boîte noire, l'utilisation de Mono est complètement cachée. Kat y'a quoi pour l'utiliser en dehors d'une appli C++/KDE ?

                              En réalité, tu sais bien que si le démon Beagle avait été fait sans dépendance style java/mono (genre c ou c++), avec une interface mono, Kat n'aurait été aussi qu'une simple interface aussi, et tout aurait été propre et freedesktop ready.
                              Vois pas du tout en quoi l'utilisation de Mono empêche force les programmes utilisateurs de Beagle à utiliser Mono. La meilleur preuve est encore que la deskbar de Gnome écrite en Python utilise Beagle.
                              Question de la FAQ :
                              "Does beagle work in KDE ?"
                              "Yes it does."
                              Quand tu vas sur la page de Kat ils mettent :
                              "the Gnome program Beagle "
                              En gros dans leur tête Beagle c'est la guéguerre Gnome/KDE C++vsMono. Alors que le projet Beagle se tue à expliquer qu'ils est tout à fait possible de l'utiliser avec KDE.


                              Simplement, les gas de Beagle ont foutu du mono dans l'unique but de promouvoir cette techno
                              Peut être parcqu'ils aiment cette techno c'est tout.
  • # mouaif

    Posté par  . Évalué à 10.

    le probleme c'est pas tant le manque d'alternative dans les moteurs de rendus (svg doit pouvoir faire le poid face a flash sur un point de vue purement technique), c'est plutot le manque d'outil pour developper des animations pour ces moteurs de rendus.

    Ce qui fait en partie le succes de flash, c'est son editeur, qui permet d'etre productif toussa.

    A mon avis, c'est plutot la dessus qu'il faut se concentrer.
    (Et aussi sur le support de svg dans les navigateurs, bien evidemment)
    • [^] # Re: mouaif

      Posté par  . Évalué à 2.

      L'autre problème c'est le support Javascript/SVG face à ActionScript qui commence à pouvoir ne pas rougir en face d'autres "grands".

      Imaginez faire une application riche avec Javascript/SVG ??? ....
      • [^] # Re: mouaif

        Posté par  . Évalué à 2.

        tu veux dire en ajax par exemple? :-D

        Railleries mises a part, j'ai un gros doute sur le fait d'utiliser flash pour des applis riches.
        Ne serait ce que par les limites de la programmation pour le code metier et l'absence de bibliotheques comme on peut en trouver pour les autres gros langages sur ce terrain.

        Par contre, pour des clients lourds de webapps (ie quasi aucun traitement cote client, tout se fait cote serveur), on doit pouvoir faire des choses sympas.
        Genre un client webmail lourd moins sujet aux problemes d'implem' de javascript, hors du navigateur, ce qui pourrait mettre le webmail au meme niveau de confort d'utilisation qu'un client riche.
        Sur ce segment, je pense que ca serait un atout non negligeable et reduirais drastiquement le temps de dev.
        Ne serait ce que pour empecher l'utilisation du precedent/suivant qui pourrit la navigation et atomiser les problemes de rendus css dans les differents navigateurs, par exemple.

        Maintenant, ce genre d'appli n'est pas tres repandu non plus.

        Bref, tout ca rentre en plein dans la problematique du web 2.0

        Note : la je parle purement technique, merci de ne pas me prendre la tete avec des histoires de licences/libertes.
        • [^] # Re: mouaif

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

          Genre un client webmail lourd moins sujet aux problemes d'implem' de javascript, hors du navigateur, ce qui pourrait mettre le webmail au meme niveau de confort d'utilisation qu'un client riche.
          En même temps y'a java qui a le mérite d'être un "vrai" langage (mes souvenirs d'actionscript me laissent le souvenir d'un javascript plus que d'un Java).
          C'est peut être un peu lourdingue à charger, mais une fois lancé c'est bon. Et puis les implémentations libres sont déjà bien avancées (même si ça ne te préoccupe pas).

          Du reste, tu semble admettre qu'un gmail est moins "confortable" qu'un ThunderBird ou un Kmail, ce que je pense aussi mais qui ne feras peut etre pas l'unanimité.
          • [^] # Re: mouaif

            Posté par  . Évalué à 2.

            j'ai deja codé un client lourd pour une webapp (en Java), c'est 99% d'ihm.
            Honnetement, c'est lourd et dommage de passer autant de temps sur un langage haut niveau pour faire uniquement de l'IHM.

            Du reste, tu semble admettre qu'un gmail est moins "confortable" qu'un ThunderBird ou un Kmail, ce que je pense aussi mais qui ne feras peut etre pas l'unanimité.
            Note que je ne connais pas du tout gmail.
            J'utilise yahoo qui a fait un clone d'outlook tres recemment en javascript.
            Bon c'est sur que ca marche foutrement bien mais ca reste embedde dans le navigateur (et dependant du navigateur, ie j'ai pas le droit a la nouvelle interface sur mon linux FF 1.0.x ni sous mon safari).

            Ca veut dire que j'ai le panneau des bookmarks a gauche, la barre webdevelopper qui me sert a rien, j'ai pas l'icone FF dans ma barre de taches, je ferme l'onglet sans le vouloir, tout ce genre de choses quoi, c'est plus a ce niveau que je situe le "confort".

            Un genre de player flash/svg/c'quevousvoulez stand alone permettrait de combiner a la fois les avantages du webmail et du client mail standard. Et ca doit pouvoir s'appliquer a toute appli web qui a tres peu de code metier cote client et consiste donc en une simple couche presentation.
          • [^] # Re: mouaif

            Posté par  . Évalué à 2.

            Et puis les implémentations libres sont déjà bien avancées (même si ça ne te préoccupe pas).
            C'est pas que ca me preoccupe pas, c'est juste que dans mon message precedent, j'abordais le probleme d'un point de vue purement technique (le besoin etant encore relativement mal identifie et les solutions concues de bric et de broc).
            Apres la licence, c'est un detail d'implementation laisse a l'appreciation du projet, qui n'a de toutes facons aucune incidence sur la discussion.

            Pour les implem' libre de java, ce que j'en pense...
            Bah deja je vois pas l'interet de compiler du java en statique (le JIT etant un des principaux interets du langage) et surtout les alternatives ne sont pas utilisable en production. A surveiller du coin de l'oeil quoi.
            Ouala, ca n'engage que moi et je suis en train de faire glisser le troll la. :-P
    • [^] # Re: mouaif

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

      entièrement d'accord

      Parce que franchement, quand on voit tout ce qu'on peut faire :
      http://svg-whiz.com/samples.html
      http://srufaculty.sru.edu/david.dailey/svg/SVGAnimations.htm
      http://www.croczilla.com/svg/samples/svgtetris

      y'a du potentiel !

      Par contre, je ne sais pas si SVG peut véritablement être positionné face à Flash dans lequel on peut trouver des vidéos et du son ?
      • [^] # Re: mouaif

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

        Les 3/4 ne marchent pas sous Firefox et ceux qui marchent font ramer le PC comme un goret :(

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: mouaif

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

          exact, il faut le plugin Acrobat (sapusaipalibre)

          et là, la parenthèse finale de kraman
          (Et aussi sur le support de svg dans les navigateurs, bien evidemment)
          prend tout son sens.

          Mais je crois que Safari et Opéra ont leur propre implémentation SMIL,donc quelle que soit ta plateforme (ou presque), tu devrais pouvoir admirer le potentiel de SVG.
        • [^] # Re: mouaif

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

          FF 1.5 a le support SVG en natif.

          FF 1.5 et Opera 9 ont mieux que le SVG, c'est le canvas qui est en cours de normalisation par le W3C.
          http://standblog.org/blog/2005/09/13/93114364-firefox-15-pou(...)
      • [^] # Re: mouaif

        Posté par  . Évalué à 6.

        A la base, SVG n'a absolument pas pour but de concurrencer le flash ! Mais simplement de fournir un format d'image vectoriel portable.
        Tandis que le flash a vraiment pour but de faire un système interactif...

        Mais bon, petit a petit, le SVG devient du flash...
        • [^] # Re: mouaif

          Posté par  . Évalué à 3.

          C'est pas plutôt la combinaison de SVG + Javascript + DOM + SMIL qui est un concurrent de Flash?

          Le seul problème reste la vidéo et le son, qui nécessitent d'avoir les bons codecs...
  • # Que vient faire flash???

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

    Flash, c'est compatible IE/FF/Opera, Windows/MacOS/Linux/etc...

    La, tu me parles d'un truc en Qt, qui dependrai donc d'une compilation suivant la plate-forme, bref, du client lourd.
    Flash, c'est du client léger, independant de la plate-forme (suffit d'avoir le plugin Flash).

    Bref, j'aimerai avoir tes arguments qui te font dire que ca sera un equivalent libre a Flash...
    • [^] # Re: Que vient faire flash???

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

      Précision : Flash n'est pas compatible «Windows/MacOS/Linux/etc...» ;-)
      Voir mon commentaire #705687
    • [^] # Re: Que vient faire flash???

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

      En tout cas, flash n'est pas compatible Linux, mais seulement Linux x86. Ce qui, avec les architecture 64bits, va commencer à pas faire grand monde.

      En particulier, le player flash de macromedia n'est pas compatible x86_64 sauf à le faire tourner dans un chroot ou avec la version 32bits du navigateur.

      PS: oui je connais : http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper mais ça n'est pas encore tout à fait fonctionnel et de toute façon ça ne fait pas fonctionner en 64bits le player flash.
    • [^] # Re: Que vient faire flash???

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

      Ben non pas client lourd...

      Pourquoi ne serait-il pas possible de faire un plugin basé sur cette techno (le machin de qt) et lui envoyer la description du machin dans un format de fichier quelconque (qui existe peut-être déjà). Et dans ce cas, y a que le plugin à recompiler sur chaque plateforme et c'est tout.
  • # Mais finalement, l'article n'a rien avoir avec Flash

    Posté par  . Évalué à 6.

    Si j'ai bien compris, c'est que le nouveau composant permettra de rassembler des objets 2D vectoriels, videos, sons et de les manipuler facilement (bref, un nouveau super widget Qt4 orienté multimedia).

    Le fait que l'on puisse les manipuler et l'intégration des technos SVG permettra de les éditer facilement et de concevoir des interfaces vectorielles et de les sauvegarder en fichier SVG. Ensuite, une moulinette viendra les transformer en code natif pour la future interface de KDE4 (qui sera donc essentiellement basée sur une interface 2D vectorielle + objets multimédias).
    Le seul lien avec Flash, c'est que ce sera donc aussi une IHM 2D vectorielle avec du multimédia comme ce que l'on a pu voir dans les objets Flash, mais finalement, ça n'a rien à voir. Ou alors, on peut dire que le desktop KDE4 ressemblera à une grosse appli Flash.
  • # Le même

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

    Juste histoire de suivre un peu, cairo est déjà utilsié dans Gtk+ (depuis la 2.8) :
    http://cairographics.org/
  • # Je rajoute juste un petit commentaire

    Posté par  . Évalué à 2.

    Quelque chose de pas forcément clair dans le post, et que je précise juste pour info, Qt gère déjà le SVG!
    En effet dans le post, on aurait tendance à croire que cela n'est pas le cas, mais si. En fait l'apport de Qt 4.2, c'est le remplacant de QCanvas (et class assocèes) qui avait disparu avec Qt et ce faisait attendre je trouve.
    Mais en ce qui concerne SVG, les QLabel (Widget d'affichage basique -texte, images,..- gére déjà le SVG (ainsi que les PNG packagers d'ailleurs ce qui fait de petites animations, mais bon... je suis pas sur )que cela soit réellement du MNG, c'était juste pour info)

Suivre le flux des commentaires

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