Posté par clearstream () le 22/08/2006 à 19:24. (lien). Évalué à 1.

> Si le backend X a un bug, je ne vois pas en quoi c'est lié à Phonon

Je considérais le cas où Phonon a un bug avec un backend spécifique.

> ni en quoi ça constitue un échec pour lui.

OK, l'argumentaire était mal foutu.

> Au contraire, dans ce cas-là, l'intérêt saute aux yeux.

Il saute au yeux si on part du principe que le logiciel libre n'est pas foutu d'avoir un framework qui ne sucks pas et que Phonon roxe. J'ai déjà argumenté sur ce point.
Si le libre fait un framework qui roxe comme Xorg ou est l'intérêt d'avoir deux ou plus serveurs X11 différents et une couche au dessus pour basculer de l'un à l'autre s'il y en a un qui sucks ? Il y a un intérêt sur le papier mais la quantité de ressource pour fiabiliser tout ça est énorme, beaucoup plus énorme que de faibiliser seulement Xorg. Hors les ressources du libre sont assez limités.

Tu peux facilement balayer mon argument en disant que l'histoire montre que les frameworks multimédia libres sucks et que je suis un gros naïf.
Mais voilà, je ne veux pas croire que celà va perdurer, je ne veux pas que ça perdure.

> Si un backend est vraiment mauvais (i.e. pas d'amélioration au fil des versions), il sera peu utilisé et le backend sera abandonné. Où est le problème ?

Dans le contexte actuel où les frameworks sucks, t'as raison.
Mais pourquoi diable il faudrait se résoudre à croire que le logiciel libre ne peut que merder que les frameworks multimédia ?

[ Répondre ]

Posté par clearstream () le 22/08/2006 à 00:28. (lien). Évalué à 2.

> 1) Il y a la question de la stabilité de l'API. Même en contribuant beaucoup à un framework, les dev KDE ne seront jamais maîtres de l'API.

C'est vrai. Mais c'est vrai aussi pour plein de domaines et c'est aussi vrai pour Gnome et en fait vrai pour tout le monde.
La stabilité API, ça peut être fait très simplement et ce n'est pas la montage que sous-entend KDE. Par exemple il y a longtemp eu Gtk 1.x alors que Gtk 2.0 était sorti depuis longtemps. Il n'a pas été fait une encapsulation au dessus de gtk2 et gtk1. Conserver Gtk 1.x n'a pas été une montage de boulot (quoique le "split" n'a pas été simple au début). Tous les Gnome 2.x ont esound pour conserver la compatibilité. Ca ne représente pas beaucoup de boulot (voir zéro) et sûrement moins que de maintenir Phonon pour qu'il suive les modifications d'API de plusieurs backends. La nécessité de compatibilité n'entrave pas l'évolution de Gnome (ajout de Gstreamer durant la branche 2.x, et vas savoir si Xine ne va pas pointer le bout de son nez durant Gnome 3.x s'il roxe) alors que l'évolution de KDE sur plusieures années (la durée de vie de KDE 4) est contrainte au plus petit dénominateur commun des backends et ils se donnent beaucoup de boulot.

> Conséquence directe, quand l'API d'un framework change, ce n'est pas toutes les applis qui doivent s'adapter, mais seulement Phonon.

Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".

Certes, tout ceci est assez voire très subjectif. Mais tu crois que les utilisateurs de Linux dans leur ensemble seraient plus content aujourd'hui si depuis le début de Linux 2.6, Linux avait conservé une compatibilité "obsolue".
Oui la politique de Linux 2.6 parfois sucks (le driver bidule qui explose en vole lors du passage de Linux 2.6.n à 2.6.n+1 par exemple). Mais la politique de la stabilité absolue sucks, et gravement, dans des domaines aussi dynamiques que le desktop.
Si la politique de Phonon était l'évidence, alors la politique de Linux 2.6 serait évidente de stupidité.

La compatibilité "absolue" est importante pour des cas comme php. Pour php, des *milliers* de site en production et "sensibles", chaqu'un avec des milliers de lignes de code php spécifiques, en dépendent.
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).

Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.

Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).

