> ne se fera pas assimiler par les borgs marketing (l'inclusion de Mono est peut être un symptôme inquiétant)
Des applis mono seront intégrées à Gnome. Pourquoi le refuser s'il n'y a maintenant plus de problème (résolu avec ION) et que ce sont de bonnes applis ?
Tu voudrais aussi supprimer Samba ?
Mono a dans Gnome la même place que Java ou Python. D'ailleurs ces derniers on plus de place car leurs bindings sont plus complets.
La place de Mono dans Gnome c'est des bindings et des applis. C'est tout. Idem pour les autres languages. Par exemple libgnomevfs ne sera jamais écrit en C#. Mono a un binding qui attaque libgnomevfs (comme python et d'autre language).
Jamais pour écrire une applie Gnome, il ne sera nécessaire d'utiliser C#. Toute appli C# pourra être recodé en C ou C++ ou python ou autre si quelqu'un s'en donne la peine. Mais si l'appli existe et quelle rend service, je ne vois pas pourquoi s'en priver.
Puis KDE a aussi un binding en cour de développement pour C#.
Je n'utilise pas Mono. Mais puisque maintenant Mono ne pose pas de problème, je ne vois pas pourquoi il faut continuer cette "chasse aux sorcières".
C'est effectivement un point sérieux. Je n'arrive pas encore à me forger un avis.
L'article est particuliairement intéressant et les commentaires aussi :
The goal is to have a framework for using various DRM systems with the GStreamer framework without interfering with the way GStreamer currently works.
[...]
The DRM work has included a lot of thinking on our part about the implications and I think its safe to say that we love DRM as little as everyone else. On the other hand we have also seen that a lot of doors get closed on us, GStreamer and GNU/Linux due to lack of DRM support, which means people in those cases go with a Windows based solution instead. Which of course is no win for free software.
On the other side there is the question on how far you should go in trying to accomodate people too and I am sure many in the community feels that any sort of DRM support is going too far.
[...]
The only group out there with the power to shut down DRM are the consumers, they need to revolt at the idea and stop buying music and movies which are using DRM. What we as a technology provider can do is try to move DRM usage in favour of the more userfriendly and fair systems.
Il serait bien que lorsqu'on va lire un contenu DRM, qu'une fenêtre s'ouvre et indique en quoi DRM c'est mal. Après l'utilisateur fait ce qu'il veut. Ceci ne pose aucun problème a réaliser avec le logiciel libre et est pratiquement impossible avec le logiciel propriétaire.
Si ça permet à des utilisateurs de venir de Windows ou de ne pas quitter Linux, il faut l'envisager.
> Je trouve d'ailleurs vraiment dommage que beaucoup de ces gens là soient du côté de Gnome (à cause de la LGPL de GTK, des grosses boîtes qui le soutiennent et d'Icaza entre autres), car ça ternis considérablement l'attrait que ce desktop
Ca ternis car c'est un troll bidon pour discrédité Gtk/Gnome.
Ce troll on peut aussi le faire pour Qt qui est quasi exclusivement développé par Trolltech.
> On voit déjà les prémices, avec un gnomiste ici et sur le blog que tu cites qui couinent "ohlala pourquoi ils prennent pas le standard GST par défaut"
Pour le gnomiste, je répète encore un fois que ce que je trouve abhérant, c'est Phonon. Pas que KDE ne choisisse pas Gstreamer.
C'est claire ou il faut que je le dise encore 50 fois ?
> alors que de toute façon ils n'utilisent pas KDE
Certe, mais si KDE prenait Gstreamer, ça fairait avancer le schmilblick au-lieu d'avoir 40 frameworks.
> le KDEiste moyen n'a rien à foutre de GST
Tout à fait.
> vu que Xine marche bien mieux.
Très bien. Que KDE choisisse Xine au-lieu de bouffer du temps inutilement avec Phonon.
Je ne connais pas Xine. Si Xine est mieux que Gstreamer, alors Gnome doit prendre Xine.
Il faut prendre le meilleur et pas faire un truc qui ne sert à rien.
> D'ailleurs, pourquoi Xine ne pourrait pas l'être, le fameux le standard...
Pourquoi pas. Ne connaissant pas Xine, je ne peux juger.
> Il me semble, que, de facto, Xine est bien plus utilisé que GST :þ
???
mplayer est peut-être aussi le plus utilisé. Mais il n'est pas adapté à un bureau "moderne".
> phonon fait tout le sale boulot.
Un tout tout petit bout du sale boulot. Les frameworks multimédia en font beaucoup beaucoup plus.
> Je ne vois pas ce qu'il y a de réellement polémique dans cette démarche
L'un des aspects de la polémique est, qu'alors que la globalement les développeurs de KDE considèrent Gstreamer comme le meilleur framework, ils font un truc tordu comme Phonon sans bonne raison, sauf pour pouvoir dire qu'ils ne sont pas dépendant d'un élément actuellement utilisé par Gnome.
Un autre aspect de la polémique, est que KDE a tout fait dans son coin et en a encore manifestement rien à foutre de mutualiser les efforts sur des acpects techniques d'un bureau qui n'impactent en rien l'utilisateur.
Qu'es-ce que ça change pour l'utilisateur de KDE si son appli KDE préférée utilise Phonon ou Xine ou Gstreamer ou tartantion ? Rien.
Par contre avec Phonon, KDE érige un standard (le standard KDE) qui se limite au plus petit dénominateur commun.
Lorsque Gnome sorte des "standards" (notes bien les guillements) qui peuvent être utilisés par plusieurs bureaux, ils mettent tout sur freedesktop. Ainsi KDE, Xfce, etc peuvent en discuter et participer.
KDE ne fait jamais ça ! Tout ce que fait KDE c'est : "ben tient, on va récupérer HAL, car à développer c'est la galère".
Gstreamer existe depuis longtemps. Puis ceux qui participent à freedeskop (Gnome, xfce, KDE, etc) l'on accèpté dans freedesktop.
Certes, et comme le dit freedesktop http://freedesktop.org/wiki/Standards "These are not really standards".
Les standards ne s'imposent pas d'eux-même.
Phonon a été une surprise à deux niveaux :
1- beaucoup ne comprennent pas l'intérêt du truc.
2- décision d'un coup de le mettre dans KDE 4 et d'en faire le standard de KDE 4. D'autant plus surprenant qu'à l'époque Phonon était à peine, voire pas, fonctionnel. Le tout sans concertation avec Gstreamer ou Xine ou autre pour voir s'il était possible de respecter les objectifs de KDE 4 sans créer un nouveau machin. M'enfin, on le sais, mutualiser les efforts du logiciel libre n'est pas un soucis de KDE. A croire que le libre à 98 % du marché du desktop. Ben non, c'est Windows.
> Evolution pour "remplacer" Outlook-Exchange
C'est le même look. Utilise les deux, et tu verras que ce n'est pas la même chose.
Dans le même registre de troll il y a "Firefox pour remplacer I.E.".
> Novell-Ximian qui pousse XGL au détriment de AIGLX
Ils pensent que c'est la meilleur solution.
> supporté par les codeurs de Xorg
Et surtout supporté par Fedora ne l'oublions pas. M'enfin, la vrai place de AIGLX est Xorg et non le cadre spécifique d'une distribution. Lorsque AIGLX sera en place, il sera sur Xorg (ce qui est pratiquement déjà fait).
> pour "concurrencer Vista"...
Oui. Mais aussi Mac OS.
> Y a quand même une volonté de faire comme (mieux que ?) MS.
Ca pue le troll à plein nez.
Regardes un bureau Gnome, le menu principal est en haut à gauche. Sur Windows c'est en bas. Etc...
> Je trouve que ça serait plus sain, vu la qualité des trucs précités, de simplement chercher à faire de bonnes applis sans s'occuper d'MS
On peut dire la même chose pour KDE. C'est uniquement du troll.
> Evolution est vraiment une horrible usine à gaz
Ca marche, les utilisateurs sont contents. De plus tu ne dois pas connaitre Evolution.
> par contre des clients GTK comme Sylpheed sont vraiment intéressants
Chaqu'un ses goûts.
> XGL est un hack horrible, qui utilise deux serveurs X et casse OpenGL, pourquoi le favoriser à AIGLX ?
???
Qui le favorise. Quelle est cette autorité ?
Novell bosse actuellement sur GLX. Les deux projets GLX et AIGLX bossent assez ensemble. Voilà c'est tout. Quand AIGLX sera au point (ce qui est plus compliqué et long que GLX) je pense que Novell va passer à AIGLX.
> Faire comme/mieux qu'MS c'est se condamner à toujours avoir un métro de retard
Troll.
Tu veux dire que KDE ne va pas utiliser *GLX ?
> tout le monde connait Evolution, mais s'il n'y avait pas régulièrement des news sur Sylpheed ici...
Et ?
Je ne vois pas où tu veux en venir.
> quelle force mystérieuse pousse les Gnomistes à râler systématiquement quand KDE n'utilisent pas leurs machins.
Je répète encore un fois que ce que je trouve abhérant, c'est Phonon. Pas que KDE ne choisisse pas Gstreamer.
> Si ça se trouve, Gnome va se dire que finalement GST c'est pas super finalement
C'est possible.
> et sortir une lib similaire nommée Gazouilli qui fera la même chose
Pourquoi ? Si GST "c'est pas super finalement", se limite au plus petit dénominateur commun des frameworks multimédia ça ne sera pas plus "super finalement".
> X11 est encapsulé par Qt (tiens, il a plusieurs backends, lui !)
Comme Gstreamer (qui tourne aussi sous Windows et Mac OS) ou Xine ou NMM !
Le but de Phonon, est d'encapsuler des trucs qui encapsulent déjà et qui font la même chose ! Ces "trucs" fournissent des facilités multimédia quelques soit la plateforme (comme Phonon, d'où l'utilité douteuse de Phonon).
Ce que fait Qt (utiliser l'interface native d'un OS), X11 ne le fait pas. Si t'as déjà utilisé une applie X11 sous Windows, tu dois voir où je veux en venir.
> Je continue ?
Non, ton analogie ne tient pas.
> Si ça se retrouve dans Qt ou kdecore, c'est encapsulé.
On peut donc utiliser Gtk+ à la place de Qt comme on pourra utiliser Xine à la pas de NMM avec Phonon ?
> Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro
C'est le mode par défaut de Gnome.
> et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome.
L'histoire jugera.
> KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer
Je répète encore, ce qui m'énerve dans Phonon, ce n'est pas spécifiquement que KDE ne prenne pas Gstreamer, mais que Phonon fait une abstraction pour plusieurs frameworks et évite de se concentrer sur le vrai problème (c-à-d améliorer le framework multimédia, qu'il soit Gstreamer ou Xine ou autre).
Lis mes commentaires plus haut.
> KDE n'a pas les ressources requises pour participer
Mais KDE a les ressources pour faire Phonon...
De faire du support pour Phonon/Xine, Phonon/Gstreamer, Phonon/NMM, ...
De suivre les modifications d'ABI de Xine, Gstreamer, NMM, etc pour réajuster Phonon.
D'avoir des développeurs qui connaissent l'API de phonon, de Xine, de Gstreamer, de NMM, etc...
C'est ça qui est abhérant dans le choix de Phonon. Tous les explications de KDE ne tiennent pas la route dès qu'on y réfléchi plus de 2 secondes.
> Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..
C'est vrai et ça aide. Indéniablement.
> niveau marketing ils sont bien servis avec Ubuntu dernièrement..
Kde à Kubuntu (mais peut-être pas le support de Canonical).
> Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
Sois gentil, remplaces "ton framework multimédia" par "son framework multimédia".
C'est du libre, libre à qui veut de participer. C'est claire.
Il n'a jamais été demandé à KDE de participé à Gstreamer s'ils ne veulent pas. Simplement on (plus précisément ici moi) s'interroge sur le choix fait par KDE.
En effet, Phonon est une perte de ressources (ressources KDE selon toi si précieuses, j'en suis d'accord) sans plus-value pour l'utilisateur.
Il y a de bonnes raisons à faire une encapsulation. Par exemple avoir une API triviale pour les actions simples et gérer les changements d'API. Pourquoi pas.
Mais Phonon va le faire pour plusieurs backends.
Et tout ça pour offrir le plus petit dénominateur commun des backends.
Ces ressources précieuses n'apporterons rien au logiciel libre. Sans compter le problème du support : Quand un programme déconne, c'est qui le fautif : L'appli, Phonon, ou l'un des 3 ou 4 backends supportés ?
Faudra aussi un système pour que le périphérique donne ses caractéristiques à Phonon et au backend, etc.
D'ailleur il y a déjà NMM qui "porte" son backend pour Phonon.
KDE a des soucis légitimes de stabilité d'API. Très bien, voyons ça, trouvons une solution. Sur ma bécane j'ai gstreamer 0.8 et 0.10. Ca marche. Sous Gnome il y a esound (compatibilié sur toute la branche 2.x) et gstreamer (un peu de blinding-edge). Si esound tourne et qu'il n'y a pas dmix d'alsa, gstreamer utiliser esound. Le minimum de ressource a été utilisé et on a le maximum de souplesse. Même en pronant une ABI stable, Gnome ne s'est pas enfermé.
On peut trouver des solutions sans sortir ce "machin" de Phonon.
Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore. Forcément Gstreamer s'améliore aussi (via les corrections de ffmpeg, via une veille sur Xine, etc). Et si Xine surpasse Gstreamer, ben Gnome passera à Xine pour le bien de ses utilisateurs et on félicitera KDE pour la pertinance de son choix et Xine (voire KDE) pour la qualité du travaille. Si ça arrive durant la branche Gnome 3.X, il y aura dans Gnome 3.x, Gstreamer (compatibilité pour le bonheur des développeurs), et Xine (pour le bonheur des utilisateurs) comme il y a aujourd'hui esound et Gstreamer.
Effectivement celà est possible aussi avec Phonon. Mais avec Phonon on bouffe des ressources pour rien.
Un des principes de Phonon, est de considérer que ça merde. Les frameworks merdent car ils changent d'API, ils merdent car il faut plusieurs backends pour satisfaire l'utilisateur ou le développeur.
Je préfère que des ressources soient affectées à corriger cette merde, qu'à vivre avec.
> Pourquoi les devs KDE n'auraient pas le droit de faire leurs designs comme ils veulent
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.
> 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.
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
> 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.
Comment tu expliques que les bindings de KDE soient si peu utilisés ?
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*.
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.
> 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.
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".
Bien vu. Je me suis égaré.
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.
> Faut voir aussi le fanboysme du projet GNU sur le C.
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.
GStreamer has been ported to a wide range of operating systems, processors and compilers. This include but are not limited to Linux on i86,PPC, ARM using GCC. Solaris on x86 and SPARC using both GCC and Forte, MacOSX, Microsoft Windows using MS Visual Developer and IBM OS/400.
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.
Je crois que tu n'as pas compris ce que je reproche.
> 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.
the day that gstreamer or any other media engine provides:
* a believable API/ABI stability guarantee that covers kde4's lifespan
* an API that is easy enough to use for casual development (bonus points for fitting in nicely with KDE's API)
* availbility on every platform that KDE supports (that's more than linux; it's even more than open source platforms for that matter)
* a solid user experience
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.
> Franchement, ras-le-bol de ces gens qui passent leur temps à critiquer sur des conneries.
De toi :
- "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."
- "Les devs de Gstreamer prennent des décisions stupides, dans la tradition GNOME"
> 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.
> Encouragerais-tu les dévellopeurs de KDE de laisser tomber KDE et de dévelloper directement Gnome ?
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é.
> - utilisation de phonon comme framework multimedia
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.
> désolé de te décevoir , mais le libre c'est pas 'la gpl'.
Dommage. Mais vires de ton système tout ce qui est gpl, tu verras ce qu'il te reste.
J'ai pas envi de ma retorturer l'esprit avec la CDDL et ses trucs tordus avec "intellectual property", etc.
Si la CDDL a été autant critiqué, ce n'est pas pour rien.
Si les développeurs du libre se détournent de la licence CDDL, ce n'est pas pour rien.
> Ensuite que les différentes licences soient incompatibles (volontairement ou non)
Volontaires, assurément. Faut pas prendre les gens de Sun pour des gogos.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Ils l'ont fait ...
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -1.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -2.
L'original :
Le "Forcément, un troll" est pour "et en rajoutant de la complexité à la tâche".
[^] # Re: Ils l'ont fait ...
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Il y avait de bonnes raisons à ça.
[^] # Re: Ils l'ont fait ...
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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.
[^] # Re: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: KDE
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: Les Gnomistes m'emmerdent
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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 clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: KDE
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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é.
# Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). É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: kpartx
Posté par clearstream . En réponse au message extraire le contenu d'une image d'une clé ou disque. Évalué à 2.
# kpartx -d /dev/loop5
# losetup -d /dev/loop5
# rmdir mount_point
# rm -f head.tmp
# kpartx
Posté par clearstream . En réponse au message extraire le contenu d'une image d'une clé ou disque. Évalué à 2.
Un bon exemple (sous FC5) :
[^] # Re: Encore une opération de communication ???
Posté par clearstream . En réponse à la dépêche Un point sur Java et l'Open-Source. Évalué à -1.
Dommage. Mais vires de ton système tout ce qui est gpl, tu verras ce qu'il te reste.
J'ai pas envi de ma retorturer l'esprit avec la CDDL et ses trucs tordus avec "intellectual property", etc.
Si la CDDL a été autant critiqué, ce n'est pas pour rien.
Si les développeurs du libre se détournent de la licence CDDL, ce n'est pas pour rien.
> Ensuite que les différentes licences soient incompatibles (volontairement ou non)
Volontaires, assurément. Faut pas prendre les gens de Sun pour des gogos.