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!
Journal Un équivalent libre de flash grace à Qt?
27
avr.
2006
# Et pendant ce temp là....
Posté par Snarky . Évalué à 7.
[^] # Re: Et pendant ce temp là....
Posté par Geo Vah . Évalué à 4.
[^] # Re: Et pendant ce temp là....
Posté par letsyl . Évalué à 1.
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 Nicolas Dumoulin (site web personnel) . Évalué à 8.
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 gnumdk (site web personnel) . Évalué à 6.
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 Nicolas Dumoulin (site web personnel) . Évalué à 8.
Cependant :
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 TImaniac (site web personnel) . Évalué à 3.
[^] # Re: encore un !
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 10.
[^] # Re: encore un !
Posté par TImaniac (site web personnel) . Évalué à 7.
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 Nicolas Dumoulin (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à -2.
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 Nicolas Dumoulin (site web personnel) . Évalué à 10.
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 TImaniac (site web personnel) . Évalué à 0.
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 Nicolas Dumoulin (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 1.
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 Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 1.
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 kraman . Évalué à 10.
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 Paul . Évalué à 2.
Imaginez faire une application riche avec Javascript/SVG ??? ....
[^] # Re: mouaif
Posté par kraman . Évalué à 2.
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 un_brice (site web personnel) . Évalué à 1.
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 kraman . Évalué à 2.
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 kraman . Évalué à 2.
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 Mat (site web personnel) . Évalué à 2.
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 Infernal Quack (site web personnel) . Évalué à 2.
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 Mat (site web personnel) . Évalué à 1.
et là, la parenthèse finale de kraman
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 DPhil (site web personnel) . Évalué à 2.
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 Snarky . Évalué à 6.
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 sanao . Évalué à 3.
Le seul problème reste la vidéo et le son, qui nécessitent d'avoir les bons codecs...
[^] # Re: mouaif
Posté par bonnaud frederic (site web personnel) . Évalué à 2.
pour la vidéo : mpeg 2 et xvid ne sont pas de bons codecs ?
# Que vient faire flash???
Posté par Zenitram (site web personnel) . Évalué à -6.
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 Nicolas Dumoulin (site web personnel) . Évalué à 6.
Voir mon commentaire #705687
[^] # Re: Que vient faire flash???
Posté par kowalsky . Évalué à 2.
Pour l'avoir, je dois utilisé le binaire linux. Cool...
[^] # Re: Que vient faire flash???
Posté par bonnaud frederic (site web personnel) . Évalué à 5.
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 allcolor (site web personnel) . Évalué à 4.
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 Frédéric COIFFIER . Évalué à 6.
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 nojhan (site web personnel, Mastodon) . Évalué à 3.
http://cairographics.org/
# Je rajoute juste un petit commentaire
Posté par blackshack . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.