Esound est un bonne exemple qui montre qu'il n'y a pas toujours de fortes exigences en compatibilité binaire dans le desktop. Bien que esound soit le "standard" supporté par Gnome pour la branche 2.x, presque aucune distribution ne le livre maintenant car presque aucune application ne l'utilise encore. Elles sont toutes passées à autre chose. Je crains que Phonon, à l'instar de Esound et aussi Arts, subisse le même sort.

> Mais tu trouvera toujours un utilisateur qui voudra celui que tu n'as pas choisi, pour une raison X ou Y, recevable ou non, mais dont il ne démordra pas.

C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.

> D'où la très grande utilité de Phonon, même pour l'utilisateur : si j'ai envie d'utiliser Xine, je le dis à Phonon, et je n'ai pas à le dire à chaque appli.

Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Pour l'utilisateur ça a un sens si Phonon échoue dans ses objectifs (typiquement ne marche pas avec le backend X pour cause de bug mais marche avec le backend Y).
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?

Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...


Ceci dit, je me trompe peut-être. A mon sens, le point le plus faible de mon argumentaire, est que Phonon n'existe pas encore. Il n'a pas fait ses prèves en bien ni en mal. Donc, si vous êtes convaincu par Phonon, foncez et codez un Phonon qui roxe des ours. Je sais, vous n'avez pas besoin de mes encouragements et vous vous en foutez :-)

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 21:47. (lien). Évalué à 1.

> Peut-être préfères-tu, comme dit plus bas, ce qui se passe en ce moment avec le dev d'amarok (ou de tout autre lecteur multimédia, juk par exemple) obligé de développer un connecteur pour xine, un autre pour gstreamer (qui d'ailleurs est plus ou moins laissé à l'abandon), le tout pour *simplement* lire des fichiers audio.

Non.
Ici tu démontres qu'avoir plusieurs backends sucks. Tu démontres aussi que maintenir une interface pour plusieurs backends sucks aussi.

> Il ne s'agit ni plus ni moins que de mutualiser les efforts

Dans l'optique de supporter plusieurs backends !

Mais tu viens de le démontrer, cette démarche sucks et depuis de nombreuses années.

> d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.

Arts était "officiellement inclus dans kde". Tu connais l'histoire. Ceci dit, c'est mieux que de ne pas être inclus dans KDE.
Puis le problème avec Phonon est : que va supporter KDE ?
Phonon seulement ? => sans issue.
Phonon et Xine et NMM et Gstreamer et alsa ?
KDE avait déjà du mal à supporter Arts. Il faut aussi le reconnaitre qu'il reste beaucoup de boulot à Gnome et Gstreamer. Ceci montre que les ressources du logiciel libre sont insufisantes pour maintenir 50 backends (déjà que pour 3 ou 4 ça sucks).

> il me semble que kde pousse le modèle objet et l'encapsulation le plus loin possible et qu'ils raffolent de ce genre d'outils.

Je répète, si l'encapsulation apporte quelques choses, pourquoi pas.
Il y a un binding de Gstreamer en C++. C'est une encapsulation, ça apporte quelque chose. Les developpeurs C++ sont contents. Les développeurs C++, ce n'est pas 0,1 % des développeurs !
Si KDE veut étendre cette API ou une autre pour ajouter des fonctions qui simplifient la vie des développeurs. Go ! M'enfin Gstreamer ce n'est pas sorcier à utiliser dans un contexte simple.
Si KDE veut le faire pour autre chose que Gstreamer => Go !
Ce que fait KDE, c'est ajouter une API (pas en étendre une pour répondre à un besoin) pour faire ce que tous les backends savent déjà faire (c'est dans la définition de Phonon).

> il s'y trouve même un gnomiste pour défendre cette idée (phonon) et regretter que Gnome n'ait pas fait de même.

C'est très bien !
J'ai peut-être tord, tu as peut-être raison. Tout le monde peut se tromper mais tout le monde à le droit de défendre ses points de vu (c'est une remarque à ceux qui voudraient me "censurer").

Tu peux me trouver un KDEiste qui est contre Phonon ?

> Pour finir, nulle part il n'est, en effet, écrit que les dev seront, couteau sous la gorge, obligés d'utiliser phonon pour une appli externe à kde.

C'est le libre. C'est normal.

