Hier est sorti un premier snapshot source de KDE4, ironiquement appelé "Krash". Si vous voulez vous mettre au développement ambitieux de cet environnement de bureau, c'est le moment de se jeter dans le bain !
Au menu :
- passage de kdelibs, kdebase et kdepimlibs sur la version 4 de QT
- utilisation de dbus pour la communication inter-processus en remplacement de dcop
- utilisation de phonon comme framework multimedia
- nouveau système de compilation avec cmake
Plus d'info :
- la news complète : http://dot.kde.org/1155935483/
- la page de KDE 3.80.1 http://kde.org/info/3.80.1.php
Journal Vous voulez krasher ? (KDE4 inside)
19
août
2006
# Ils l'ont fait ...
Posté par Oscar Blumberg . Évalué à 10.
Je suis kde-core-devel (k-c-d pour les intimes) depuis pas mal de temps et l'idée de publier un snapshot de KDE4 était en discussion. Personnellement j'étais contre.
Ce snapshot va forcement attirer une foule d'utilisateurs voulant essayer la version 4 de kde en s'imaginant retrouver les mockups qu'ils ont vu sur le net etc. Ils vont repartir déçus (KDE4 cédlamerde).
Pour l'instant ya *rien* qui marche, ça crash tout le temps et en plus c'est moche. Le seul intérêt de ce snapshot c'est pour les développeurs d'applications KDE qui veulent commencer à porter vers KDE4, car tous les changements sont en profondeur (DBus, CMake, etc ...).
Appeler ça snapshot et mettre une grosse news sur kde.org, c'est courir le gros risque de se taper une masse d'end-user pas content.
[^] # Re: Ils l'ont fait ...
Posté par lezardbreton . Évalué à 10.
[^] # Re: Ils l'ont fait ...
Posté par Pinaraf . Évalué à 7.
Heu
http://software.opensuse.org/download/repositories/KDE:/KDE4(...)
http://www.imbrandon.com/2006/08/18/kde-4-snapshot-released-(...)
Bon, raté.
[^] # Re: Ils l'ont fait ...
Posté par Tom D . Évalué à 6.
Puisque les sites plasma.kde.org, appeal.kde.org, ... ne sont plus mis à jour depuis bientôt un an, l'angoisse du vaporware (vu tous le hype qu'il y a autour de KDE 4, les mockups, ...) pouvait planer. Heureusement que Phonon communique bien.
Tom
[^] # Re: Ils l'ont fait ...
Posté par clearstream . Évalué à -7.
Ben il y a de quoi pour plasma et solid.
Je paris que KDE 4 ne sortira pas en 2006 avec plasma et solid.
[^] # Re: Ils l'ont fait ...
Posté par med . Évalué à 2.
Sinon si tu pouvais arrêter de déverser ton fiel sur KDE ce serait bien aimable de ta part. Merci.
[^] # Re: Ils l'ont fait ...
Posté par clearstream . Évalué à -3.
Super.
Je ne le connaissais pas, mais il a l'air "intéressant" :
http://mail.kde.org/pipermail/panel-devel/2006-May/000905.ht(...)
Suivre le thread.
[^] # Re: Ils l'ont fait ...
Posté par lezardbreton . Évalué à 3.
Tu arrives à quelle conclusion à la suite de ce thread ?
Pour info, une personne débarque sur la mailing-list panel-devel, et demande à avoir où sont les documents préliminaires officiels au développement de KDE4. Les devs KDE lui répondent en coeur que pour l'instant tout est disséminé un peu partout sur le web, et qu'en ce moment, ils sont trop occupés par le développement des couches basses des bibliothèques KDE. Suivent ensuite des explications sur le rôle de la communauté dans le choix des idées retenues.
Ensuite, cette personne pointe vers son wiki où elle a collecté pas mal d'idée et demande ce que les devs en pensent. Comme il ne reçoit pas de réponses rapides, il renvoit un mail pour reprendre des nouvelles. Là on lui répond que personne n'a le temps, mais qu'ils le feront dès que possible.
[^] # Re: Ils l'ont fait ...
Posté par clearstream . Évalué à -1.
[^] # Re: Ils l'ont fait ...
Posté par mickabouille . Évalué à 2.
Si après ça il y en a qui trouvent intelligent d'installer un truc qui s'appelle krash sans être sûrs d'eux...
# Une question que je me posais depuis un moment...
Posté par Moonz . Évalué à 1.
J'ai par contre vachement aimé dcop, Pour faire des trucs du genre (si mes souvenirs sont bons):
dcop konsole-1234 `dcop konsole-1234 newSession` setTitle "blah"
Est-ce toujours possible avec KDE 4 ?
Si oui, je suppose que c'est possible avec DBUS tout court. Comment on fait? (oui, j'ai lu les pages de man... Mais elles sont vraiment pas claires, et la seule vraie doc que j'ai trouvé c'est pour l'API C)
[^] # Re: Une question que je me posais depuis un moment...
Posté par Oscar Blumberg . Évalué à 3.
# Phonon
Posté par clearstream . Évalué à -8.
Je viens de me renseigner sur Phonon. C'est un peu tard, je sais. Mais je n'utilise pas KDE.
Déjà, ce n'est pas un framework, c'est limite une coquille vide.
Ne faisons pas dans la dentelle : Quelle connerie...
C'est du KDE tout krashé^Wcraché. Faut que ça pète plus haut que son cul.
Il y a quelques temps, on nous rabachait que KDE avait au moins 3 ans d'avance sur Gnome, que C++ roxor et C puxor, etc...
Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance.
Puis KDE a tortillé du cul pour savoir s'il prenait ou non Gstreamer car Arts était agonisant.
Quand j'ai vu que KDE "adoptait" Dbus, je me suis dit que KDE était enfin "raisonnable", qu'il prendrait Gstreamer, et que tout va pour le mieux dans le meilleur des mondes. Que la jonction des forces de KDE, Gnome et Gstreamer aboutirait à une solution multimédia qui roxe des ours. Car oui, Gstreamer a besoin des forces de KDE. Pas pour le meilleur de Gnome mais pour le meilleurs des utilisateurs de Gnome, de KDE, d'xfce, etc.
Car en définitive, l'utilisateur final en a rien à foutre de savoir que c'est Gstreamer ou tartanpion qui lit sa video. S'il est utilisateur de KDE, il veut un bureau typé KDE car c'est ce qui lui convient le mieux. Que KDE utilise Gstreamer ou Dbus, ne va en rien changer le typage du bureau.
Finalement, qu'à choisi KDE pour le multimédia ?
Phonon.
Pour bien résumer, on peut dire que ça ne sert à rien.
Je vais ajouter un peu d'eau dans mon vin et dire que c'est une abstraction. Il peut y avoir de bonnes raisons de le faire. Par exemple pour avoir une meilleure intégration dans KDE (utiliser kio, etc).
Mais ces bonnes raisons n'ont pas été les motivations premières de Phonon. Phonon est une abstraction au-dessus DES toolkits multimédia. Une sorte de méta-toolkit ou je ne sais quoi. Ca doit permettre à KDE de faire du multimédia indépendament du toolkit utilisé.
Sur le papier, c'est mignon. Dans la pratique c'est une autre histoire. Faut se limiter au plus petit dénominateur commun. Si ce n'est pas satisfaisant, Phonon dupliquera des fonctionnalités de Gstreamer ou autre. Il y aura aussi les applis qui vont courcircuiter l'API limité de Phonon pour attaquer directement, qui Gsteamer, qui NMM, etc...
Quelles sont les raisons avancées pour Phonon (liste non exhautive) :
* Eviter la mésaventure de Arts. C'est-à-dire ne pas être dépendand de la maintenance d'un toolkit (ou framework). Naze comme raison. C'est aussi arrivé à Gnome avec esd. Arts était limité, il fallait autre chose. Même si Arts était maintenu, son API était à revoir. Ca peut arriver avec Gstreamer et ça peut aussi arriver avec l'API de Phonon. Je ne me trompe en disant que maintenant KDE est dépendant d'un toolkit multimédia (comme avant mais en plus peut-être de plusieurs toolkits si les applis se mettent à taper dans l'API de tel ou tel toolkit car Phonon est limité) ET de Phonon. Si Phonon n'est plus maintenu, qu'es-ce qu'il se passe ? Certe Phonon est un projet pour KDE. Mais Arts aussi était un projet pour KDE ! Brèf, même problème qu'avec Arts.
* Pouvoir choisir entre plusieurs toolkits, et donc choisir le meilleur. L'intention est louable. Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun.
Ce qui est désagréable dans cette raison avancée par KDE, c'est qu'en gros on dirait que KDE ne veut pas s'impliquer dans les toolkits multimédia. L'attitude est condescendante. Type "je veux le meilleur sans rien foutre, car je le vaux bien". Gstreamer est sur http://freedesktop.org/ pour travailler avec les développeurs des bureaux et des applications !
Enfin, une abstraction pour faire une abstraction est de la connerie. Car c'est finalement ce qui va arriver à Phonon. Au final, Phonon sera utiliser dans 99,9 % des cas toujours avec le même toolkit.
Havoc Pennington avait fait un très bon papier sur ça à propos de Cairo. L'argumentaire a été convaincant et il n'y a pas d'abstraction dans gtk/gdk pour attaquer Cairo. L'API Gdk est conservée (pour compatibilité) et toute l'API de Cairo est disponible.
Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt).
* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits.
Si ces raisons sont importantes au yeux des développeurs de KDE, il devrait faire une abstraction par rapport au toolkit graphique. On ne sait jamais, si Qt n'est plus maintenu, s'il y a un autre meilleur toolkit, ou si Qt n'existe pas sur une plate-forme (avant il n'y avait pas de Qt GPL pour Windows !!).
L'attitude de Gnome est toute autre. Gnome se lie fortement à un projet, ça motive les développeurs du projet, ça motive les développeurs Gnome à participer à ce projet. C'est du gagnant-gagnant et ça ne peut marcher que s'il n'y a pas de défiance. Mais pourquoi il y en aurait ? C'est bien meilleur pour le logiciel libre que de faire une abstraction en pariant sur la division puis sur un rapide positionnement opportuniste. Ce choix "politique" de Gnome ne le rend pas dépendant. On est dans le logiciel libre, Gnome peut forcker si nécessaire. Gnome peut toujours aller voir ailleurs (comme ils l'ont fait en passant d'esd à Gstreamer).
Donc pourquoi cette défiance des développeurs de KDE ? Pourquoi ce choix tordu ?
Simplement car Gstreamer est associé à Gnome. C'est mon avis.
A mon sens, c'est la vraie raison. Si par exemple Xine était meilleur que Gstreamer, KDE serait parti avec Xine sans faire ce truc tordu qu'est Phonon. Il ne resterait qu'à dire "bonne chance KDE/Xine et va savoir si un jour Gnome ne va pas rejoindre KDE pour utiliser Xine".
Ce Phonon est grandiosement stupide, car les "vrais" raisons de son existance, l'utilisateur final en a rien à foutre.
Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel.
[^] # Re: Phonon
Posté par Narishma Jahar . Évalué à 6.
http://linuxfr.org/~BlueBird/21613.html
http://linuxfr.org/2006/04/28/20737.html
[^] # Re: Phonon
Posté par clearstream . Évalué à 0.
Tu ne m'en feras pas reproche j'espère ?
Je me suis intéressé à Phonon car dans le journal il y a :
- "utilisation de phonon comme framework multimedia"
Je me suis demandé ce que c'était comme framework n'imaginant pas au début que c'était spécifique à KDE.
J'ai cliqué sur http://dot.kde.org/1155935483/ (de ce journal) puis sur http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.(...) .
Et j'ai vu que ce n'est pas vraiment un framework. Ca commence par :
- "Phonon is the Multimedia API for KDE."
J'ai cru que c'était pour encapsuler soit exlusivement Gstreamer, soit exclusement Xine, etc... mais à ma grande surprise ce n'était pas le cas et j'ai poursuivi la lecture.
[^] # KDE
Posté par Nicolas Schoonbroodt . Évalué à 8.
Encouragerais-tu les dévellopeurs de KDE de laisser tomber KDE et de dévelloper directement Gnome ? Parce que KDE/Gnome, c'est aussi "un pari sur la division"
:-)
[^] # Re: KDE
Posté par clearstream . Évalué à -1.
Si ça arrive, je ne vais pas me plaindre.
Mais que pensera un utilisateur de KDE ?
Un utilisateur de Gnome n'est pas plus important qu'un utilisateur de KDE.
> Parce que KDE/Gnome, c'est aussi "un pari sur la division"
Mouaif...
KDE différent de Gnome répond à un vrai besoin. On ne peut satisfaire l'ensemble des utilisateurs avec un seul bureau.
Apparament il y a deux gros poles (les utilisateurs avec un "profile" Gnome et les utilisateurs avec un "profile" KDE) et quelques niches (xfce, bash-only, etc).
KDE différent de Gnome est aussi justifié par deux "catégories" de développeurs : les pro-object et les pas pro-objet.
Il y a ici une diversité (je ne dis pas division) car il y une diversité d'utilisateur.
Qu'es-ce que ça change pour l'utilisateur que le son soit joué par Xine ou Gstreamer ?
Rien.
Par contre l'utilisateur peut préférer un lecteur avec le typage KDE (plein d'options, etc) à un lecteur avec le typage Gnome (moins d'options, etc).
Idem pour les développeurs.
Que KDE encapsule Xine ou Gstreamer pour avoir une interface objet est normal car il y a différents développeurs. Gnome le fait avec son cortège de binding. Pas pour diviser, mais pour qu'un maximum de développeur se retrouve sur la même plateforme. Ce n'est pas jouer la division, mais tenir compte de la diversité.
[^] # Re: KDE
Posté par ragnar . Évalué à 10.
Hein ? c'est avec quoi que tu te drogues ?
Les développeurs de Gnome sont certainement autant pro-objets que les développeurs de KDE. Ils ont recrée le C++ en C avec la glib/gtk..
C'est une guerre de religion C/C++ qui provient des temps sombres de g++ et du fanatisme du projet GNU..
[^] # Re: KDE
Posté par clearstream . Évalué à 2.
Je voulais dire que Gnome est plus pro-binding que KDE. Ceci est peu compatible avec l'usage du C++. Du moins pour ce qui constitue la plateforme de Gnome. Pour les applications il n'y a pas de problème a utilise le language qu'on veut.
> C'est une guerre de religion C/C++
Je développe (développais plustot) et j'apprécie les deux.
[^] # Les Gnomistes m'emmerdent
Posté par lezardbreton . Évalué à 10.
Aaron Seigo a déja répondu à ces critiques complètement débiles de supporters de leur joujou préféré : http://aseigo.blogspot.com/2006/05/id-like-another-black-eye(...)
1. Aujourd'hui, Gstreamer est une grosse bouse infame. Je n'ai jamais vu un backend aussi mauvais. Peut-être que dans la théorie, c'est beau, en pratique, c'est nul. Compare Amarok avec Gstreamer ou avec Xine, tu verras la différence. Pire, compare totem-gstreamer avec totem-xine, et on peut voir lequel des deux marchent correctement.
2. Les devs de Gstreamer prennent des décisions stupides, dans la tradition GNOME, comme des changements brusques d'API (qui ont provoqué beaucoup d'incompatibilité) sans discussion prélable comme entre la version 0.8 et la 0.10.
3. Il n'est pas question d'utiliser Phonon pour les applis ayant des besoins spécifiques, mais uniquement pour les applications classiques qui ont toutes plus ou moins les mêmes besoins basiques et pour lesquels ça ne sert à rien d'utiliser un backend particulier.
4. On a bon dos de critiquer KDE pour ne pas utiliser des technologies GNOME alors que KDE vient justement de prendre dbus alors que dcop était parfaitement fonctionnel depuis des années et était là avant dbus. Pourquoi GNOME n'a-t-il pas utilisé dcop ? A mon avis, c'était déja une connerie pour KDE d'utiliser dbus.
5. Prendre Phonon, c'est au contraire laisser la porte ouverte à Gstreamer dans un but d'ouverture, sinon xine aurait évidemment été la meilleure solution.
6. Comme d'habitude, les développeurs GNOME ont tendance à ne penser à l'utilisation des bibliothèques qu'ils utilisent uniquement dans un contexte GNOME. Par exemple GTK+ qui va encore grossir pour recueillir les bibliothèques GNOME (que personne n'a sohaité maintenir malgré leur utilisation dans de nombreuses applications) au sein du projet Ridley. Merci pour les devs XFCE !
Bref, foutez la paix au kdeistes s'il vous plait.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à -5.
De toi :> Pourquoi GNOME n'a-t-il pas utilisé dcop ?
Fouilles les mailings de KDE pour avoir la réponse. Probablement pour les mêmes raisons qui ont poussé KDE a abandonner Dcop.
> sinon xine aurait évidemment été la meilleure solution.
Même si je suis un supporter de Gnome, je trouve que KDE aurait mieux fait de ne prendre que Xine, si pour eux c'est le meilleur framework, que de faire ce truc tordu.
> Comme d'habitude, les développeurs GNOME ont tendance à ne penser à l'utilisation des bibliothèques qu'ils utilisent uniquement dans un contexte GNOME.
T'as raison, je vais ouvrir un rapport de bug pour me plaindre que Gstreamer ne dépend que de glib (comme Arts :-)) et devrait dépendre aussi de gtk & libgnome.
D'ailleur il faudrait fusionner glib avec gtk.
> Par exemple GTK+ qui va encore grossir pour recueillir les bibliothèques GNOME
C'est une librairie (en fait plusieurs : pango, glib, cairo, gdk, etc). Si la fontion n'est pas utilisée, elle n'est pas chargée en mémoire. De plus beaucoup de fonctionnalité sont en plugin.
Pour ton info, les sources de gtk sont plus petit que les sources de la libc.
> que personne n'a sohaité maintenir malgré leur utilisation dans de nombreuses applications
Comme Arts... Balayes devant ta porte.
> Merci pour les devs XFCE !
En quoi ça les déranges ?
En rien.
Pour l'utilisateur final, c'est un peu plus de place disque et un peu moins de dépendance.
Enfin, ne donnes pas de leçon ici. Les sources compactés de Qt font 35 Mo (!) et ceux de gtk "seulement" 12 Mo. L'ensemble glib/gtk/pango/cairo/libgnome fait 16 Mo.
Ajoutes encore libxml2, etc et t'es toujours loin du monolithe Qt.
Balayes devant ta porte.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Oscar Blumberg . Évalué à 10.
Sachant que l'API multimédia sera figée au début de KDE4, et que les backends sont trop instables, API/ABI parlant, le plus logique c'est pas de faire une couche d'abstraction ?
Ça apporte aussi l'avantage d'exposer a l'application une API consistante avec le reste des kdelibs.
Rien que ça, ça me parait être une très bonne raison de coder Phonon.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Laurent A. . Évalué à 2.
- pour trouver un socle commun à des bibliothèques très différentes, il faut aller chercher loin dans l'abstraction. Cela amène facilement à un code complexe, difficile à débugguer et « lent » ;
- il faut maintenir la liaison avec plusieurs bibliothèques, donc sortir régulièrement de nouvelles versions (développement soutenu) alors qu'il faut peut-être casser de grandes parties du code dans un même temps ! Les risques de bugs sont donc bien présents ;
- enfin le refrain est malheureusement assez connu : on part d'une petite bibliothèque, puis sous la pression d'autres développeurs, on commence à ajouter des fonctionnalités... et on se retrouve avec un joli monstre.
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 !
[^] # Re: Les Gnomistes m'emmerdent
Posté par un_brice (site web personnel) . Évalué à 10.
Les bibliothèques envisagée ont toutes en commun la capacité de satisfaire l'utilisateur ayant des besoins basiques (une playlist, des fondus, et un peu d'effet sur la vidéo... à priori ça inclue même des applications comme Juk ou Codeine).
La différence est donc que l'API phonon est construite, non pas dans l'optique d'une "N-ième API qui roske", mais dans une API qui permet de faire en 2 lignes de code ce que tout le monde veut faire (essentuellement les taches susnommées). Ce que tout le monde ferais en peut être 2 à 10 lignes avec une autre API.
Les backends ne rajoutent aucun code qui ne serait pas de toutes manière nécessaire à l'utilisation de la bibliothèque et présent dans une dizaine d'applications. Phonon n'a pas fait l'erreur de la "génericité abusive".
Si tu veut le voir par toi même, goto là bas : http://developer.kde.org/documentation/library/cvs-api/kdeli(...)
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à -2.
> Abstraction faites de toutes les considérations techniques (gstreamer est une bouse etc ...)
Très constructif, passons.
> Sachant que l'API multimédia sera figée au début de KDE4, et que les backends sont trop instables, API/ABI parlant, le plus logique c'est pas de faire une couche d'abstraction ?
Oui, c'est logique. Je n'ai pas reproché à KDE de faire une couche d'abstraction (relis mes commentaires).
J'ai critiqué le fait que KDE fait une couche qui n'aura que le plus petit dénominateur commun (et ça n'apporte rien au libre). Et si ce n'est pas le cas, ça sera limite ingérable (d'ailleurs, ça commence). Tu parles de stabilité d'API/ABI, mais ce qui va arriver c'est que dans KDE il y aura des applis qui utilisent phonon, d'autres qui utilisent Gstreamer, d'autres Xine, d'autres ...
C'est se tirer une balle dans le pied. Si phonon est beaucoup utilisée, les programmes n'offriront que peu de fonctionnalités. Ce n'est pas avec ça qu'on va concurrencer Windows Media Player surtout si rien ne bouge pour les 3 ans à venir.
J'ai aussi critiqué l'attitude de KDE. Un lien donné par lezardbreton le confirme :
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye(...)
En gros, il faut que ça leur tombe tout cuit dans le bec sinon c'est de la merde. Pas de compromis. Franchement, pour qui il se prend ?
Oui les développeurs de Gstreamer veulent avoir KDE à leurs côtés. C'est important. Mais si le prix est "vous êtes à ma botte et vous fermez votre gueule", il est claire que Gstreamer va envoyer KDE aller ce faire foutre un peu plus loin.
Ce n'est pas comme ça que marche le logiciel libre. Ce n'est pas avec ce mépris que Gstreamer sera à l'écoute des demandes de KDE. Pour qu'un projet vous écoute, il faut y participer.
Gnome bosse avec Gstreamer. Il y a des compromis qui sont faits. C'est gagnant-gagnant.
Si KDE continue dans cette esprit, KDE va se casser la gueule. Rien qu'ici on voit des tonnes de "Gstreamer c'est une bouse", "les développeurs de Gnome sont stupides", etc...
J'ai critiqué KDE sur deux points seulement :
- le choix de faire phonon
- l'attitude de KDE
Si je pensais que KDE était de la bouse ou que ses développeurs étaient stupides :
1- J'en aurai strictement rien à foutre que KDE prennent Gstreamer ou non
2- Je ne dirais pas que KDE a sa place à côté de Gnome et répond à un vrai besoin ("KDE différent de Gnome répond à un vrai besoin")
M'enfin, c'est comme ça avec les fan de KDE, il faut toujours qu'ils soient injurieux.
Pour finir sur le "Les Gnomistes m'emmerdent". J'en ai généralement rien à foutre de KDE. Je ne l'utilise pas comme je l'ai dit. Donc, j'ai aucune raison de dire que c'est de la bouse ou bloat ou autres trucs stupides dans ce goût.
Par contre, je commente ce choix de KDE car il est préjudiciable à Gstreamer. Si KDE prenait Gstreamer, ça serait cool pour les utilisateurs de Gnome et de KDE car Gstreamer serait plus supporté. C'est pourrait créer enfin un standard dans Linux où les développeur pourraient se concentrer au-lieux d'avoir 50 frameworks qui sucks tous autant que les autres. Encore un fois, ça serait bon pour KDE et Gnome. C'est un domaine qui n'impacte pas l'utilisateur. Il n'est pas demandé à KDE de devenir à Gnome-like d'un point de vu utilisateur, mais seulement de mutualiser les efforts pour le bien de tous. Mais ça va au-delà de Gstreamer. Je préfère que KDE dépense du temps sur Xine ou autre que sur phonon. Si Xine roxe des ours avec le support de KDE, alors Gnome pourra le reprendre. Les deux bureaux peuvent y gagner. Avec phonon, je ne crois pas que KDE y gagne (et personnellement c'est le cadet de mes soucis), mais en plus Phonon semble un truc pour ne pas bosser sur le vrai problème. C'est-à-dire bosser sur le framework afin d'en avoir un qui roxe. Il est claire que le chois de KDE n'apportera rien sur ce point et c'est dommage pour le libre. Certains vont dire que Gnome veut imposer Gstreamer à KDE. C'est naze. Gstreamer est sur freedesktop depuis un moment. KDE n'a rien proposé.
PS : aseigo n'est pas représentatif des développeurs de KDE, les développeurs de KDE sont milles fois plus respecteux que les fans de KDE.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Oscar Blumberg . Évalué à 6.
Le "gstreamer est une bouse" c'est une citation et ne reflète pas du tout mon opinion, j'ai jamais vu le code de gstreamer, jamais vu la gueule de l'API, j'en sais rien, je me tais.
Ben, c'est dit partout, phonon *doit* être simple. Il devra niveler par le bas les fonctionnalitées des backends, ok. Les applications ayant besoin d'une manipulation fine utiliseront un framework particulier, pourquoi pas gstreamer ? En tout cas c'est comme ça que j'ai compris le schmilblik.
Je vois pas en quoi son attitude est blessante pour les développeurs gst : il faut une solution qui se conforme au points qu'il a écrit, ça veut pas dire que kde contribuera pas a gstreamer.
A mon avis (pures spéculations), les développeurs des différents backends coderont sur le moteur multimédia qu'ils ont wrappé (correction de bugs, etc).
Pure généralisation. Un troll est un troll, tu peux pas dire que les trolleurs KDE "ilstrollentplus" et qu'en plus "ilssontmoinsrespectueux" que les autres ...
En plus, comme je l'ai dit plus haut, je vois pas de problèmes avec ce qu'a dit Aaron.
En parlant de troll, sans vouloir sombrer dedans, faire un projet qui a pour but d'être commun a plusieurs desktop (je parle de gstreamer la ;)) et l'écrire avec la glib, c'est comme si kde sortait un fw audio avec QtCore, tout le monde gueulerait.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 1.
Faut pas charier. QtCore demande C++ et n'est probablement pas wrappable vers un autre language.
De plus glib a été sorti de Gtk justement pour être utilisé dans un contexte hors desktop. Glib est petit et n'a rien à voir avec Qt qui fait figure de monstre à côté.
Glib est déjà utilisé par de nombreuses applis qui n'ont rien à voir avec le desktop.
Pour ton info, Glib était utilisé par Arts. Donc Gstreamer ne fait pas "pire".
Puis je ne vois pas pourquoi il faudrait réinventer la roue car certains on une sensibilité mal placée.
La brique la plus basse de Gnome, c'est Glib. Pour KDE c'est Qt. S'il vous plait, arrêtez ce reproche ridicule.
Enfin Glib est LGPL et QT GPL.
Gnome fait beaucoup pour que ces librairies soient reprises (d'où un nombre important de librairies (pango, glib, cairo, etc)). KDE et Qt presque rien.
Si à chaque fois qu'on voulait une liste chainée, etc, des petites fonctionnalités qu'on trouve dans glib il fallait tout recoder, ça serait vite très lourd, une grande source de bug et ça boufferait de la place mémoire (code non partagé).
KDE utilise bien libxml2 a l'origine fait pour Gnome. Où est le problème ?
Quel pourrait être l'intérêt pour KDE de tout recoder ?
Gnome ne dit pas à KDE, "recodé ceci afin qu'on l'utilise".
[^] # Re: Les Gnomistes m'emmerdent
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Ça doit être pour ça que les bindings KDE sont limités aux seuls langages suivants :
- Python
- Ruby
- Perl
- Java
- Javascript
- C#
Sans oublier la librairie SMOKE, si tu veux ajouter un binding vers un autre langage : http://developer.kde.org/language-bindings/smoke/
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à -1.
Une conspiration sûrement...
Juste pour exemple, le binding de java et C# sont quasiment complets pour Gnome, pour ne pas dire parfait.
C'est à dire que ces languages sont utilisés pour faire de *vrais* programmes utilisés par des *vrais* utilisateurs au *quotidien*.
Rien à voir avec les bindings de KDE.
[^] # Re: Les Gnomistes m'emmerdent
Posté par lezardbreton . Évalué à 10.
Peut-être y-a-t-il si peu d'applications KDE utilisant des bindings uniquement parce que :
- les devs KDE sont à l'aise avec le C++ parce que les libs sont bien faites et la documentation complète
- ne comprennent pas l'intérêt des bindings par rapport au C++
- ne veulent pas rajouter 100 machines virtuelles différentes pour faire tourner une appli basique parce qu'ils se préoccupent de la consommation mémoire de leurs utilisateurs
- trouvent qu'il est très intelligent de tout faire en C++, car justement tous les devs KDE auront une base commune de langage
- trouvent que les langages autres ne sont pas aussi performants
Bref, tu peux trouver des dizaines de raisons pour ne pas utiliser les bindings autre que "les bindings ne sont pas complets". En l'occurence, tu apprendras par exemple que PyQT et PyKDE sont complets et générés automatiquement et je t'invite à lire l'interview de leur auteur : http://dot.kde.org/1155075248/
[^] # Re: Les Gnomistes m'emmerdent
Posté par Larry Cow . Évalué à 10.
Comme par un fait exprès, Qt a justement été "explosé" en modules (dont QtCore et QtGui) pour des raisons similaires à la modularisation de GTK+.
Si à chaque fois qu'on voulait une liste chainée, etc, des petites fonctionnalités qu'on trouve dans glib il fallait tout recoder, ça serait vite très lourd, une grande source de bug et ça boufferait de la place mémoire (code non partagé).
Rassures-toi, il y a aussi des containers sympas en Qt (dans QtCore, justement).
Reste que, oui, ces projets ont leur libs "utilitaires" fétiches, et que tu feras aussi peu utiliser les containers Qt à un dev GTK que l'inverse. Ce n'est pas spécialement fait pour, et ce serait suboptimal. Un peu comme utiliser une librairie de containers conçue en C dans un programme C++ (même s'il y a plus sympa que C++ comme langage, je le reconnais aisément).
Il ne faut pas perdre de vue non plus que Gnome et GTK+ sont deux entités distinctes. Gnome est un bureau basé sur ce dernier, et y contribuant beaucoup, c'est entendu. Mais il est loin d'être le seul (cf. ROX, XFCE, GPE, ...). Ca oeuvre à expliquer pourquoi dans le monde GTK les librairies sont beaucoup moins "liées" entre elles (si ce n'est le lien à Glib) que dans le monde Qt.
Quand à la libxml2, elle est très largement utilisée, bien au delà du desktop, ou de linux. Ce n'est donc pas le meilleur exemple de récupération de projet Gnome par KDE.
Gnome ne dit pas à KDE, "recodé ceci afin qu'on l'utilise".
Quitte à marcher dans le troll avec toi, faudrait voir à pas oublier que les développeurs de Gnome ont justement choisi de créer ce dernier plutôt que de contribuer au jeune KDE de l'époque.
:]
[^] # Re: Les Gnomistes m'emmerdent
Posté par imalip . Évalué à -3.
Tiens, cadeau :
http://blogs.qtdeveloper.net/archives/2006/02/24/qt-and-glib(...)
Avec la phrase finale : "We both agree: the ideal would be for all applications on the X11 desktop to use the same event dispatching mechanism. Here are Trolltech, we think the Glib main loop should be that mechanismm…"
Attends, je te rejoins dans le troll... QT etait libre a l'epoque ?
[^] # Re: Les Gnomistes m'emmerdent
Posté par Gof (site web personnel) . Évalué à 3.
Un gars de chez Trolltech dis juste que le mécanisme de boucle principale de Glib est pas mal.
Et quand bien même ils intégrerais ce mécanisme dans Qt, ça restera en C++/Qt , et ne signifie aucune dépendance avec la GLib, et encore moins que le développeur d'un soft en Qt devra utiliser l'API en C de la GLib.
Quand à l'intégration de la boucle principale de Qt dans celle de la GLib et inversément, ça a juste pour but de *permettre* à une appli d'utiliser à la fois des lib Qt et des lib basé sur la GLib. En aucun cas une appli purement Qt ne sera intégrée dans la boucle GLib.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 1.
Il y avait de bonnes raisons à ça.
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . Évalué à 10.
On s'en fout complètement de Windows Media Player®. En plus il me semble qu'on a largement les même fonctionnalités (sauf le bouton "Acheter" et les DRM, un manque à combler d'urgence je suppose) depuis MPlayer (MPlayer vaincra !).
Je ne comprend pas pourquoi les gnomistes sont toujours à crier à la "standardisation" et à vouloir concurrencer Windows (C#, ta référence à WMP...). En plus, la standardisation, c'est toujours dans le sens "faites comme Gnome", comme par hasard.
Pourquoi les devs KDE n'auraient pas le droit de faire leurs designs comme ils veulent sans devoir préserver l'égo des codeurs Gnomistes ? Ça ne t'ai pas venu à l'idée qu'ils n'en avaient peut être rien à foutre de GST ?
Des gars créent une API s'autoproclamant "standard pour le multimédia sous Unix" et il faudraient automatiquement les suivre car il y a le mot "standard" dedans ? Faudrait peut être qu'ils fassent leurs preuves aussi, et pour l'instant c'est loin d'être le cas.
Avec ton raisonnement, faudrait recoder KDE en GTK (duplication d'effort ! la GPL de QT c'est pas corporate friendly !* un autre toolkit, c'est préjudiciable à GTK !)
* et tout le monde sait que si Linux n'est pas corporate-friendly, il va 'se casser la gueule'®.
Ah ça oui, dès qu'on ne suit pas les standardiseurs autoproclamés, on court droit dans le mur ;)
Au lieu de chercher à unifier GNU/Linux pour le corporate desktop et devenir une alternative crédible au grand méchant Microsoft®, les gnomistes feraient mieux de simplement chercher à coder le meilleur desktop possible.
Je préfère l'ambiance "on code ce qu'on aime comme il nous plait et si on détruit MS ce sera un effet secondaire tout à fait involontaire" prônée par Linus et suivie par les devs KDE que l'élitisme hautain des Gnomistes qui passent leur temps à tout vouloir standardiser* (qui bien souvent, comme la LSB, ne serviraient qu'aux devs d'applications propriétaires) pour "concurrencer Windows".
* et couiner ensuite que personne ne suit leurs standards qu'ils sont seuls à utiliser
Bref, j'ai marché dedans, mais ça fait du bien :D
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à -2.
J'ai dit qu'ils n'avaient pas le droit ?
Arrêtes le crack.
Il ont le droit de faire comme ils veulent et j'ai le droit de dire que c'est de la merde ou génial.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Laurent A. . Évalué à 2.
Ce type de commentaire est, pour moi, du même niveau que ceux qui prétendent que tous les linuxiens sont élististes...
Quant aux standards, il n'y a jusqu'à présent que deux exemples qui ont été donnés : DBus et GStreamer, c'est léger pour un argumentaire à charge.
En ce qui concerne DBus, je ne me souviens pas comment est né exactement ce projet et pourquoi les dév de KDE en sont arrivés à l'adopter. Donc je ne vais pas le commenter.
Pour ce qui est de GStreamer, sur quels GNOMiste t'appuies-tu ? Personnellement, je me souviens surtout des pleurs de Christian Schaller ( http://blogs.gnome.org/portal/uraeus ) et de ses commentaires « virils » à propos de Phonon et de la non-adoption directe de GStreamer dans KDE. Mais ce n'est pas très étonnant, le monsieur travaille pour le contributeur principal à Gstreamer, à savoir la société Fluendo...
D'ailleurs GNOME a pas mal d'employés dans ses développeurs. Ils viennent de Red-Hat, Novell, Fluendo ou même Nokia. Ils faut donc tenir compte des différents intérêts qu'il y a dans GNOME. Je suppose qu'il y en a aussi dans KDE d'ailleurs, cependant je n'en suis suffisament pas le développement pour le remarquer.
Au fait, es-tu sûr que c'est de l'élitisme de vouloir tout standardiser ? Pour moi, il est beaucoup plus difficile de devoir savoir maîtriser plusieurs bibliothèques qui font les mêmes choses mais de manières totalement différentes. L'élitisme se crée déjà là.
Je trouve plutôt que l'idiotie serait de prétendre vouloir tout unifier.
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . Évalué à 10.
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" alors que de toute façon ils n'utilisent pas KDE, et que le KDEiste moyen n'a rien à foutre de GST vu que Xine marche bien mieux.
D'ailleurs, pourquoi Xine ne pourrait pas l'être, le fameux le standard... Il me semble, que, de facto, Xine est bien plus utilisé que GST :þ
'fin tout ça c'est pas génant, ça ne fait que générer du bruit de fond sur la toile.
Phonon c'est une API multimédia basique, elle a été conçue *généreusement* de façon a proposer à l'utilisateur différents back-ends. Si le besoin se faisait sentir, ils pourraient très bien remplacer les calls vers les back-ends par une solution maison en dur, ça marcherait pareil. Ça permet simplement aux devs d'applis KDE qui ont besoin de jouer un son, par exemple, de le faire facilement sans chercher une lib adéquate et se farcir sa doc, phonon fait tout le sale boulot.
Je ne vois pas ce qu'il y a de réellement polémique dans cette démarche, m'enfin un petit troll de temps en temps ça ne se refuse pas :)
Ah, si tu trouves que les codeurs KDE sont des l33t pour réussir à faire phonon et l'interfacer avec différent backends, c'est sympa et fairplay de ta part, et je suis tout à fait de ton avis ! :)
Pour la fascination des Gnomistes pour Windows, c'est du pur troll de ma part :) M'enfin, quand on voit les décisions de Miguel de Icaza et Ximian avec Mono dans Gnome (duplication d'effort d'ailleurs, y a déjà .GNU), Evolution pour "remplacer" Outlook-Exchange, Novell-Ximian qui pousse XGL au détriment de AIGLX (supporté par les codeurs de Xorg, lui) pour "concurrencer Vista"... Y a quand même une volonté de faire comme (mieux que ?) MS.
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: Evolution est vraiment une horrible usine à gaz, par contre des clients GTK comme Sylpheed sont vraiment intéressants; XGL est un hack horrible, qui utilise deux serveurs X et casse OpenGL, pourquoi le favoriser à AIGLX ? (d'ailleurs le patch glucose qui s'appuie sur AIGLX a l'air très intéressant en attendant Xegl).
Faire comme/mieux qu'MS c'est se condamner à toujours avoir un métro de retard, et ça peut même étouffer les bons projets originaux qui n'ont pas les même moyens marketing que Novell/Ximian (tout le monde connait Evolution, mais s'il n'y avait pas régulièrement des news sur Sylpheed ici...).
En bref, les KDEistes ne vont jamais couiner que Gnome n'utilise pas dcop ou les kparts, je me donc demande quelle force mystérieuse pousse les Gnomistes à râler systématiquement quand KDE n'utilisent pas leurs machins. Si ça se trouve, Gnome va se dire que finalement GST c'est pas super finalement, et sortir une lib similaire nommée Gazouilli qui fera la même chose, mais là ce sera présenté comme visionnaire :)
[^] # Re: Les Gnomistes m'emmerdent
Posté par Laurent A. . Évalué à 3.
C'est juste du troll ça...
C'est bien ce que disais juste avant, à la lumière d'un comportement (ici deux), tu fais des généralités. Le GNOMiste a été excité par un lézard breton qui a bien pris le soleil [comment ça se fait ça en Bretagne ?!], et de l'autre côté il s'agit d'un dév qui a tout intérêt à voir GST largement utilisé puisque c'est son gagne pain. À voir ses posts, je ne serais d'ailleurs pas étonné qu'il ne soit pas un simple dév à Fluendo...
Quant à « pourquoi pas Xine », je n'en sais foutre rien ! GST est très modulaire, peut-être est-ce pour ça qu'il est préféré à Xine ? Des histoires de licence ? Je ne sais pas.
Mais je n'ai rien dit contre Phonon... Je leur souhaite juste bon courage pour tenir quelque chose au-dessus de plusieurs bibliothèques très différentes, c'est tout.
Icaza n'a de force sur GNOME que chez Novell. Pour Xgl ou AIGLX, il n'y pas que MS, il y a Apple aussi. C'est surtout la problèmatique de faire un bureau avec des effets sympas. D'ailleurs EXA vient bien d'un Dév de KDE il me semble, le même que Glucose d'ailleurs.
Il y a Tiny-mail aussi peut-être. Evolution est sur une voie d'amaigrissement. M'enfin je ne vois pas pourquoi ce seul programme devrait servir à faire tomber tout GNOME dans le catastrophisme.
Xgl ne fait par exemple pas partie de GNOME. Le Window Manager est Metacity et non pas Compiz. Il me semble -- je parle bien au conditionnel -- que Metacity s'appuie sur AIGLX, pas sur Xgl.
Pour clore cette petite partie, je suis comme toi je pense, j'aimerais que Xegl soit prêt et utilisé. Je n'aime pas Xgl avec son idée de faire tourner deux serveurs... Mais visiblement l'effort pour arriver à Xegl est important et des changements incrémentaux sont obligatoires.
Si tu as des articles à propos de Glucose, je suis preneur :)
Héhé, tu n'as pas du tout tort. Personnellement, le prosélitysme d'Icaza à propos de Mono me gonfle bien. Toujours d'un point de vue personnel, je préfère suivre l'évolution discrète de Classpath à celle ronflante de Mono...
D'ailleurs je vais peut-être me trouver confronté à cette connerie de puissance marketing. Je développe un peu sur Tracker en ce moment, c'est un Beagle-like, mais en C (et indépendant de tout bureau même s'il utilise Glib et DBus...). Lorsqu'il va être suffisament mûr pour affronter Novell de face, ça risque d'être amusant...
Vil trolleur !
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . Évalué à 8.
C'est vraiment un excellent exemple, je suis tombé complètement par hasard sur Tracker en parcourant un troll Mono sur OSnews... :/
Beagle est une abomination à installer à partir des tarball, j'ai du prendre des binaires précompilés sur linuxpackages pour l'installer sur ma machine de test. C'est très lourd (~100 megs de RAM occupés rien que pour lui), lent à indexer et chercher. Pourtant, quelle popularité sur google... SPOTLIGHT KILLER ! mouarf.
Si on recherche Meta Tracker sur google, on ne trouve que la page du projet, et en cherchant mieux deux trois messages sur des blogs ou des ML (enfin, le nom assez générique n'aide pas non plus ;) ).
Tracker s'installe à la main très facilement à condition d'avoir dbus, trackerd consomme très peu de mémoire, et l'ensemble est considérablement plus nerveux que Beagle :) ('fin je n'ai pu joué qu'avec tracker-search et tracker-query).
J'espère que la sphère Linux n'est pas encore suffisamment intoxiquée par le marketing et la corporate-friendly attitude, et que tracker pourra s'imposer naturellement par sa supériorité technologique. Déjà, j'ai vu qu'il pouvait être intégré à Nautilus (pas testé par contre, pas de Gnome sur Slack de base :) ), c'est peut être le pied dans la porte.
Bref, tout ça pour dire que le front des "linuxiens" qui crie à la standardisation des packages manager, veulent un /etc unifié style base de registre, ABI stable dans le noyau sinon le driver nvidia est cassé, LSB sinon installer Oracle c'est compliqué, LGPL c'est mieux car on peut faire du proprio, "linux va mourir s'il gère X" où X est un buzzword à la mode, Mono C# c'est l'avenir, bref, un Windows® légalement gratuit... il me donne très très vite envie de troller :]
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 - par ailleurs encore tout à fait respectable - pourrait avoir sur certains, dont moi (même si la politique de 'less is more' m'agace :þ).
J'espère simplement que GNOME, né pour contrer un KDE alors non-libre, ne se fera pas assimiler par les borgs marketing (l'inclusion de Mono est peut être un symptôme inquiétant), et surtout que KDE ne sera pas contaminé ! (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 )... sayvrai, si linusque gère pas les déairem, yva creuver !!!!1!!)
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 2.
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.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 3.
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 :
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.
[^] # Re: Les Gnomistes m'emmerdent
Posté par lezardbreton . Évalué à 6.
J'ai encore des coups de soleil, fallait pas m'énerver :)
Sinon, je trouve dommage que des gens comme toi du côté de chez GNOME ne s'exprime pas plus. On retrouve de plus en plus de pollueurs comme clearstream qui pousse un marketing ridicule et ternisse l'image de GNOME. Si un jour tu pouvais nous expliquer comment marche tracker, ça m'intéresse énormément.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 2.
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".
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . Évalué à 10.
Actuellement, le dev en question doit d'abord choisir un framework pas forcément intégré à kde et en assimiler la doc, ensuite coder en espérant que tous les utilisateurs disposent de la lib.
L'avantage de phonon, c'est que là le dev n'a pas à se poser de question, c'est intégré à kde. Donc il utilise gentiment l'api prévue (hint: l'avantage sur utiliser xine en dur c'est l'api plus simple et l'absence de dépendance dure), et c'est kde qui se débrouille avec les moyens du bord pour que le son sorte par les enceintes, avec probablement peu de pertes de performance vu que sur le fond c'est juste un wrapper. Réutilisation (en utilisant un backend tout fait), et mutualisation du code (via le wrapper, au lieu de forcer les gens à mettre de grosses boilerplates pour utiliser une api plus complexe), c'est exactement ce que tu prône non ?
Si phonon n'utilisait pas de backends mais se débrouillait pour sortir le son tout seul tu n'aurais probablement rien contre :)
Le fait que phonon se réduise au plus petit dénominateur commun n'est pas génant vu son objectif (faire des trucs multimédia pouet pouet *simples* facilement et de manière portable). Évidemment qu'une appli de MAO n'utilisera pas phonon, mais une interface plus élaborée genre jack.
Tu trouves toujours ça aberrant ?
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 1.
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. :
[^] # Re: Les Gnomistes m'emmerdent
Posté par Olivier Serve (site web personnel) . Évalué à 7.
Phonon est exactement ça : un wrapper pour faire des choses simples.
Genre le jour où je voudrai ajouter un bigornophone à koinkoin, j'ai pas besoin de me taper l'API de GST ou Xine.
Je code pour Phonon et le backend utilisé dépend des préférences de l'utilisateur. Je n'ai aucune dépendance à un backend particulier, et je n'oblige personne à installer un backend qu'il ne veut - ou ne peut - utiliser.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Larry Cow . Évalué à 10.
Rien à voir avec un standard. Avec Phonon, KDE développe une bibliothèque pour KDE et les développeurs d'applications KDE. Il n'a jamais été question d'étendre l'usage de Phonon au reste du monde logiciel.
Phonon, c'est un peu de sucre pour les développeurs d'applications multimédia sous KDE. C'est pour leur permettre d'avoir du son dans leurs applications, 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, ...).
Bien évidemment, le mec qui veut fait une application audio avancée (Rosegarden, LMMS, etc.), il y a fort à parier que Phonon lui soit inutile. Et c'est relativement normal.
Mais ça fait des années que KDE se traîne aRTs, qui n'a jamais trop su à quel genre d'applications il était destiné, et qui du coup était (selon les cas) peu utilisé, mal utilisé ou (dans mon cas) complètement désactivé.
Si tu penses que KDE se porterait mieux en ne proposant aucune API audio, expliques-nous pourquoi (sauf ta sempiternelle chanson sur la perte de temps, ils sont en train de remettre un DE à plat, il ne sont pas à un framework près).
Si tu penses que KDE se porterait mieux avec une API audio liée de manière forte à une architecture sous-jacente (GST, Xine, Portaudio, que-sais-je...), expliques-nous pourquoi, et comment dans ce cas gérer les ambitions multiplateformes du K.
Maintenant, si c'est juste pour expliquer que Phonon ça sert à rien, avec un argumentaire en bordure de Trollurie orientale, c'est pas la peine. On a tous déjà démonté tes arguments (enfin les "vrais" arguments, car il y en a) plusieurs fois.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Larry Cow . Évalué à 5.
Pour moi, l'interopérabilité est primordiale, et pas seulement dans la direction habituellement réclamée à cor et à cri par les libristes : ce doit être un processus à double sens.
[^] # Re: Les Gnomistes m'emmerdent
Posté par ragnar . Évalué à 2.
http://wiki.x.org/wiki/IntelGraphicsDriver
"
https://bugs.freedesktop.org/show_bug.cgi?id=643
For all those who don't know. There is a new 'modesetting' branch for native
modesetting without the Video BIOS."
[^] # Re: Les Gnomistes m'emmerdent
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Mais c'est quoi le rapport avec la choucroute ?
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 1.
Pour preuve, tu en parles alors qu'on parle d'informatique.
Que la force de la choucroute soit avec toi.
[^] # Re: Les Gnomistes m'emmerdent
Posté par lasher . Évalué à 3.
ca ca me gene, perso je suis persuade avec moi meme (c'est deja pas mal) que porter les applis linux sous windows c'est se tirer une balle dans le pied.
Oui, sauf que multi-plateforme ne signifie pas nécessairement linux->windows. Ca peut très bien être Linux -> unix_libre_quelconque, ou bien Linux -> OS_libre_quelconque (ReactOS ? :p ou plus sérieusement Minix 3, ou ...).
Sinon, sur le côté "porter des applications sur windows", je ne peux qu'être en désaccord avec toi : je suis quant à moi persuadé que forcer le passage à "tout libre ou rien", c'est perdre un certain niveau de "porosité". C'est sûr, si toutes les applications qui nous intéressent se trouvent en libre sur windows, pourquoi changer ? Justement, la réponse à ceci est que si vraiment *toutes* les applications libres qui me servent sur windows sont des portages depuis Linux, j'aurai moins de réserves pour déménager dessus.
Le problème actuellement, c'est qu'un tas d'applications (propriétaires ou pas) n'existent que sous windows, et qu'elles sont critiques pour certains - et oui, les jeux vidéo font partie des applications critiques, dans le sens où un nombre non-négligeable d'utilisateurs se servent de leur ordinateur comme d'une console de jeux + console d'accès au net.
A partir du moment où une certaine masse critique de logiciels libres sera utilisée sur les systèmes propriétaires, le comportement du système en lui-même sera beaucoup moins visible (évidemment ce n'est que mon avis).
Pour info, j'ai Mac OS X en dual boot avec une debian sur mon ibook. En pratique, je n'ai que cet OS de propriétaire (et éventuellement les applications fournies avec l'ibook, mais j'ai désinstallé la plupart). Le reste est issu des logiciels libres.
Dernière chose : il n'est absolument pas inimaginable qu'un OS libre sorte un jour, et qu'il ait un comportement très différent d'un OS compatible POSIX. Le côté multiplateformes se posera alors encore.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Larry Cow . Évalué à 3.
ReactOS? Haiku OS? Syllable?
[^] # Re: Les Gnomistes m'emmerdent
Posté par dinomasque . Évalué à 2.
http://www.gnu.org/prep/standards/standards.html#Non_002dGNU(...)
BeOS le faisait il y a 20 ans !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les Gnomistes m'emmerdent
Posté par lasher . Évalué à 5.
A partir du moment où une certaine masse critique de logiciels libres sera utilisée sur les systèmes propriétaires, le comportement du système en lui-même sera beaucoup moins visible (évidemment ce n'est que mon avis).
En résumé :
La méthode la plus rapide pour imposer Linux à la place de windows est d'abord de le faire dans les entreprises, qui se chargeront de former leurs employés.
Si on "inonde" un SE proprio avec du logiciel libre de bonne qualité, on redonne à l'utilisateur la bonne manie de ne pas s'arrêter aux logiciels fournis par défaut (lecture DVD, retouche d'image, système d'exploitation ;-) ).
J'espère donc (naïvement ?) que grâce à une certaine dynamique (et une certaine éducation ?) on arrivera à rendre l'utilisateur critique concernant le choix de ses logiciels.
Il existe actuellement des logiciels qui sont critiques, qu'il s'agisse de logiciels pro ou ludiques. Au niveau des jeux vidéo, il est impératif de proposer un framework de développement presque aussi attractif que celui proposé par MS (et portable).
L'argumentation complète se trouve en-dessous :-)
Bon, voyons le côté pessimiste des choses : tant que dans les boites les gens n'auront pas de formation aux environnements de travail sous Linux, on ne peut effectivement pas espérer récupérer en masse les utilisateurs actuels des micro-ordinateurs. Le meilleur moyen de fournir en masse ce genre de formation me semble évidemment être la formation sur le lieu de travail. Pourquoi Word, Photoshop, etc., ont été si populaires au départ chez le particulier ? Entre autres parce que ce sont les logiciels utilisés quotidiennement au boulot par tout un tas de catégories de travailleurs.
Le côté plus optimiste selon moi : comme je le dis plus haut, si le comportement des applications, au look des fenêtres près, est le même que ce soit sous Linux ou sous Windows, alors la transition me semble bien plus simple. Dire que MS ou Apple "gagnent" des clients lorsqu'on porte sur leur plate-forme des applications libres, cela me semble très erroné. A partir du moment où tu introduis la notion de choix - par exemple, montrer à quelqu'un qu'il existe plusieurs alternatives pour éviter d'avoir à charger 4 logiciels de messagerie instantanée en utilisant gaim, ou adiumX, ou bien en montrant que firefox propose tout un tas de choses plutôt cool que IE n'a pas, idem pour Thunderbird Vs Outlook, etc., on réinstaure le besoin de rechercher une certaine qualité dans les logiciels utilisés, on réapprend à l'utilisateur que les logiciels d'un ordinateur, c'est comme un appareil électroménager : il ne faut pas nécessairement prendre le moins cher/le plus accessible (parce qu'il a été préinstallé par exemple)/...
Au final, j'espère (et là je sais que je suis sans doute un peu trop optimiste) qu'à force d'avoir le choix, il semble naturel à l'utilisateur final de se demander si Windows est bien le SE qui lui convient. S'il répond oui à cette question, alors il aura fait le choix en tout conscience. De plus, on peut dire ce qu'on veut, mais pour le moment, pour certaines grosses applications critiques pour les boites, il n'existe aucune alternative sous Linux. Windows s'impose car il est la seule alternative viable. Idem pour les jeux.
Alors oui, les jeux sous linux, il faudrait les développer, en mettre plein d'autres, etc. Mais comme ils représentent une part non-négligeable des raisons qu'ont les constructeurs à pousser toujours plus loin la puissance des micro-processeurs et des cartes graphiques, il serait plutôt bienvenu que d'une manière ou d'une autre, les jeux arrivent sous Linux. Ca passe selon moi par la présence d'outils équivalents à ceux proposés par DirectX (et non, SDL n'est pour le moment pas tout à fait suffisante). Ils n'ont pas besoin d'être aussi performants que ceux de MS (après tout, MS aura toujours un train d'avance, vu qu'ils connaissent tout de l'API windows, et qu'ils ont des contrats avec les constructeurs de matériel), mais assez pour que les boites qui font du logiciel de type jeu vidéo puissent développer pour une plate-forme telle que Linux. Personnellement, si les jeux arrivaient sous Linux un an après la version Windows (cas de Never Winter Nights, par exemple), ça ne me dérangerait pas (un jeu, s'il est bon, le reste malgré le retard technologique).
[^] # Re: Les Gnomistes m'emmerdent
Posté par Nicolas Schoonbroodt . Évalué à 5.
Pas sympa pour gnome, en effet -->[]
[^] # Re: Les Gnomistes m'emmerdent
Posté par Moonz . Évalué à 9.
On nous crie depuis des années qu'il ne faut pas dire Linux mais GNU/Linux, parce que le noyau c'est pas un OS complet (parfois c'est limite sous entendu que la partie noyau est négligeable), et toussa. Et bien si quelqu'un préfère GNU/Windows à GNU/Linux, grand bien lui en fasse. La partie GNU devant m'assure que:
- la plupart des bugs reports faits par des GNU/Windowsiens me profiteront à moi aussi
- les patchs, pareil
- et tout ce qui est codé par des GNU/Windowsiens aura de grandes chances de m'être utile (et d'être utile aux BSDistes, et j'en passe)
- que si tous les Windowsiens utilisent KHTML/Gecko/jenesaisquoi, ça me garantit que les sites passeront bien aussi sur mon GNU/Linux
En gros, faire de Windows un simple kernel non libre pour tout un OS entièrement libre, ça me gène pas plus que ça. Bien au contraire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . Évalué à 1.
Et dire que si seulement il y avait un moyen de plugger du mini pci sur du mini pci-e, je pourrais lui mettre une prism54 fullmac aux fesses...
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 1.
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.
[^] # Re: Les Gnomistes m'emmerdent
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Donc, je suis content que les devs d'AmaroK ne se soient pas contenté des deux premiers qui ne marchaient pas chez moi.
Tu proposes quoi pour résoudre ce problème particulier ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . Évalué à 2.
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.
[^] # Re: Les Gnomistes m'emmerdent
Posté par lasher . Évalué à 3.
Euh. Tu viens de décrire exactement le comportement de windows. "Ben en utilisant la méthode A, ça marche pas. Mais en cliquant sur le bouton du milieu, en chantant 'Aré Crichna' trois fois, et en me tenant le pied gauche juste après, le bug disparaît pendant au moins 48h." :-)
Le problème de windows, c'est que beaucoup trop de gens convaincus par linux continuent d'aider les gens autour d'eux avec windows (et je me compte parmi ceux-ci). Le jour où les gens pro-OS libres arrêteront d'aider les gens à réparer leur windows, et que ces derniers seront obligés de faire appel à un technicien qui coûte la peau des fesses (ou un SAV, ou ...), je pense qu'on aura fait un grand pas. D'un coup, les gens se rendront compte que les quelques minutes (voire secondes) qui nous suffisent pour régler leurs problèmes peuvent prendre des proportions gigantesques lorsqu'ils ne nous ont plus sous la main.
En fait je continue le "support" informatique pour les gens que j'ai déjà aidés, mais de toute manière je sais de moins en moins m'en servir, donc je suis de moins en moins efficace - et je le leur dis, en laissant des indices concernant Linux et les LL... Et même comme ça, je refuse de les aider s'ils utilisent IE et Outlook Express (parce que je n'ai pas que ça à faire de leur enlever tout un tas de virus installés automatiquement...)
[^] # Re: Les Gnomistes m'emmerdent
Posté par Ph Husson (site web personnel) . Évalué à 3.
M'enfin bon d'ici quelques années, si je continue comme je fais (c'est à dire que j'utilise windows uniquement en cyber café), plus personne ne me demandera de l'aide
[^] # Re: Les Gnomistes m'emmerdent
Posté par dinomasque . Évalué à 6.
J'ai dit à mes parents que s'ils voulaient Windows à la place de Linux ils n'avaient qu'à acheter Windows, MS OFfice, un antivirus, un antipopup, un antispyware, un firewall et un technicien qui réparerait leur windows à ma place.
Finalement ma mère est très satisfaite des jolies icones de son linux.
Un de mes collocataires a fait l'expérience de Linux pendant à peu près un an. Il a décidé de revenir à Windows parcequ'il n'arrive pas à installer les jeux linux alors que la méthode clic-clic-installshield de Windows lui va bien. Je lui ai bien dit qu'il devrait se débouiller pour ses problèmes.
J'ai fait de la place dans mon cerveau en oubliant toutes les techniques de maintenance de Windows que j'avais appris et je m'en porte bien mieux (et puis au boulot, y'a des gens très bien payés pour réparer mon windows)
BeOS le faisait il y a 20 ans !
[^] # Re: Les Gnomistes m'emmerdent
Posté par Moonz . Évalué à 6.
Est-ce que tu as regardé le projet Ridley ? J'en ai pas l'impression... A peut près tout ce qui est intégré dans GTK bénéficiera à _tous_ les utilisateurs de GTK (y compris Xfce/ROX/...): ce sont des trucs basiques qui auraient du être présents dès le départ (GtkAboutDialog, c'est vrai que c'est une merde pro-gnome qui va emmerder tous les devs GTK qui ne veulent pas de truc pro-gnome...)
Ne t'en fais pas que si le but avait été d'intégrer gnome-vfs, orbit ou bonobo, là un bon paquet de moules sur linuxfr auraient ralées (moi en premier)
[^] # Re: Phonon
Posté par Gmooron . Évalué à 9.
[^] # Re: Phonon
Posté par ragnar . Évalué à 10.
Faut voir aussi le fanboysme du projet GNU sur le C. Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C. A propos de ce pauvre Nautilus, il a été mutilé par la mode spatiale puis ils sont revenus en arrière, avec une bonne partie de développeurs gnome de haut calibre qui disent que c'était un échec..
"Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance."
Du calme, car ici, c'est DBUS qui est arrivé comme un cheveux sur la soupe en copiant les principes de base de DCOP et en rajoutant de la complexité à la tâche. Hebergé par freedesktop, les mecs de KDE vous font une faveur en adoptant un projet censé favoriser l'intéropérabilité des deux desktop..
En attendant, j'attends de voir une utilisation plus poussée chez Gnome de leur corba avant qu'ils la ramènent, quand on voit où on en est avec les kparts sous KDE..
kparts et KDE = code reuse. Kontact, le concurrent KDE à Evolution, réutilise des kparts pour toutes ses fonctions, tandis qu'evolution n'est qu'une sale application monolithique à la maintenance affreuse.
"[...]
[Là je coupe ton baratin sur Phonon]
[...]"
Phonon a pour but d'unifier dans le desktop KDE toutes les petites tâches audio que peuvent avoir besoin la majorité des appli, dans une API stable et pas prise de tête. Phonon n'est pas un concurrent à une quelconque technologie gnome et je ne vois pas très bien ton problème, là. Les logiciels les plus compliqués continueront d'utiliser xine ou, au pire, gstreamer, les autres auront une API tranquille sur laquelle ils ne s'arracheront pas les cheveux pour la suivre. En quoi les développeurs de KDE gênent ton pauvre petit gstreamer d'amour ?
"Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun."
Le meilleur, actuellement, ça n'est certainement pas gstreamer, donc là, tu repasseras avec tes délires fanatiques.
"Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt)."
Absolument pas. Les applications avancées sont libres de faire ce qui est nécessaire, le gros du desktop lui utilisera en effet Phonon.
"* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits."
Phonon permets la portabilité sur les quelques plateformes où gstreamer ne tourne pas. Par sa nature à multiple backend, il ne sera pas très difficile de l'adapter à des systèmes exotiques.
"Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel."
Les premiers à avoir provoqué cette division, c'est les mecs de Gnome. Gnome 1.x n'était rien d'autre qu'une copie de KDE, avec une interface encore plus bourrée d'options. Ce n'est que tardivement qu'ils se sont cherchés une identité et ont dépassé le stade "Nous sommes KDE en C, et nous sommes pro-GNU".
Je trouve ça gonflé de venir parler de division ici en accusant les développeurs de KDE de pratiquer la "défiance" envers les dev gnome.
[^] # Re: Phonon
Posté par clearstream . Évalué à -8.
C'est pour avoir des bindings. Ca été répété 5*10^43 fois.
Côté binding, KDE ne boxe pas dans la même catégorie.
> Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C.
Du style un couteau sous la gorge ?
Il y a des programmes en C# maintenant dans Gnome.
> A propos de ce pauvre Nautilus, il a été mutilé par la mode spatiale puis ils sont revenus en arrière, avec une bonne partie de développeurs gnome de haut calibre qui disent que c'était un échec..
Le mode spatiale est toujours là et toujours par défaut.
Apparament tu n'utilises pas nautilus.
> Du calme, car ici, c'est DBUS qui est arrivé comme un cheveux sur la soupe
Havoc en a largement parlé avant qu'il y ait la moindre ligne de code. Tout a été fait sur freedesktop.org en public.
> en copiant les principes de base de DCOP
Et alors ? Si ça ne plait pas à KDE, il fallait breveter DCOP.
> et en rajoutant de la complexité à la tâche.
Forcément, un troll.
> Hebergé par freedesktop, les mecs de KDE vous font une faveur en adoptant un projet censé favoriser l'intéropérabilité des deux desktop..
Un sens hautement élevé du sacrifice.
Tu ne trouves pas que là tu prends les développeurs de KDE pour des gogos ?
> En attendant, j'attends de voir une utilisation plus poussée chez Gnome de leur corba avant qu'ils la ramènent
Ben si ça peut occuper tes longues nuits d'hiver.
Pour la ramener, je vais te décevoir, mais ils vont se passer de ton accord.
> quand on voit où on en est avec les kparts sous KDE..
Tant mieux pour KDE.
En passant : ça fait depuis des années que les KDE fanboys répètent que KDE à 10 années lumières d'avance.
Mais comment c'est traduit cette fabuleuse avance depuis d'au moins 5 ans ?
On se le demande.
> tandis qu'evolution n'est qu'une sale application monolithique à la maintenance affreuse.
Evolution plait aux utilisateurs.
Il est évident que tu ne connais pas l'architecture d'évolution.
> Phonon a pour but d'unifier dans le desktop KDE toutes les petites tâches audio que peuvent avoir besoin la majorité des appli
Idem Gstreamer mais pas que pour les petites tâches.
> dans une API stable et pas prise de tête.
Parce que l'objectif de Gstreamer serait de faire un API prise de tête et pas stable ?
Gstreamer veut avoir une API stable. Mais dans le domaine du desktop ça bouge beaucoup. Un desktop n'est pas aussi critique qu'un serveur.
Debian avec sa politique de stabilité n'a pas un succès retentissant dans le domaine du desktop.
M'enfin, je ne veux pas t'oter l'espoir qu'il est possible de faire aujourd'hui une API qui sera répondre aux attendes des utilisateurs et développeurs demain.
> Phonon n'est pas un concurrent à une quelconque technologie gnome et je ne vois pas très bien ton problème, là.
Premièrement, que KDE soit un concurrent de Gnome, ne me dérange en rien.
Pour le reste, j'y ai répondu ailleurs.
> Les logiciels les plus compliqués continueront d'utiliser xine ou, au pire, gstreamer,
Troll. Pourquoi pas au mieu ?
[Notes que j'ai jamais dit que Gstreamer était meilleur que ses concurrents. Vous, vous arrêtez pas de défoncer Gstreamer gratuitement.]
Tu le dis, Phonon est une API stable qui n'est pas destiné à être largement utilisé. Quel est l'intérêt ?
Tu mets en place une API stable lorsque celle-ci sera très utilisée. Sinon c'est se mettre un boulet au pied.
> les autres auront une API tranquille sur laquelle ils ne s'arracheront pas les cheveux
Gstreamer est simple quand il faut faire des choses simples et compliqué quand il faut faire des choses compliqués.
> En quoi les développeurs de KDE gênent ton pauvre petit gstreamer d'amour ?
Déjà expliqué, et ça va au-delà de Gstreamer uniquement.
> Le meilleur, actuellement, ça n'est certainement pas gstreamer, donc là, tu repasseras avec tes délires fanatiques.
J'ai dit que Gstreamer était le meilleur ?
J'ai dit que Xine était naze par rapport à Gstreamer ?
Je pense que KDE devrait prendre le meilleur framework. S'il pense que c'est Xine, ben ils prennent Xine.
> Absolument pas. Les applications avancées sont libres de faire ce qui est nécessaire, le gros du desktop lui utilisera en effet Phonon.
Merci de démontrer l'intérêt limité de Phonon.
> Phonon permets la portabilité sur les quelques plateformes où gstreamer ne tourne pas.
http://gstreamer.freedesktop.org/features/
Au-lieu de bouffer du temps à faire un truc tordu qui ne proposera que le minimum, et donc l'insatisfaction de l'utilisateur (l'utilisateur de desktop aujourd'hui est exigent et n'attend pas le minimum), ils feraient mieux de bosser sur Gstreamer (ou Xine ou autre).
Là où il faut bosser, c'est le framework. Ce n'est pas en ne bossant pas sur le framework, qu'on finira par avoir un framework (que ce soit Gstreamer ou Xine ou autre) qui roxe et pourra faire de l'ombre à WMP.
> Par sa nature à multiple backend, il ne sera pas très difficile de l'adapter à des systèmes exotiques.
C'est pour faire le bonheur de moins de 0,5 % des utilisateurs qui vous n'allez offrir que le minimum à plus de 99,5 % des utilisateurs...
Gstreamer couvre déjà 99,5 % des ordinateurs si ce n'est plus.
Le jours où KDE sera sur plus de 99 % des ordinateurs, l'usage de Phonon sera sensée.
[^] # Re: Phonon
Posté par Amand Tihon (site web personnel) . Évalué à 10.
1 : KDE a besoin d'offrir un moyen simple, présent dans les libs au coeur de toute installation KDE, de jouer des sons. Le support peut parfaitement être super-basique, mais il faut quelque chose.
2 : KDE a décidé, et ce depuis très longtemps (le tout début ?) que tout au long de la vie d'une version majeure, la compatibilité binaire était conservée dans les libs "core".
Il s'ensuit que KDE ne peut pas considérer GStreamer, ni même xine, comme interface par défaut de toute installation KDE. Ils n'ont pas autorité sur le développement et les cycles de release de ces bibliothèques. Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout. Et là, tu ne serais plus tout seul à crier, crois-moi.
Se dire que xine ou GStreamer seront incapables de garder une ABI compatible sur les deux ou trois (ou quatre, si KDE 5 se fait attendre) années à venir, ce n'est pas de la défiance, c'est du simple bon sens.
Dans KDE 4, les notifications sonores passeront sans doute par Phonon. Peut-être également les "prévisualisations" de fichiers audio. Mais je suis persuadé que mon Amarok et mon Kaffeine utiliseront toujours Xine... sauf si le "plus petit dénominateur commun" qui te fait si peur est capable de les remplacer sans perte de fonctionnalités. Soit Phonon est petit, et est là pour toute application qui a besoin de fonctions basiques ; soit Phonon est grand, et encapsule Xine de manière étendue et avec une interface propre à KDE. Dans les deux cas, il comble un besoin.
Et avec tout ça, je ne comprends toujours pas ce que tu lui reproche. L'API de Phonon n'est pas développée à partir du PPCD des libs existantes, elle est faite selon les besoins des développeurs. Qu'il y ait un ou plusieurs backends ne change rien à l'histoire. Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ? Pourtant, OSS est vachement limité !
Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour, Phonon sera joyeusement mis à la poubelle. Qui sait, ce moteur sera peut-être même développé en collaboration Gnome/KDE, sur les bases de GStreamer ou xine ?
[^] # Re: Phonon
Posté par clearstream . Évalué à -3.
Sacré défit...
> 2 : KDE a décidé, et ce depuis très longtemps (le tout début ?) que tout au long de la vie d'une version majeure, la compatibilité binaire était conservée dans les libs "core".
Fichtre, comme Gnome. Une appli Gnome 2.0 tourne sous n'importe qu'elle Gnome 2.x.
Et oui, il y a toujours esound avec Gnome 2.14 et il y sera là temps que Gnome 3.0 ne sera pas sorti.
Gstreamer ne fait pas encore parti de la "gnome platform". Il est dans "gnome desktop". Mais il sera dans la "gnome platform" pour Gnome 3.
Gnome est découpé en :
- gnome platform
- gnome desktop
- gnome binding
- gnome admin
Gnome platform : ftp://ftp.gnome.org/pub/GNOME/platform/
> Il s'ensuit que KDE ne peut pas considérer GStreamer, ni même xine, comme interface par défaut de toute installation KDE. Ils n'ont pas autorité sur le développement et les cycles de release de ces bibliothèques.
Ben comme X11, comme Qt, comme la libc, comme dbus, comme libxml2, etc...
Tu m'expliques pourquoi KDE pinaille avec le framework media et pas avec le reste ?
Pourtant c'est exactement le même problème.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout.
Pourtant ça se fait. Regardes les distributions qui garantisse la compatibilité ABI durant le support.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer
Une autre solution est aussi l'encapsulation (NB : c'est un bon motif d'encapsulation).
Que fait KDE : ils encapsulent plusieurs backends.
KDE devra gérer les changement d'ABI de plusieurs backends.
Où est l'avantage ?
Mistère...
Gnome ne fait ça que pour *un* backend. Pour Gnome 2.x, c'est esound. A partir de Gnome 3.0, ça sera Gstreamer et pour toute la vie de Gnome 3.x (On peut tabler sur 5 ans par analogie avec Gnome 2.x).
> Se dire que xine ou GStreamer seront incapables de garder une ABI compatible sur les deux ou trois (ou quatre, si KDE 5 se fait attendre) années à venir, ce n'est pas de la défiance, c'est du simple bon sens.
Ben applique le même raisonnement pour les autres librairies que KDE utilise mais ne développe pas.
> Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ?
Que est le rapport ?
Xine (idem pour gstreamer) subit Linux (OSS et alsa (qui n'avait pas dmix)), KDE (arts), et Gnome (esound).
Aujourd'hui sous Gnome avec Gstreamer : Ben comme alsa utilise dmix, Xine a uniquement besoin d'alsa et se fout de la présence ou non de Gstreamer.
Pourquoi tu veux que Xine maintienne les vieilleries ?
Je ne comprend pas.
La meilleur solution, c'est alsa. Donc on prend alsa et le reste on l'oubli. On ne s'amuse pas à garder 50 trucs plus ou moins bon car on a la trouille qu'alsa change d'API, ou ne soit plus maintenu.
> Pourtant, OSS est vachement limité !
Je n'utilise pas OSS.
> Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour
KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive.
[^] # Re: Phonon
Posté par oops (site web personnel) . Évalué à 5.
Maintenant arrête !
[^] # Re: Phonon
Posté par Amand Tihon (site web personnel) . Évalué à 4.
X11 est encapsulé par Qt (tiens, il a plusieurs backends, lui !)
Qt garde sa compatibilité binaire sur les versions majeures.
dbus est encapsulé par Qt 4.
Je continue ?
Que fait KDE : ils encapsulent plusieurs backends.
Non.
KDE décide que l'encapsulation est nécessaire (le motif est bon, selon toi). Et ils se rendent compte que, tant qu'à faire, autant prévoir une API style KDE et générique. Et cette généricité permet à ceux qui le veulent de créer et d'utiliser un autre backend s'ils n'aiment pas/ne peuvent pas utiliser celui qui a été choisi. Et évidemment, c'est ce qui arrive, mais ce n'était pas le but premier de Phonon, c'est juste un effet de bord.
Ben applique le même raisonnement pour les autres librairies que KDE utilise mais ne développe pas.
C'est exactement la même chose qui se passe. Si ça se retrouve dans Qt ou kdecore, c'est encapsulé. Et si une application décide de passer outre, et d'utiliser directement la bibliothèque, rien ne l'en empêche.
[^] # Re: Phonon
Posté par clearstream . Évalué à 2.
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.
[^] # Re: Phonon
Posté par Amand Tihon (site web personnel) . Évalué à 5.
J'ai déjà dit et répété que le rôle de Phonon n'est pas d'apporter un choix et plein de backends. Son rôle est d'offrir une ABI stable, et une API qui correspond à celle de KDE. Et s'il faut encapsuler pour avoir ça, eh bien ce sera encapsulé.
Et si cette encapsulation permet de manière simple à certains gars d'écrire d'autres backends, grand bien leur fasse. Ils font ce qu'ils veulent de leur temps.
Fin du thread pour moi.
[^] # Re: Phonon
Posté par Pinaraf . Évalué à 7.
> en copiant les principes de base de DCOP
> et en rajoutant de la complexité à la tâche.
Forcément, un troll.
C'est pourtant ce que l'on peut lire dans la foire aux questions de ..... DBUS !
http://dbus.freedesktop.org/doc/dbus-faq.html#dcop
[^] # Re: Phonon
Posté par clearstream . Évalué à -2.
L'original :
Le "Forcément, un troll" est pour "et en rajoutant de la complexité à la tâche".
[^] # Re: Phonon
Posté par Pinaraf . Évalué à 6.
[^] # Re: Phonon
Posté par clearstream . Évalué à -4.
C++ est plus compliqué que le C, ça ne veut pas dire que pour une tâche donnée, C++ est plus compliqué à utiliser.
Compris ou il te faut un dessin ?
[^] # Re: Phonon
Posté par ragnar . Évalué à 9.
Ta gueule.
"The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus."
Et un détail croustillant :
"D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though. "
[^] # Re: Phonon
Posté par ragnar . Évalué à 6.
> Les mecs d'Eazel ont voulu programmer au départ le Nautilus en C++ mais chez gnome ça a hurlé alors ils l'ont codé en C.
Du style un couteau sous la gorge ?
Il y a des programmes en C# maintenant dans Gnome."
Les temps changent, et les mecs de Ximian pèsent un poids lourd sur les décisions prises par Gnome. Le fait qu'Eazel se soit fait critiquer pour avoir voulu faire le nautilus en C++ ne change pas.
"Le mode spatiale est toujours là et toujours par défaut.
Apparament tu n'utilises pas nautilus."
Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro, et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome. Lis un peu ce qu'ont à dire Nat Friedman ou Jeff Waugh sur le sujet.
"KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive."
KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer, tout ce qu'ils peuvent faire, c'est juste l'adopter, ce qui est une très mauvaise idée. KDE n'a que Trolltech comme boite commerciale qui soutient, et c'est surtout du côté de la lib QT. 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 comme si tu comparais les ressources mises sur linux et celles mises sur les BSD. Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
[^] # Re: Phonon
Posté par lezardbreton . Évalué à 4.
Pas uniquement, KDE a compris que les gens qui développent les applications graphiques ne sont pas les mêmes que les gens qui développent des frameworks multimedia. C'est l'esprit une tache - une appli appliquée aux développeurs. Un développeur de navigateur web n'a pas forcément les connaissances, les compétences et l'envie pour participer au développement d'un framework multimedia. KDE participe tout de même aux projets qu'ils utilisent dans la mesure de leur moyen. Cmake a par exemple été beaucoup amélioré pour supporter KDE, et ça s'est fait en collaboration avec les devs KDE.
Sinon, au niveau des appuis commerciaux de KDE, il ne faut pas oublier Mandriva et SUSE.
[^] # Re: Phonon
Posté par Brice2 . Évalué à 4.
[^] # Re: Phonon
Posté par mats . Évalué à 1.
On en est maintenant à au moins la quatrième, qui, ça tombe bien, débute avec kde4.
Ceci dit, tous ces développeurs qui font tous les jours avancer les logiciels libres, quelle bande d'idiots tout de même : les mecs, ils développent des bouses avec les pieds !!! c'est hallucinant non ?
Heureusement que certains veillent ici pour nous en informer.
[^] # Re: Phonon
Posté par Spyhawk . Évalué à 0.
Trop gros. Passera pas. ^^
[^] # Re: Phonon
Posté par ragnar . Évalué à 2.
SuSE a viré une partie de son staff quand ils se sont fait chopper par Novell (les vrais décideurs sont du camp Ximian.) et Mandriva est une petite distribution qui n'a pas vraiment le moyen de réellement soutenir KDE. D'ailleurs, t'as cas comparer la contribution de Mandriva et celle de Red Hat sur des sujets importants comme le kernel, gcc etc, tu verras que Mandriva à part faire leur propre distrib ils font pas grand chose.
[^] # Re: Phonon
Posté par lezardbreton . Évalué à 3.
[^] # Re: Phonon
Posté par clearstream . Évalué à 1.
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.
[^] # Re: Phonon
Posté par med . Évalué à 10.
T'es quand même quelqu'un de vachement fort, en deux secondes de réflexion ton cerveau surpuissant a réussi à faire mieux dans une prise de décision que des dizaines de développeurs de KDE ayant des années d'expérience et ayant réfléchi au meilleur compromis pour les n années à venir. Franchement chapeau, je ne crois pas avoir rencontré quelqu'un d'aussi puissant que toi.
[^] # Re: Phonon
Posté par ragnar . Évalué à 2.
Kubuntu c'est juste une "cerise sur le gateau". La machine marketing derrière Ubuntu elle pousse Gnome.
Les premières Kubuntu étaient horriblement instables et les packagers avaient fait du boulot de merde. En fait, c'est dire, utiliser KDE sur une fedora, malgré le manque de logiciels QT, devait être plus agréable qu'utiliser les premières Kubuntu. La dapper est un peu plus correcte mais ça reste de la mauvaise finition.
"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".
C'est là que je ne te suivais pas, en fait. En tant qu'utilisateur, Xine me va très bien et je ne vois pas de raison d'améliorer ce qui me convient déjà. Du point de vue des développeurs KDE, ils veulent s'immuniser si un jour Xine ne trouvait plus de programmeurs pour maintenir le backend (ce qui est tout à fait possible, dans le fond..), en créant une architecture indépendante couvrant les besoins minimaux et permettant de se séparer en un rien de temps du backend abandonné.
Note que les mecs qui créent les API et l'abstraction de Phonon n'ont pas forcément les compétences requises pour développer à plein temps Xine lui même. Entre faire quelques abstractions et faire tout un framework multimédia, y'a un monde.
[^] # Re: Phonon
Posté par Nelis (site web personnel) . Évalué à 7.
Mais bordel t'es bouché ou quoi !! Le but de Phonon n'est pas de faire un autre framework multimédia, c'est de faire une API simple, intégrée avec le reste de KDE, pour faire les tâches multimédia _de base_.
La raison d'être de Phonon me parait tout à fait justifiée, ça va permettre à n'importe quel développeur d'applications KDE de bénéficier des fonctionnalités multimédia de base sans devoir apprendre d'autres API ou se poser la question "quel framework les utilisateurs vont ils avoir".
Le fait que Phonon supporte plusieurs backends parait logique dans cet optique, et de plus, je ne pense pas que ça sera un boulot tellement gigantesque d'implémenter Phonon pour les différents backends.
J'ai vraiment l'impression que tu n'as pas compris (ou que tu ne veux pas comprendre) la philosophie derrière Phonon ...
[^] # Re: Phonon
Posté par clearstream . Évalué à -2.
Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité.
Au final le développeur va surement apprendre une autre API, alors qu'il aurait pu se contenter d'en apprendre qu'une.
Puis mets toi à la place du développeur lorsqu'il envisage de faire une appli. Es-ce qu'en général il se dit "je vais prendre ce truc là car il permet le minimum au rique d'être bloqué et de passer à autre chose", ou "je vais prendre ce truc là car il permet le maximum et j'ai peu de chance d'être bloqué et il me donne plus de liberté".
Il faut aussi savoir évaluer la complexité. Quelque chose avec plein de fonctionnalité n'est pas forcément plus compliqué que quelque chose avec peu de fonctionnalité.
Par exemple php a plein de fonctionnalités. Si tu enlèves le support pour xml, les expressions rationnelles, les accès aux bases de données, es-ce que ça rend php plus simple dans le cadre d'un programme simple qui n'utilise pas xml, ni les expressions rationnelles, et n'accède pas à une base de donnée ?
Ben non.
Dans une bonne API, ce dont tu ne te sers pas, ne doit pas te géner.
Pour un développeur C, il n'est pas plus compliqué de faire du C avec un compilateur C++ même si ce dernier à plus de fonctionnalité.
Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur.
Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon".
[^] # Re: Phonon
Posté par mats . Évalué à 8.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité."
On se tue à te dire que *non* il ne demandera pas une extension à phonon. Il apprendra à se servir d'une boître à outils plus conséquente (et ce ne sera, la plupart du temps, pas nécessaire).
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.
Il ne s'agit ni plus ni moins que de mutualiser les efforts (au niveau de kde bien sur) et d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
"Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur."
Toujours les mêmes sympatiques humilité et nuance.
Je t'engage à relire les commentaires sur le blog de Aaron Seigo, 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.
"Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon"."
Comment le sais-tu ? As-tu déjà développé pour Kde ? Raisonnes-tu comme eux ?
Vu de l'extérieur (j'utilise Gnome et je ne suis pas un programmeur émérite), 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. Ils ne restent donc que fidèles à leur façon de faire avec 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. Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine mais je pense que la plupart de ceux n'ayant pas des besoins spécifiques (seulement lire des fichiers audio et vidéo) ne se priveront pas de cette possibilité.
À suivre donc...
[^] # Re: Phonon
Posté par clearstream . Évalué à 1.
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.
[^] # Re: Phonon
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
Néanmoins, je voudrais te faire les remarques suivantes :
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.
Il y a la question de la compatibilité binaire qui a été soulevée (tu dis que ça marche aussi avec gnome, mais je ne suis pas assez au courant pour débattre). Ceci dit, une api mouvante est une bonne raison d'encapsuler : Phonon étant destiné à tes tâches simples, il est à priori possible de s'adapter aux changements du backend sans changer l'API de Phonon.
Conséquence directe, quand l'API d'un framework change, ce n'est pas toutes les applis qui doivent s'adapter, mais seulement Phonon.
C'est un gros plus pour les développeurs qui utilisent juste le son pour lire un ogg qui insulte l'utilisateur quand il clique n'importe où.
2) Quoique tu en dises, il est plus simple de prendre en main une bibliothèque qui a une petite API plutôt qu'une bibliothèque qui a une API qui permet de faire le café.
3) Tu as parlé des applis qui voudraient plus de fonctionnalités et donc Phonon serait insuffisant. On ne parles pas ici de AmaroK ou Kaffeine, mais plutôt des applis genre K3B : il y a peu de chances que les utilisateurs demandent à K3B de faire autre chose que lire un son quand la gravure a réussi ou échouer (ou alors, je retourne avec mon fvwm et mes xterms).
4) Last, but not least, je suis d'accord sur le fait que l'unicité d'un framework est multimédia est une bonne chose, mais c'est infaisable en pratique. C'est là-dessus que se base une bonne partie de ton raisonnement, et il assez cohérent si on accepte cette assertion. 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. 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.
mes 2 centimes dans ce dialogue de sourds.
[^] # Re: Phonon
Posté par clearstream . Évalué à 2.
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 :-)
[^] # Re: Phonon
Posté par Olivier Serve (site web personnel) . Évalué à 5.
Ou bien si un backend ne compile pas (64 bits, problème de versions de libs sur une plateforme donnée), pouvoir choisir un backend qui lui compile au lieu de se retrouver sans aucun son.
Le but de Phonon n'est évidemment pas de changer de backend toutes les 5 minutes, mais d'avoir la possibilité de choisir et de s'adapter à l'environnement choisi par les distributions et/ou l'utilisateur.
Si le backend X a un bug, je ne vois pas en quoi c'est lié à Phonon ni en quoi ça constitue un échec pour lui. Au contraire, dans ce cas-là, l'intérêt saute aux yeux.
Because it can be done ;-) 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 ?
[^] # Re: Phonon
Posté par clearstream . Évalué à 1.
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 ?
[^] # Re: Phonon
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Malheureusement, ce n'est pas le cas, et il ne peuvent pas prendre la responsabilité de trop se lier à un framework. On a vu ce que ça a donné avec arts...
Il y a tellement d'autres choses à développer pour KDE4 qui sont davantage dans le cadre de KDE. Développer un petit wrapper ne coûte pas cher et résoud un problème immédiat. Et les développeurs des backends vont sans doute rencontrer des bugs dans les frameworks et donc les reporter d'où augmentation générale de la qualité. Certains vont peut-être même mettre la main à la pâte...
J'espère aussi que les frameworks multimédia gagnent en maturité et qu'on arrivera à en avoir 1 ou 2 activement soutenus qui sortiront du lot. Dans KDE5, qui sait ?
[^] # Re: Phonon
Posté par clearstream . Évalué à 0.
C'est aussi du pur pragmatisme que de vouloir corriger le logiciel libre là où il sucks.
> il ne peuvent pas prendre la responsabilité de trop se lier à un framework.
Mais il le font pour Qt, etc...
Tout le monde le fait et par pragmatisme.
> J'espère aussi que les frameworks multimédia gagnent en maturité et qu'on arrivera à en avoir 1 ou 2 activement soutenus qui sortiront du lot. Dans KDE5, qui sait ?
Espérons que KDE5 sorte vite :-)
[^] # Re: Phonon
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Qt est stable et fonctionne bien de puis longtemps. Ce n'est pas encre le cas des frameworks mm.
[^] # Re: Phonon
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
Encore une fois, le but de Phonon n'est pas d'implémenter tous les backend.
Si certains ont envie d'implémenter des nouveaux backend, qu'ils le fassent, mais il ne me semblent pas qu'il y en aura une tripotée d'officiellement supportée.
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".
Le rapport avec la choucroute ? Tu crois vraiment que les devs de kwin par exemple ont besoin du dernier cri pour lire un son quand tu réduis ta fenêtre ?
Sans compter qui s'il s'agit d'une technologie qui améliore une fonctionnalité (genre le 5.1 sur la lecture d'un son), elle peut être intégrée à Phonon (et du coup, toutes les appli l'auront, sans que les développeurs changent une ligne, merveilleux, non ?).
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).
Au contraire, il s'agit de toutes les applications KDE, sauf les applis multimédias. Je ne pense pas qu'on puisse parler d'une poignée.
Allez, je le répète encore une fois : on parle ici des applications qui ont des besoins simples en multimédia. Ces besoins ont-ils évolués pendant les 5 dernières années ? Si oui, j'aimerai bien savoir en quoi.
Ta comparaison avec le noyau 2.6 ne tient pas, justement parce que ce qu'ils cassent, c'est la compatiblité avec les applications qui dépendent intimement du noyau.
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.
Il me semble, bien que je ne sois pas sûr à 100%, qu'il s'agit de l'inverse.
Un binaire compilé sur KDE 3.4 doit toujours marcher avec KDE 3.5.
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).
Les drivers, c'est quand même quelque chose d'intimement lié à X.org, ce qui n'est pas le cas des appli qui utiliseront Phonon vers une api multimédia.
J'ai quand même pas envie d'apprendre 5 framework multimédia et de maintenir à jour juste pour lire un son quand j'affiche mes mickeys qui clignotent.
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.
J'essaie justement de t'expliquer qu'il y gagne, puisque :
on est sûr que pour toutes appli qui veut jouer un son, si elle s'appuie sur un seul framework, il y aura un utilisateur pour prendre la tête aux devs parce qu'il aime pas ce backend.
Partant de ce principe, toutes les appli, si elles veulent satisfaire les utilisateurs, doivent implémenter plusieurs backend. Toujours pour, rappelons-le, lire un son quand elles affichent des mickeys qui clignotent.
Ne crois-tu pas qu'il peut être intéressant d'écrire un wrapper qui permette de lire un son avec choix du backend ?
Crois-tu vraiment qu'un utilisateur va demander aux devs d'une appli classique d'ajouter de nouvelles fonctionnalités sur le son ? Genre le support du wma42 DRM21 inside ?
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 ?
Parce qu'il y a la petite-fille de la tante du cousin de ma mère qui développe le backend plopiniou. Elle est très jolie, donc je préfère utiliser le backend plopiniou.
Des raisons connes pour pouvoir préférer un backend à un autre à fonctionnalité égale, il y en a des milliards.
Croire que l'utilisateur ne va pas vouloir imposer le sien, c'est au moins aussi idiot que croire que l'utilisateur ne va pas demander à kwin plus que lire des fichiers ogg lors d'un évènement.
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?
Parce qu'il y a des utilisateurs qui préfèrent celui-là, pour une raison X ou Y, recevable ou non.
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 ...
Je veux que toutes les appli qui jouent du son, de kwin à kopete en passant par kttsmgr utilisent le même backend de lecture.
Alors certes, on peut imaginer que toutes les applications lisent une préférence dans un fichier commun et qu'elles implémentent toutes le support de différents backend.
Ou bien on peut imaginer une lib qui wrappe les fonctionnalités vers différents backend, et qui lise son propre fichier de conf.
[^] # Re: Phonon
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 8.
Pour KDE4, ce cahier des charges est renouvellé, c'est pourquoi KDE ne pouvait se lier à Gstreamer (et non pas a cause d'une liaison gnome/gstreamer, argument stupide). Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Apres, personne ne jete la pierre à Gstreamer, c'est normal vu la jeunesse du projet. Apres, KDE aurait pu se lier a un autre backend, mais les autres ont soit le meme soucis, soit d'autres. Et dans l'hypothèse où KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Finalement, je pense plutot que Phonon donne du temps à Gstreamer pour murrir et s'imposer, tout en garantissant la compatibilité binaire chere à KDE.
[^] # Re: Phonon
Posté par clearstream . Évalué à -3.
Gnome à le même cahier des charges.
> et non pas a cause d'une liaison gnome/gstreamer, argument stupide
Qu'es-ce qui te garantit que Qt sera stable durant toute la vie de KDE 4 ?
Qu'es-ce qui te garantit que libjpeg, libxlst, libxml, libsvg, libpcre, libpng, libpgpgme, libnetsnmp, libdbus, libhal, libsmb, et encore une dixaine d'autres librairies non développées par KDE et utilisées par KDE resteront stables durant toute la vie de KDE ?
KDE a-t-il prévu des "phonons" pour toutes ces librairies ?
Non.
Alors pourquoi ce "traitement de faveur" pour Gstreamer ?
A part une raison stupide, je ne vois pas.
> Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Premièrement, Gstreamer n'a pas cherché à garantir la stabilité de l'API entre la version 0.8 et 0.10. Donc la question de ne pas pouvoir ne se pose pas, car Gstreamer ne voulait pas. Comme KDE ne veut pas garantir la compatibilité entre KDE 3 et KDE 4. La version 0.9 (de développement) était dès l'origine incompatible avec la version 0.8 et c'était prévu avec sa création. La version 0.9 était dès l'origine installable à côté de la version 0.8 (pour conserver une API stable).
Linux est pire que Gstreamer, il n'y a ni ABI et API stable entre versions mineures (x.y.n et x.y.n+1).
Remarquons le culot dont à fait preuve KDE à propos de l'incompatibilité entre gstreamer 0.8 et 0.10 en disant que ça a casser les applis des utilisateurs après une mise à jours. N'importe qu'elle gestionnaire de paquet digne de ce nom aurait refusé de mettre à jour gstreamer 0.8 vers 0.10 si des programmes utilisent gstreamer 0.8 et ne sont pas disponibles en version gstreamer 0.10.
C'est le boulot des gestionnaires de paquet !
Remarquons le culot de KDE de dire que gstreamer 0.10 a introduit des bugs qui n'existaient pas dans gstreamer 0.8. Je suis sûr à 12 000 % que KDE 4 va ajouter des bugs qui n'étaient pas dans KDE 3 et qui ne vont pas être corrigés ni dans la semaine et ni dans le mois de la sortie de KDE 4.
Et quel culot de la part de KDE de critique la maintenance de Gstreamer alors que KDE n'est pas foutu de maintenir Arts qui fait le quart du huitième de ce que fait Gstreamer.
Quand on fait preuve d'un tel niveau de FUD, il y a quelque chose de stupide, de crétin, qui se cache.
> KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Ben avec Phonon, KDE "garantit" la sission des frameworks durant tout KDE 4. Inutile d'instrumenter Gnome pour le constater.
[^] # Re: Phonon
Posté par clearstream . Évalué à -1.
Tout a un rapport avec la choucroute.
> améliore une fonctionnalité (genre le 5.1 sur la lecture d'un son), elle peut être intégrée à Phonon
Yet another backend.
[^] # Re: Phonon
Posté par Mark Havel . Évalué à 10.
On a parfaitement compris ton avis sur Phonon, je pense que c'est inutile de continuer à perdre ton temps à nous le répéter depuis que ce journal est apparu. Ca s'appelle un beau troll et après ça, on s'étonne d'éventuelles baisses de fréquentation du site ou de baisses des contributions en tout genre au site...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Phonon
Posté par Marc Poiroud (site web personnel) . Évalué à 4.
avant de me faire ramasser ... je ne suis pas développeur et j'y connais rien !
KDE = > multiplateforme (*nix / Windows)
Photon = > couche d'abstraction pour le multimédia
Donc en gros, Photon va permettre à un dev KDE de coder sans (trop !) penser au système final.
Car si j'ai tout capté, pour faire un joli son, une appli KDE va chercher Photon qui lui va chercher le "machin qui fait le son" (Xine, GStreamer, le "truc Windows")
J'ai bon ?
Donc dans ce cas, le troll Gnome/Kde est limité aux Unix ... donc il est finalement sans grand intérêt (comme beaucoup de troll !)
Il y a une vraie question dans ce commentaire ...
[^] # Re: Phonon
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
Donc, Phonon, c'est juste une factorisation de ce qui existe déjà, au niveau de KDE cette fois-ci.
[^] # Re: Phonon
Posté par clearstream . Évalué à 1.
Gstreamer = > multiplateforme (*nix / Windows / Mac OS)
Il y a peut-être d'autre framework aussi portable que Gstreamer, mais je ne les connais pas.
[^] # Re: Phonon
Posté par tene . Évalué à 2.
ah ben si, on dirait... ;) --> []
# Au secours
Posté par xavier66 . Évalué à 9.
J'avais évité de mettre le pied dedans vu que l'on tourne en rond et que finalement, je ne sais plus vraiment ce que cherche à démontrer clearstream, mais je vais essayer de faire un petit récapitulatif. (Attention, je me mets au C++/Qt mais je ne connais pas tous les boyaux de KDE/Qt, donc corrigez moi si je me trompe. Qui plus est, pas la peine de me traiter de fanboy KDE, car j'ai utilisé KDE et Gnome en alternance pendant quelques années avant de me poser chez KDE pour le moment. Je laisserai aussi le côté "KDE dénigre Gnome" et "KDE c'est ils jouent perso" de côté pour recentrer sur la technique.)
- Les développements de KDE et de QT sont intimement liés, avec une version majeure de QT précédent une version majeure de KDE. Il faudra que je me renseigne plus en avant sur ces liens ;)
- QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à http://linuxfr.org/comments/745544.html#745544 ]
- Malheureusement, rien n'est prévu dans QT4 pour le son (vu que c'est à la base un toolkit graphique quand même :p). L'idée est venue de faire l'encapsulation d'un framework multimedia pour avoir les mêmes avantages que QT pour les graphismes : stabilité d'API/ABI et syntaxe objet unifiée avec le reste (et portabilité aussi si possible).
- Vient alors la question du framework à encapsuler. L'avantage de l'encapsulation est qu'on peut fournir la même API en passant par n'importe quel backend s'il est supporté. Le fait de supporter plusieurs backends est un plus, pas le but recherché. Qui plus est, ça arrange ceux qui ont des mauvais souvenirs avec arts ;)
- Non, ce n'est pas une somme de travail immense de rajouter le support d'un backend, c'est écrire quelques fonctions de quelques lignes. Si l'API d'un backend change, il n'y a qu'à modifier ces fonctions, recompiler phonon et tout va bien. J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
- Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...), on ne parle pas de MAO et de temps réel là. Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
- Comme dit plus haut, c'est du "sucre" pour les développeurs, rien qui n'impacte directement luce et henry, à part des soucis en moins dans amarok quand gstreamer change d'API ou quand xine ne veut pas marcher avec dmix.
J'espère n'avoir pas dit trop de bêtises. Maintenant, clearstream, qu'est-ce qui te révolte tant ?
[^] # Re: Au secours
Posté par outs . Évalué à 7.
Mais le problème est qu'on est pas dans un monde parfait et monolitique. Surtout que ce n'est pas parceque KDE s'investi dans quelque chose que cela va forcement débloquer la situation (cf arts).
Donc vu la situations actuelle du son sous linux la solution choisie avec le wrapper phonon est la meilleur en attendant que les choses se décantent.
Quand cela sera fait (que cela soit Gstreamer ou autre qui s'impose) Phonon n'aura dérangé personne vus que c'est juste un peu de colle C++ entre un logiciel et KDE.
Et que de toute facon on a besoin de cette colle de toute manière dans KDE (parceque les backends sont toujours en C, parceque c'est une technique de programmation normal en objet, parceque ca permet a plein de développeur C++ de continuer a utiliser le même style de programmation, parceque ca résoud une dépendance envers des projets qui changent tous le temps, parceque ca assure la compatibilité binaire de KDE)
Voila pas la peine de lire le troll la dessus qui fait ramer mon renard de feux y'a rien a voir. (a par un discours limite insultant)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Au secours
Posté par xavier66 . Évalué à 1.
[^] # Re: Au secours
Posté par clearstream . Évalué à 5.
Il sait lire les dvd crypté (et pas encrypté).
> je n'ai toujours pas vu un truc pour le lier a dvdcss
Il utiliser un plugin (qui utiliser dvdread qui s'occupe de css)
> qu'il ne sait pas streamer
Il sait streamer.
> qu'il ne sait pas lire plein de format audio (mp3 pour le plus courrant)
Il lit plein de format audio et mp3 notament.
> comme clearstream arrete pas de faire des reproche sur KDE a cause de QT lie a trolltech
J'ai fait des reproches sur ça ? Je n'ai pas fait le moindre commentaire avec le mot "trolltech".
J'ai fait le constat que KDE était lié à Qt (comme Gnome est lié à Gtk) et que ce n'étant en rien un soucis pour eux mais qu'être lié à Gstreamer est un soucis pour eux. J'ai fait ce constat (en prenant Qt et d'autres librairies) pour "dénoncer" ce deux poids deux mesures.
Pour Gstreamer, il est très très modulaires et utilise les plugins. Très probablement tu n'as pas installé les plugins non libre.
Il y a :
gstreamer-plugin-base
gstreamer-plugin-good
gstreamer-plugin-ugly
gstreamer-plugin-bad
Voir ici :
http://gstreamer.freedesktop.org/src/
[^] # Re: Au secours
Posté par xavier66 . Évalué à 2.
[^] # Re: Au secours
Posté par clearstream . Évalué à -6.
Vérifies toi même, les libs que j'ai sité ne sont pas "wrappées" par Qt (je n'ai pas sité Xlib). Qt wrappe presque rien (vérifies toi même).
> J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
Ben si les autres s'en chargent... C'est rien comme boulot. Ils doivent bosser sur leur frameword ET sur Phonon maintenant. Pour KDE c'est que du bonheur surtout que tu dois penser que les développeurs de framework n'ont que ça a foutre.
> - Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...),
Donc tous les développements actuels sur les frameworks sont inutiles puisqu'il y a déjà tout le nécessaire selon toi.
J'imagine que quand les autres fairont mieux, tu vas te persuader que c'est inutile car t'as déjà "tout le nécessaire pour la quasi totalité des applications desktop".
> Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
Jack ne fait pas la vidéo. Gstreamer oui. Quand avec Gstreamer et une bête caméra USB à 2 sous on pourra éditer ses propres films, ajouter des commentaires ou une musique de fond en deux cliques tu vas penser que c'est inutile pour l'utilisateur moyen. Au mieux KDE offrira ça par défaut dans KDE 5. Pas avant 5 ans...
> - Comme dit plus haut, c'est du "sucre" pour les développeurs
Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
> à part des soucis en moins dans amarok quand gstreamer change d'API
Ce qui arrive tout les ans (13 mois entre 0.8 et 0.10) et le rythme va forcément décroitre. Si ton appli est simple (type une appli qui utilise Phonon), c'est l'affaire de 1 jour maximum pour passer de Gstreamer 0.8 à 0.10 et avoir plus de fonctionnalité. Avec Phonon pour avoir plus de fonctionnalité, il faut "seulement" que tu changes complètement d'API.
> Maintenant, clearstream, qu'est-ce qui te révolte tant ?
Ta naïveté.
[^] # Re: Au secours
Posté par xavier66 . Évalué à 5.
Comme d'habitude, tu ne sais parler que de gst, à croire qu'il n'y a que ça dans la vie. Pour ma part, gst devrait déjà faire ses preuves pour les besoins de base (cf les commentaires plus haut) avant de vouloir révolutionner le cinéma grand public :D
>> - Comme dit plus haut, c'est du "sucre" pour les développeurs
> Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé. L'API de phonon pourra être étendue au fil des avancées des backends, mais sera toujours sous contrôle. Et non, ce n'est pas un travail surhumain de maintenir phonon.
[^] # Re: Au secours
Posté par clearstream . Évalué à -2.
Tu parles des librairies wrappées par Qt et tu n'es même pas allez vérifier. Pourtant avec un "rpm -q --requires" ou un ldd ça se fait vite. Une ligne de commande seulement.
Je ne voulais pas répondre à ton commentaire au début. T'as demandé une réponse, je l'ai fait et voilà.
Si tu voulais du "oui, oui, oui", t'as frappé à la mauvaise.
> gst devrait déjà faire ses preuves pour les besoins de base
C'est fait, c'est utilisé par Gnome depuis plus d'un an qui n'utilise que Gstreamer.
Notes que Phonon n'a toujours pas fait ses preuves...
> cf les commentaires plus haut
Apparament la personne a oublié d'ajouter des plugins. Si elle ne veut pas se renseigner avant d'utiliser quelque chose, Gstreamer n'y est pour rien. Les modules sont à un click de la page d'accueil du site de Gstreamer.
Tu crois que Gstreamer ne supporte pas mp3 car quelqu'un le dit ?
Mp3 est supporté par Gstreamer depuis la nuit des temps.
Tu crois que Gstreamer ne supporte pas le réseau car quelqu'un le dit ?
Gstreamer support tcp, udp, gnomevfs (il ne tient qu'à KDE de faire l'équivalent), et rtp*. Un exemple qu'il y a plus d'un an :
http://linuxfr.org/comments/581662.html#581662
Rhythmbox qui utilise gstreamer permet d'écouter la radio sur internet et rtp* pour les videos real.
Tu crois que Gstreamer ne supporte pas les DVD car quelqu'un le dit ?
Gstreamer supporte les dvds cryptés ou pas depuis longtemps. A vu de nez peut-être depuis au moins 2 ans.
T'es un peu naïf.
Sur ma bécane, j'ai 82 modules offrant 487 fonctionnalités. Il manque principalement le support pour dvb.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Le développeur est enchaîné à Phonon dont l'api ne doit pas bouger durant en gros 5 ans (la durée de vie de KDE 4) et Phonon est enchaîné aux frameworks.
> L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé.
Et Arts, qui le développait ? Ce n'était pas KDE par hazard ?
Ben oui. On a vu ce que ça a donné.
Ce n'est pas parce que KDE fait quelque chose que c'est forcément parfait ou mieux que les autres.
> L'API de phonon pourra être étendue au fil des avancées des backends
Des extensions seulement. Si une fonctionnalité casse la compatibilité, il faudra attendre KDE 5 (au moins 5 ans).
Et si personne veut étendre Phonon comme c'est arrivé avec Arts ?
Je répète, ce n'est pas parce que KDE gère le projet que tout est forcément rose.
> mais sera toujours sous contrôle.
Super.
Comme ce n'est fait que pour le framework multimédia, je peux en conclure que tout le reste n'est pas sous contrôle.
> Et non, ce n'est pas un travail surhumain de maintenir phonon.
Arts non plus ce n'était pas un travail surhumain.
[^] # Re: Au secours
Posté par Moonz . Évalué à 9.
Si j'ai bien tout compris, phonon, ça va être en gros: void playSound(QString path). C'est vrai que c'est une dispersion d'efforts honteuse. En plus, KDE prennent du code que pour eux, regarde, ça dépend de Qt (QString). Honteux vraiment, le logiciel libre, c'était mieux à vent. Ça va sûrement finir comme Arts, inmaintenu car le code est trop gruik.
Alors d'accord, on peu reprocher à KDE d'avoir fait beaucoup de bruit pour pas grand chose, mais c'est pas une raison pour crier encore plus fort et pour d'encore moins bonnes raisons.
Et insulte moi autant que tu veux, profites en, parce que je répondrais pas. À moins que ta réponse soit constructive (et que ce ne soit pas une n-ième tentative de faire croire que tu n'as pas compris), mais je suis plutôt sceptique là dessus
Ça fait du bien :)
[^] # Re: Au secours
Posté par clearstream . Évalué à 2.
http://linuxfr.org/comments/746145,1.html
Certe, je n'étais pas obligé et ton commentaire n'est pas "inspiré" uniquement par ce dernier thread.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.