Pour une appli KDE :
1- Phonon pour les trucs simples.
2- Xine, GStreamer, NMM, etc pour les trucs un rien compliqués (dès que ce n'est pas dans le plus petit dénominateur commun des backens).
3- Xine, Gstreamer, NMM, etc pour les trucs compliqués.
4- Xine ou Gstreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
5- Autre chose de mieux que Phonon (le truc par défaut). La liste est longue, voire on ne peut faire plus long, de part la définition de Phonon.

=> Une API supplémentaire (et même pas une extension d'une existant) pour faire ce qu'on sait déjà faire.
=> Beaucoup de cas pour ne pas utiliser Phonon.
=> Donc les efforts seront dispersés (et non mutualisé).

Avec Gnome :
1 Gstreamer pour les trucs simples.
2 Gstreamer pour les trucs compliqués.
3 Xine ou GStreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
4 Autre chose de mieux que Gstreamer (le truc par défaut). La liste est limitée car Gnome a pris initialement le meilleur framework (du moins selon eux).

=> quelques cas pour ne pas utiliser Gstreamer.
=> Donc les efforts sont concentrés sur Gstreamer (et non dispersé). Ils sont concentrés sur ce qui fait vraiment le boulot, ce qui apporte de la valeur à l'utilisateur, et non sur un wrapper.

KDE ajoute une API et plus de raisons pour les développeurs de se disperser sur 50 backends. Avoir plein de backend sucks ! L'histoire le montre.
Et rien que pour faire des trucs simples, les développeurs doivent maintenir un truc donc le bon fonctionnement dépend de lui-même et de plusieurs backends.

> Ils ne restent donc que fidèles à leur façon de faire avec Phonon.

Non !
Pour les widgets, KDE n'encapsule QUE Qt. Pas Qt et Gtk et Xt etc... et pas en ne fournissant que le plus petit dénominateur commun d'un ensemble de "backends" graphiques.
Il n'y a qu'un "backend" graphique, c'est Qt. Il n'y a qu'un backend vfs, c'est kio, etc. Mais il y aura plusieurs backends multimédia, ce sont NMM, Xine, Gstreamer, etc...
Tu comprends la différence ?

Je n'ai rien contre que KDE encapsule QUE Xine ou autre.


Tu peux considérer que Phonon sera un succès. Si le logiciel libre n'arrive pas faire à un (voire deux) backend qui roxor des ours, il y aura encore 50 backends et il faudra vivre avec.
Si le logiciel libre sucks, Phonon va permettre que ça sucks un peu moins.
Moi, je ne veux pas que le logiciel libre sucks.
Je ne veux pas que le logiciel libre persiste dans une voix qui manifestement ne marche pas. Je n'aime pas ce qui "pousse" à persister dans cette voix qui sucks.

Le choix de KDE est peut-être judicieux. Mais il a des effets de bord non négligeables. Ils faut les reconnaitres et non avoir des oeillères devant les yeux et affirmer que l'encapsulation que fait Phonon est la même que les autres encapsulations faites dans KDE par exemple.

> Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine

Libre, libre, libre !
OK, je le sais, c'est du logiciel libre.
Libre aux développeurs de Gnome de faire comme KDE et pousser dans une voix qui sucks.

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 20:17. (lien). Évalué à 2.

> Je retourne dans les préférences, je re-change, et hop, là, ça marche.

Le but d'un bureau n'est pas de donner un maximum de préférences pour que l'utilisateur (pardon, le technicien en informatique) trouve l'astuce qui fait marcher le bousin.

> Tu proposes quoi pour résoudre ce problème particulier ?

De corriger le bug là où il est !
Proposer du "ça ne marche pas mais tu peux faire pour que ça marche" n'est pas un objectif à suite. OK, parfois ça rend service. Mais pour une grande majorité d'utilisateur, la conclusion sera que Linux c'est compliqué, ça sucks, etc...
Pour les développeurs, c'est se compliquer la vie a offrir 50 moyens pour faire marcher le bousin. Cette énergie dépensée serait beaucoup plus utile à corriger les bugs au-lieu de trouver des moyens pour les contourner.

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 19:59. (lien). Évalué à 1.

Tout tourne autour de la choucroute.
Pour preuve, tu en parles alors qu'on parle d'informatique.

Que la force de la choucroute soit avec toi.

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 15:33. (lien). Évalué à 1.

> KDE = > multiplateforme (*nix / Windows)
Gstreamer = > multiplateforme (*nix / Windows / Mac OS)

Il y a peut-être d'autre framework aussi portable que Gstreamer, mais je ne les connais pas.

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 15:29. (lien). Évalué à 1.

> quelles que soient les préférences de l'utilisateur final (toi qui préfère GST, un autre qui ne jure que par Xine, ma maman qui est sous Windows, mon papa qui est sous OSX, ...).

C'est vachement important pour 99,9 % des utilisateurs...
Pardon pour 0,1 % des utilisateurs.
L'utilisateur en a rien à foutre de savoir qu'il y a un backend, qu'il a le choix entre plusieurs backends etc...
De plus avec Phonon, quelque soit le backend, c'est la même chose. Donc en quoi ça concerne l'utilisateur ? A part l'emmerder pour rien ?

> comment dans ce cas gérer les ambitions multiplateformes du K.

Les frameworks sont multiplateformes. Effectivement, si KDE veut bichonner les utilisateurs de TO7, Gstreamer ou Xine ou n'importe quoi ne va pas les aider.

> On a tous déjà démonté tes arguments

Ben l'histoire jugera.

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 00:58. (lien). Évalué à 1.

J'ai dit qu'il ne fallait pas faire de wrapper pour permettre aux développeurs de faire simplement des choses simples ?
Où ça ?

> Tu trouves toujours ça aberrant ?

Manifestement, tu n'as pas compris ce que j'ai dit. La réciproque est sûrement vrai.

J'arrête ici, et reprends une phrase de Laurent A. :

De toute façon, tout cela a déjà été discuté dans les ML KDE et les décisions sont prises, alors bon courage aux dév de Phonon !

[ Répondre ]

Posté par clearstream () le 21/08/2006 à 00:16. (lien). Évalué à 3.

> ne se fera pas assimiler par les borgs marketing (l'inclusion de Mono est peut être un symptôme inquiétant)

Des applis mono seront intégrées à Gnome. Pourquoi le refuser s'il n'y a maintenant plus de problème (résolu avec ION) et que ce sont de bonnes applis ?

Tu voudrais aussi supprimer Samba ?

Mono a dans Gnome la même place que Java ou Python. D'ailleurs ces derniers on plus de place car leurs bindings sont plus complets.

La place de Mono dans Gnome c'est des bindings et des applis. C'est tout. Idem pour les autres languages. Par exemple libgnomevfs ne sera jamais écrit en C#. Mono a un binding qui attaque libgnomevfs (comme python et d'autre language).

Jamais pour écrire une applie Gnome, il ne sera nécessaire d'utiliser C#. Toute appli C# pourra être recodé en C ou C++ ou python ou autre si quelqu'un s'en donne la peine. Mais si l'appli existe et quelle rend service, je ne vois pas pourquoi s'en priver.

Puis KDE a aussi un binding en cour de développement pour C#.

Je n'utilise pas Mono. Mais puisque maintenant Mono ne pose pas de problème, je ne vois pas pourquoi il faut continuer cette "chasse aux sorcières".

> comme par hasard, les devs de gstreamer travaillent à intégrer un support des DRM à leur framework (http://blogs.gnome.org/view/uraeus/2005/12/03/0)

C'est effectivement un point sérieux. Je n'arrive pas encore à me forger un avis.
L'article est particuliairement intéressant et les commentaires aussi :

The goal is to have a framework for using various DRM systems with the GStreamer framework without interfering with the way GStreamer currently works.
[...]
The DRM work has included a lot of thinking on our part about the implications and I think its safe to say that we love DRM as little as everyone else. On the other hand we have also seen that a lot of doors get closed on us, GStreamer and GNU/Linux due to lack of DRM support, which means people in those cases go with a Windows based solution instead. Which of course is no win for free software.

On the other side there is the question on how far you should go in trying to accomodate people too and I am sure many in the community feels that any sort of DRM support is going too far.
[...]
The only group out there with the power to shut down DRM are the consumers, they need to revolt at the idea and stop buying music and movies which are using DRM. What we as a technology provider can do is try to move DRM usage in favour of the more userfriendly and fair systems.

Il serait bien que lorsqu'on va lire un contenu DRM, qu'une fenêtre s'ouvre et indique en quoi DRM c'est mal. Après l'utilisateur fait ce qu'il veut. Ceci ne pose aucun problème a réaliser avec le logiciel libre et est pratiquement impossible avec le logiciel propriétaire.
Si ça permet à des utilisateurs de venir de Windows ou de ne pas quitter Linux, il faut l'envisager.

[ Répondre ]

Posté par clearstream () le 20/08/2006 à 23:37. (lien). Évalué à 2.

> Je trouve d'ailleurs vraiment dommage que beaucoup de ces gens là soient du côté de Gnome (à cause de la LGPL de GTK, des grosses boîtes qui le soutiennent et d'Icaza entre autres), car ça ternis considérablement l'attrait que ce desktop

Ca ternis car c'est un troll bidon pour discrédité Gtk/Gnome.

Ce troll on peut aussi le faire pour Qt qui est quasi exclusivement développé par Trolltech.

Le premier est un troll naze, le second aussi.

[ Répondre ]

Posté par clearstream () le 20/08/2006 à 23:31. (lien). Évalué à 2.

> On voit déjà les prémices, avec un gnomiste ici et sur le blog que tu cites qui couinent "ohlala pourquoi ils prennent pas le standard GST par défaut"

Pour le gnomiste, je répète encore un fois que ce que je trouve abhérant, c'est Phonon. Pas que KDE ne choisisse pas Gstreamer.
C'est claire ou il faut que je le dise encore 50 fois ?

> alors que de toute façon ils n'utilisent pas KDE

Certe, mais si KDE prenait Gstreamer, ça fairait avancer le schmilblick au-lieu d'avoir 40 frameworks.

> le KDEiste moyen n'a rien à foutre de GST

Tout à fait.

> vu que Xine marche bien mieux.

Très bien. Que KDE choisisse Xine au-lieu de bouffer du temps inutilement avec Phonon.
Je ne connais pas Xine. Si Xine est mieux que Gstreamer, alors Gnome doit prendre Xine.
Il faut prendre le meilleur et pas faire un truc qui ne sert à rien.

> D'ailleurs, pourquoi Xine ne pourrait pas l'être, le fameux le standard...

Pourquoi pas. Ne connaissant pas Xine, je ne peux juger.

> Il me semble, que, de facto, Xine est bien plus utilisé que GST :þ

???
mplayer est peut-être aussi le plus utilisé. Mais il n'est pas adapté à un bureau "moderne".

> phonon fait tout le sale boulot.

Un tout tout petit bout du sale boulot. Les frameworks multimédia en font beaucoup beaucoup plus.

> Je ne vois pas ce qu'il y a de réellement polémique dans cette démarche

L'un des aspects de la polémique est, qu'alors que la globalement les développeurs de KDE considèrent Gstreamer comme le meilleur framework, ils font un truc tordu comme Phonon sans bonne raison, sauf pour pouvoir dire qu'ils ne sont pas dépendant d'un élément actuellement utilisé par Gnome.

Un autre aspect de la polémique, est que KDE a tout fait dans son coin et en a encore manifestement rien à foutre de mutualiser les efforts sur des acpects techniques d'un bureau qui n'impactent en rien l'utilisateur.

Qu'es-ce que ça change pour l'utilisateur de KDE si son appli KDE préférée utilise Phonon ou Xine ou Gstreamer ou tartantion ? Rien.
Par contre avec Phonon, KDE érige un standard (le standard KDE) qui se limite au plus petit dénominateur commun.

Lorsque Gnome sorte des "standards" (notes bien les guillements) qui peuvent être utilisés par plusieurs bureaux, ils mettent tout sur freedesktop. Ainsi KDE, Xfce, etc peuvent en discuter et participer.

KDE ne fait jamais ça ! Tout ce que fait KDE c'est : "ben tient, on va récupérer HAL, car à développer c'est la galère".

Gstreamer existe depuis longtemps. Puis ceux qui participent à freedeskop (Gnome, xfce, KDE, etc) l'on accèpté dans freedesktop.
Certes, et comme le dit freedesktop http://freedesktop.org/wiki/Standards "These are not really standards".
Les standards ne s'imposent pas d'eux-même.

Phonon a été une surprise à deux niveaux :
1- beaucoup ne comprennent pas l'intérêt du truc.
2- décision d'un coup de le mettre dans KDE 4 et d'en faire le standard de KDE 4. D'autant plus surprenant qu'à l'époque Phonon était à peine, voire pas, fonctionnel. Le tout sans concertation avec Gstreamer ou Xine ou autre pour voir s'il était possible de respecter les objectifs de KDE 4 sans créer un nouveau machin. M'enfin, on le sais, mutualiser les efforts du logiciel libre n'est pas un soucis de KDE. A croire que le libre à 98 % du marché du desktop. Ben non, c'est Windows.

> Evolution pour "remplacer" Outlook-Exchange

C'est le même look. Utilise les deux, et tu verras que ce n'est pas la même chose.
Dans le même registre de troll il y a "Firefox pour remplacer I.E.".

> Novell-Ximian qui pousse XGL au détriment de AIGLX

Ils pensent que c'est la meilleur solution.

> supporté par les codeurs de Xorg

Et surtout supporté par Fedora ne l'oublions pas. M'enfin, la vrai place de AIGLX est Xorg et non le cadre spécifique d'une distribution. Lorsque AIGLX sera en place, il sera sur Xorg (ce qui est pratiquement déjà fait).

> pour "concurrencer Vista"...

Oui. Mais aussi Mac OS.

> Y a quand même une volonté de faire comme (mieux que ?) MS.

Ca pue le troll à plein nez.
Regardes un bureau Gnome, le menu principal est en haut à gauche. Sur Windows c'est en bas. Etc...

> Je trouve que ça serait plus sain, vu la qualité des trucs précités, de simplement chercher à faire de bonnes applis sans s'occuper d'MS

On peut dire la même chose pour KDE. C'est uniquement du troll.

> Evolution est vraiment une horrible usine à gaz

Ca marche, les utilisateurs sont contents. De plus tu ne dois pas connaitre Evolution.

> par contre des clients GTK comme Sylpheed sont vraiment intéressants

Chaqu'un ses goûts.

> XGL est un hack horrible, qui utilise deux serveurs X et casse OpenGL, pourquoi le favoriser à AIGLX ?

???
Qui le favorise. Quelle est cette autorité ?
Novell bosse actuellement sur GLX. Les deux projets GLX et AIGLX bossent assez ensemble. Voilà c'est tout. Quand AIGLX sera au point (ce qui est plus compliqué et long que GLX) je pense que Novell va passer à AIGLX.

> Faire comme/mieux qu'MS c'est se condamner à toujours avoir un métro de retard

Troll.
Tu veux dire que KDE ne va pas utiliser *GLX ?

> tout le monde connait Evolution, mais s'il n'y avait pas régulièrement des news sur Sylpheed ici...

Et ?
Je ne vois pas où tu veux en venir.

> quelle force mystérieuse pousse les Gnomistes à râler systématiquement quand KDE n'utilisent pas leurs machins.

Je répète encore un fois que ce que je trouve abhérant, c'est Phonon. Pas que KDE ne choisisse pas Gstreamer.

> Si ça se trouve, Gnome va se dire que finalement GST c'est pas super finalement

C'est possible.

> et sortir une lib similaire nommée Gazouilli qui fera la même chose

Pourquoi ? Si GST "c'est pas super finalement", se limite au plus petit dénominateur commun des frameworks multimédia ça ne sera pas plus "super finalement".

[ Répondre ]

Posté par clearstream () le 20/08/2006 à 19:50. (lien). Évalué à 2.

> X11 est encapsulé par Qt (tiens, il a plusieurs backends, lui !)

Comme Gstreamer (qui tourne aussi sous Windows et Mac OS) ou Xine ou NMM !
Le but de Phonon, est d'encapsuler des trucs qui encapsulent déjà et qui font la même chose ! Ces "trucs" fournissent des facilités multimédia quelques soit la plateforme (comme Phonon, d'où l'utilité douteuse de Phonon).

Ce que fait Qt (utiliser l'interface native d'un OS), X11 ne le fait pas. Si t'as déjà utilisé une applie X11 sous Windows, tu dois voir où je veux en venir.

> Je continue ?

Non, ton analogie ne tient pas.

> Si ça se retrouve dans Qt ou kdecore, c'est encapsulé.

On peut donc utiliser Gtk+ à la place de Qt comme on pourra utiliser Xine à la pas de NMM avec Phonon ?

Tes comparaisons ne tiennent pas.

[ Répondre ]

Posté par clearstream () le 20/08/2006 à 19:24. (lien). Évalué à 1.

> Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro

C'est le mode par défaut de Gnome.

> et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome.

L'histoire jugera.

> KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer

Je répète encore, ce qui m'énerve dans Phonon, ce n'est pas spécifiquement que KDE ne prenne pas Gstreamer, mais que Phonon fait une abstraction pour plusieurs frameworks et évite de se concentrer sur le vrai problème (c-à-d améliorer le framework multimédia, qu'il soit Gstreamer ou Xine ou autre).

Lis mes commentaires plus haut.

> KDE n'a pas les ressources requises pour participer

Mais KDE a les ressources pour faire Phonon...
De faire du support pour Phonon/Xine, Phonon/Gstreamer, Phonon/NMM, ...
De suivre les modifications d'ABI de Xine, Gstreamer, NMM, etc pour réajuster Phonon.
D'avoir des développeurs qui connaissent l'API de phonon, de Xine, de Gstreamer, de NMM, etc...

C'est ça qui est abhérant dans le choix de Phonon. Tous les explications de KDE ne tiennent pas la route dès qu'on y réfléchi plus de 2 secondes.

> Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..

C'est vrai et ça aide. Indéniablement.

> niveau marketing ils sont bien servis avec Ubuntu dernièrement..

Kde à Kubuntu (mais peut-être pas le support de Canonical).

> Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?

Sois gentil, remplaces "ton framework multimédia" par "son framework multimédia".

C'est du libre, libre à qui veut de participer. C'est claire.
Il n'a jamais été demandé à KDE de participé à Gstreamer s'ils ne veulent pas. Simplement on (plus précisément ici moi) s'interroge sur le choix fait par KDE.
En effet, Phonon est une perte de ressources (ressources KDE selon toi si précieuses, j'en suis d'accord) sans plus-value pour l'utilisateur.

Il y a de bonnes raisons à faire une encapsulation. Par exemple avoir une API triviale pour les actions simples et gérer les changements d'API. Pourquoi pas.
Mais Phonon va le faire pour plusieurs backends.

Et tout ça pour offrir le plus petit dénominateur commun des backends.

Ces ressources précieuses n'apporterons rien au logiciel libre. Sans compter le problème du support : Quand un programme déconne, c'est qui le fautif : L'appli, Phonon, ou l'un des 3 ou 4 backends supportés ?

Faudra aussi un système pour que le périphérique donne ses caractéristiques à Phonon et au backend, etc.
D'ailleur il y a déjà NMM qui "porte" son backend pour Phonon.

KDE a des soucis légitimes de stabilité d'API. Très bien, voyons ça, trouvons une solution. Sur ma bécane j'ai gstreamer 0.8 et 0.10. Ca marche. Sous Gnome il y a esound (compatibilié sur toute la branche 2.x) et gstreamer (un peu de blinding-edge). Si esound tourne et qu'il n'y a pas dmix d'alsa, gstreamer utiliser esound. Le minimum de ressource a été utilisé et on a le maximum de souplesse. Même en pronant une ABI stable, Gnome ne s'est pas enfermé.
On peut trouver des solutions sans sortir ce "machin" de Phonon.

Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore. Forcément Gstreamer s'améliore aussi (via les corrections de ffmpeg, via une veille sur Xine, etc). Et si Xine surpasse Gstreamer, ben Gnome passera à Xine pour le bien de ses utilisateurs et on félicitera KDE pour la pertinance de son choix et Xine (voire KDE) pour la qualité du travaille. Si ça arrive durant la branche Gnome 3.X, il y aura dans Gnome 3.x, Gstreamer (compatibilité pour le bonheur des développeurs), et Xine (pour le bonheur des utilisateurs) comme il y a aujourd'hui esound et Gstreamer.

Effectivement celà est possible aussi avec Phonon. Mais avec Phonon on bouffe des ressources pour rien.

Un des principes de Phonon, est de considérer que ça merde. Les frameworks merdent car ils changent d'API, ils merdent car il faut plusieurs backends pour satisfaire l'utilisateur ou le développeur.
Je préfère que des ressources soient affectées à corriger cette merde, qu'à vivre avec.

[ Répondre ]