La trollosphere se déchaîne sur phonon depuis que Christian Schaller, un des auteurs de gstreamer l'a critiqué : http://blogs.gnome.org/view/uraeus/2006/05/11/0
On a droit comme d'habitude a un gros lot de commentaires de chocs niveau slashdot qui sont toujours aussi intelligents et bien argumentés :
- KDE est en train de se tirer une balle dans le pied
- phonon est une surcouche d'une surcouche déjà complexe donc ça va tout ralentir
- gstreamer assure, c'est débile de ne pas l'utiliser
et j'en passe. On est tout juste au niveau de "KDE devrait fusionner avec Gnome" et "on devrait réécrire Qt en utilisant la glib".
Heureusement, on a eu droit a quelques réponses bien argumentées des développeurs KDE :
- http://aseigo.blogspot.com/ : Aaron Seigo (développeur KDE important)
-http://grammarian.homelinux.net/~mpyne/weblog/kde/phonon-whi(...) Michael Pyne (Auteur de JUK)
- http://www.kdedevelopers.org/node/2007 Scott Wheeler (auteur de Amarok)
A noter que ces deux derniers ont fait des bindings gstreamer pour KDE et travaillent tous les deux sur des applications musicales. Ils font donc partie des rares personnes qui savent de quoi elles parlent quand le sujet est évoqué. Je trouve leurs arguments techniques tout à fait convaincants sur les raisons d'existence de phonon. J'ai du mal à imaginer qu'on puisse les lire et continuer à affirmer que "KDE devrait utiliser gstreamer comme Gnome" sans être de mauvais foi.
Pour les flemmards, les arguments qui m'ont le plus marqué :
- que faire sur les plate-formes où gstreamer ne tourne pas ?
On pourrait imaginer que les applications détectent si gstreamer est présent et l'utilisent et sinon utilisent l'autre moteur multimedia disponible. C'est exactement ce que va faire phonon
- KDE 3 a duré à peu près 3 ans sans changement binaires incompatibles. Pour KDE 4, on espère faire beaucoup mieux. En 3 ans, non seulement la compatibilité binaire de gstreamer a été cassée 3 fois, mais en plus, l'API a évolué de façon importante de sorte qu'il est difficile de maintenir facilement une application l'utilisant. Si KDE choisissait une version de gstreamer, il serait obligé de faire un fork pour garder une vieille version compatible pendant que le reste de gstreamer continuerait à évoluer et que KDE ne pourrait pas en tirer partie.
- l'API de gstreamer est complexe est mal adaptée aux besoins raisonnablement simple des auteurs d'application de KDE. Me vient à l'esprit le fameux "Bonhomme Patate".
Mais j'en viens au coeur de mon journal. En lisant tout ça, j'ai eu une forte impression de déjà vu. Certes, beaucoup de "batailles au lance-flamme" se ressemblent mais vraiment, ça dépassait la simple familiarité.
Alors l'éclair m'est venu. Remplacez gstreamer par Corba, phonon par DCOP et KDE 4 par KDE 2 et on se retrouve quelques années en arrière. Tout y est :
- les commentaires façon slashdot de ceux qui n'ont pas la moindre idée de ce dont ils parlent.
- les "KDE va mourir s'il fait ce choix-là"
- le mépris de l'expérience des développeurs de KDE qui ont utilisé gstreamer de façon approfondie mais "qui n'ont rien compris à tout ce que gstreamer peut apporter".
- les "vous n'arriverez jamais à maintenir [ une API multimedia / un framework de communication inter-processus ] à vous tout seul, c'est beaucoup trop compliqué.
- les "ça ne sert à rien de faire [ de la communication inter-procesus / une API multimedia ] si vous n'avez pas toutes les fonctionnalités de [ Corba / du moteur multimedia sous-jacent ] :
Au final, je prédis exactement le même sort à phonon qu'à DCOP. Regardons la situation présente de DCOP vs Corba :
- la complexité de Corba a rendu le développement de bonobo long et difficile.
- très peu d'applications Gnomes utilisent au final bonobo
- Gnome a pratiquement renoncé à cette technologie
- la légèreté de DCOP a fait qu'il a été facilement maintenu et qu'il est devenu très populaire
- toutes les applications KDE supportent DCOP et beaucoup en tirent avantage : il suffit de lancer kdcop sous KDE pour le voir et de jouer avec dcop pour faire des trucs sympa
- DCOP a tellement bien marché qu'il a donné naissance à DBUS, le même principe mais avec moins de dépendances et fonctionnant dans un contexte plus large que un environnement de bureau.
Donc ma prédiction :
- phonon sera léger et maintenu
- il sera vite populaire et toutes les applications KDE l'utiliseront avec plaisir
- le problème qu'il résout continuera de se poser et au final, freedesktop adoptera ou développera une technologie extrèmement similaire en bénéficiant de l'expérience de phonon.
Rendez-vous en 2009 pour le résultat des courses. A noter que je suis prêt à prendre des paris.
Journal Phonon et gstreamer : un voyage dans le temps
12
mai
2006
# Ce qui est dommage
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: Ce qui est dommage
Posté par Nicolas Schoonbroodt . Évalué à 10.
C'est comme ça que l'informatique fonctionne : (c'est schématique, il est tard)
En bas tu as des transistors, tu peux les controller en leur envoyant des signaux électriques sur pleins d'entrées. Mais c'est pas pratique. Alors on laisse cela aux spécialistes.
Les spécialistes ils prennent beaucoup de transistors, et ils t'en font des ALU, de la RAM, ... qui sont des choses avec moins d'entrées, moins de sorties, de plus haut niveau, ... Mais c'est toujours dur, alors on laisse les spécialistes s'en occuper.
Les spécialistes, ils prennentce composants, et ils écrivent un OS. Ca permet de diriger ce qu'il y a en dessous à partir d'un nombre assez restreint d'opérations. Mais c'est toujours compliqué, ...
etc, etc,
Un ordinateur est un empilement de couches, et ça marche comme cela depuis un moment. Les couches ne sont pas là pour allourdir le système, et si elles le font, c'est pour faciliter la vie de l'utilisateur de la couche supérieure. Gnome et KDE, ce sont avant tout des frameworks de dévellopement, te permettant de réaliser une application en te concentrant le plus possible sur la couche métier de ton application. De plus, grâce à cela, il est possible que ton application soit portable, sans faire le moindre effort, si ce n'est utiliser uniquement des fonctions définies dans la dernière couche (modulo bien sur le fait que la couche choisie ait été porté sur plusieurs architecture)
Enfin, tout ça pour dire que personnelementje ne trouve pas nécessairement cela dommage ;-)
Ensuite, sur la question de la performance, je ne sais pas, phonon par exemple est sencé être uniquement de la colle entre l'appli est un backend. La suite n'est qu'une imaginationde ma part, mais me semble plausible :
Le backend et phonon n'ont certainement pas trop de différence de fonctions (je ne connait pas bien le domaine, mais les différents backend sonores doivent se ressembler au niveau des fonctions présentées dans leurs API. Phonon devrait donc présenter aussi la même structure. Supposont que le BE a ait une fonction play(FILE *fichier) et le BE b une fonction joueFichier(char *cheminFichier). PhononFrontend présentera une fonction joue(QString chemin)
De plus, la classe PhononFrontend aura un attribut private PhononBackend pbe, possédent une méthode joue(QString chemin). Bien sur, on a
PhononFrontend::joue(QString chemin) {
pbe.joue(chemin)
}
A l'initialisation de l'appli (ou à l'initialisation du son) le backend (pbe) est initialisé. Cela ne prend pas beaucoup plus de temps que d'initialiser uniquement le backend a ou b.
Ensuite, à l'appel de joue(), on a en plus :
dans le cas du BE a : l'appel à la fonction délégée, un open(chemin), et un appel à la fonction du backend (le open aurait de toute façon du être appelé)
dans le cas b, l'appel à la fonction déléguée et l'appel à la fonction du BE.
Bien sur, le mapping phonon-backend est certainement légèrement plus compliqué, mais ce qu'il faut voir, c'est que le traitement d'un flux audio (lecture, décodage) est certainement _beaucoup_ plus lourd que la délégation de quelque fonction d'adaptateur.
Enfin, voila, c'est mon impression, j'ai peut-être tout faux.
[^] # Re: Ce qui est dommage
Posté par Guillaume Knispel . Évalué à 8.
Tout simplement chaque couche a un coût, et pas qu'en temps CPU. Les ordinateurs souffrent de plus en plus des temps de chargement de par l'empilement, et cela ne va ni n'ira pas en s'arrangeant. Et qui dit temps de chargement dit aussi que l'objet chargé ira résidé en mémoire vive, d'où empreinte plus large, et incapacité d'utiliser de vieux ordinateurs. Le paradoxe actuel est que les ordinateurs vont beaucoup moins vite à executer les actions (de l'utilisateur) les plus basiques qu'auparavent alors qu'ils sont inifiniments plus puissant. La contrepartie et qu'il sont maintenant aussi capable d'effectuer des actions beaucoup moins basique, et même dans de bonne condition s'il s'agit principalement d'utiliser des processeurs et de la mémoire vive... (au contraire de charger toujours plus de fichiers a partir d'un disque dur qui ne seek pas du tout plus vite qu'avant)
Reste que les couches ont quelquefois un avantage incontestable, notemment bien sûr en matière de compatibilité.
Mais il est rare de ne pouvoir faire plus léger que ce dont on dispose actuellement (quoiqu'il existe encore quelques logiciel fort bien conçu en la matière, et les seuls que je connaisse qui rentrent dans cette catégorie sont libres (bon ok je connais très peu de logiciels proprio c'est de la triche) :)
Mais globalement je persiste, Gnome et KDE deviennent bloatted.
ex1: Chacun y va de son VFS alors que c'est plutôt (à priori) du domaine de l'OS (bien entendu de tels environements se voulant portable, il n'est pas vraiment envisageable de procéder autrement tout en atteignant les mêmes fonctionnalités, sauf que en se faisant on crée une distortion avec le comportement des applications native, distortion qu'on peut selon les goûts trouver tout aussi déplacée que l'absence de portabilité)
ex2: L'empilement des couches en matière de rendu graphique (en particulier d'affichage des polices) donne un résultat extrèmement lent.
Bref il s'agit du problème classique de choix entre légereté et fonctionnalités, l'évolution du monde informatique faisant que fatalement les logiciels se complexifient.
Sauf qu'on ne sait pas réellement actuellement créer des architectures logicielles telles que l'utilisateur ne paye que pour ce qu'il utilise. Ce qui veut dire que pour qu'une couche soit adaptée à une situation, il faut qu'elle soit utile dans le cas moyen, que ce qu'elle aporte soit supérieur en terme de valeur percu par l'utilisateur aux ressources qu'elle consomme. Étant peu enclain à changer régulièrement d'ordinateur et aimant les environements (a peu près) légers, je n'aime donc pas trop que l'empilement de couche se fasse à une vitesse trop élevée. Mais jaccepte tout à fait que certain apprécient les fonctionnalités que ca leur apporte s'ils s'en servent réellement au quotidien.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Idem pour le serveur de son... Chaque aplication doit avoir son backend (oss, alsa, arts, esd...) alors qu'en tant que simple utilisateur, on demande juste à pouvoir entendre le son ! C'est tellement le bordel que ce n'est pas intégré dans ssh. Je ne sais pas pour vous, mais l'unification du protocole X est vraiment une merveille pour tous les UNIX depuis DES ANNEES. Il suffit de faire un ssh -X pour ne plus pouvoir s'en passer. Ecouter du son sur une machine distante est bien plus complexe, tellement complexe que bien peu l'utilise.
Heureusement, freedestop essaye de mettre pas mal de chose à plat. Cependant, cela prend pas mal de temps à se mettre en place. Le son serait plus compliqué que l'affichage graphique ? Je trouve dommage cette dépense d'énergie dans les deux environnements gnome et kde qui pourrait être bien plus bénéfique pour tous si elle était faite de manière communautaire comme X-Windows.
A ma décharge, je n'y connais pas grand chose en multi-média. Je suis un utilisateur plus que lambda. Mes propos sont peut être un amas de bétises.
[^] # Re: Ce qui est dommage
Posté par oops (site web personnel) . Évalué à 2.
>développeurs feraient mieux de travailler sur fuse sous linux et quelque
>chose d'équivalent sous les BSD...
Fuse fonctionne pour FreeBSD apparement :
http://fuse.sourceforge.net/wiki/index.php/OperatingSystems
[^] # Re: Ce qui est dommage
Posté par Ph Husson (site web personnel) . Évalué à 2.
Tu critique "l'unification" (au sein du DE quoi) faite pas le VFS KDE ou GNOME,
Et après tu critique l'in-unification des systèmes de sons (qui n'est vrai sous KDE que parce que arts est mouru)
[^] # Re: Ce qui est dommage
Posté par Anonyme . Évalué à 3.
Le problème des systèmes de sons est l'exclusivité sur le périphérique : en gros, impossible de lire de l'audio avec arts si esd occupe déjà la carte son.
Alors que le fait d'utiliser KDE ne t'empêche pas d'utiliser des applis GNOME.
Dans un cas "l'unification" n'est pas fondamentale : l'utilisation de l'un n'exclue pas l'autre, alors que dans l'autre cas, tu as une exclusion et c'est carément pénible.
(note : SVP passez moi des aoss, esddsp et artsdsp, c'est vraiment pas ce que j'appelle une solution)
[^] # Re: Ce qui est dommage
Posté par Ph Husson (site web personnel) . Évalué à 2.
Moi je parle plutot dans un cadre technique plus large(et l'argumentation de sytoka est largement plus valable)
Sinon si tu veux utiliser esd et artsd un coup de dmix (qui est activé par défaut maintenant parait il)
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
le VFS de gnome et celui de kde ne sont pas compatibles et ne sont pas utilsables par des applications tierces. Ce n'est au "framework" utilisateur de faire ce genre de chose. Par exemple, "vi" sais-t-il utiliser les url kde du type fish:// ? Bref, ces VFS sont des doublons qui enferment les utilsateurs dans l'un ou l'autre des environnements. Fuse au contraire, malgré des défauts, à l'avantage de s'ouvrir à tous et d'enfermer personne. Bref, je pense que les développeurs des VFS de gnome et de kde devraient mieux travailler sur une couche de plus bas niveau qui puisse servir a TOUS les programmes de manière transparente (je ne veux pas de gconfd, oaf, kdeinit... lorsque je lance vi ou latex !).
Pour la partie son, je ne suis pas sur qu'esd soit beaucoup mieux qu'arts. J'ai l'impression que jackd est de plus en plus utilisé ! Tout cela n'est en rien lié au serveur X. Pourtant, il est logique que le son suive par défaut la même route que X.
Bref, je ne critique pas le fait d'unifié les systèmes, je critique le fait que gnome et kde ont par le passé unifié leur système respectif mais par la même un peu exclu le reste. Compte le nombre de fois ou sur dlfp des personnes ont réclamés un version équivalente gnome d'un logiciel kde et réciproquement. Personnellement, je me fiche pas mal de l'aspect bureau unifié pour le look des applications que j'utilise mais j'en ai un peu marre, il est vrai, que gnome et kde cherchent à m'enfermer sur leur bureau.
[^] # Re: Ce qui est dommage
Posté par Ph Husson (site web personnel) . Évalué à 5.
Bon par contre petites rectification/ajouts
Le but de GNOME/KDE c'est d'être portable, donc comme un driver fuse c'est pas ce qu'il y a de plus portable (et surtout que ca existait pas à l'epoque ! et loin de la)
sinon pour vi avec fish oui :)
Y a différents moyens, de mémoire on peut faire un vim ssh://blabla (ou quelque chose du genre), ou aussi kioexec vim fish://chezmoi/blabla (avec l'enregistrement quand vim quitte, et il demande si tu veux envoyer la version modifiée))
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . Évalué à 2.
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway
Et donc, tu peux utilsier tous les ioslave KDE sous bash.
Dans la pratique, ce n'est pas tres pratique donc pas tres utilise.
Il y a eu une enfilade de deux mois sur un VFS commun entre Gnome et KDE sur la liste freedesktop. Pour resumer, le VFS de Gnome est moins mature a l'heure actuelle que celui de KDE (bien qu'il semble y avoir des trucs plus interessants sous certains aspects) et il y a enormement de problemes techniques pour la realisation.
Ensuite viendrait la question de ce qui pourrait pousser une desktop comme KDE qui a une solution robuste et eprouvee depuis maintenant 5 ans pour passer a un truc inferieur (moins de ioslave que sous KDE) et mal teste. Ca arrivera surement mais ce ne se fera pas simplement.
J'avais tendance a penser comme toi mais en fait, l'experience montre que c'est la voie naturelle. Tu ne peux pas commencer a prevoir l'integration dans un autre environnement que le tien tant que tu n'as pas essaye la solution d'abord chez toi.
Pour le coup des framework VFS, Gnome est arrive tres en retard sur KDE et a fait un truc different, avec des URLs incompatibles avec celle de KDE.
Si on prend l'exemple de DCOP et DBUS, la situation est relativemetn similaire. D'abord on valide une solution qui marche (DCOP) puis on derive qq chose qui va plus loin (DBUS). Si tu essayes de faire DBUS du premier coup, tu n'y arrveras jamais.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
D'un coté, on a un bus orienté bureau avec un savoir faire pas énorme à l'époque. De l'autre, on a affaire a des systèmes de fichiers distribués. NFS, Samba... ce ne sont pas des trucs qui n'existaient pas en 2000 ! Ca marchait déjà très bien.
Au niveau des automounteurs, il y avait déjà autofs et amd qui marchaient aussi + ou - bien. Mais enfin, ils sont utilisés en production depuis des années.
Tout ca pour dire qu'il y a une base de personnes très compétentes en systèmes de fichiers qui auraient pu se pencher la dessus plutôt que de construire des trucs très liés au environnement de bureau.
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . Évalué à 4.
Utilise une telle API pour des lecteurs qui peuvent etre tres lent, ou la connection peut carrement etre perdue a tout moment donne un tres mauvais resultat. Des que tu as une operation lente, il veut mieux la faire de facon asynchrone et garder la main sur la partie visuelle de l'application, en proposant un dialogue permettant d'arreter immediatement l'operation en cours.
Si tu as deja utilise un disque dur foireux ou tu fais un ls et tu attends deux minutes sans rien pouvoir faire, tu as une idee de ce que peut etre la latence sur un systeme de fichier monte a distance : super penible.
En fait, tu ne peux pas concevoir une application qui travaille sur un systeme de fichier ayant des caracteristiques reseau (latence, perte de connection) sans integrer ce parametre dans ton application.
Donc les fuse-ioslave, ca peut resoudre qqs problemes pratiques mais ce n'est pas la panacee.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ensuite sur la latence, NFS marchait très bien sur des hub a 10Mb il y a 10 ans. Donc pas besoin d'avoir un réseau gigabit (même si c'est mieux). Toujours avec NFS, il y a une option async pour être en asynchrone et une option intr pour que la connection ne soit pas bloquante. On peux certes mieux faire et c'est justement là ou c'est dommage, car la plupart des développeurs de gnome-vfs et de kio ont, j'en suis sur, des compétences pointus en informatique pour faire ce genre de chose.
Il y a aussi plan9 qui a l'air de faire tout un tas de chose sympathique...
Bref, les API systèmes ne demandent qu'a être améliorer si on arrive effectivement avec quelque chose de cohérent.
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . Évalué à 2.
Donc au final, c'est l'application qui doit s'adapter et tu perds l'avantage de la transparence du systeme. Sous KDE, toutes les applications sont deja adaptees a ces problemes. Et KDE n'a eu besoin de demander l'autorisation de personne (Linus, ...) pour le mettre en place et le tester.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Bref, ta vision est une vision un peu égoiste des choses. Et comme je l'ai dis plus haut, on peut très bien monter un système de fichier nfs en asynchrone.
Moi ce que je vois, c'est qu'une partie des personnes de kde et de gnome ont pour objectif d'enfermer les utilisateurs dans leur environnement. Moi, cela ne me gène pas d'utiliser une application kde avec une application gnome au coté d'un bon vieux gv qui a une interface pas du tout gnome ou kde mais qui est, à mon sens, pas égalé pour lire des fichiers postscripts.
[^] # Re: Ce qui est dommage
Posté par wahnby . Évalué à 3.
Le mieux serai d'avoir un vfs utilisateur unifié et indépendant des libs haut niveau, car pour l'instant les applic gnome et kde utilise leur vfs respectif et les autres en utilisent souvent aucun.
Pour le son je suis d'accord, 50 mixeurs diférénts ça sert a rien surtout que alsa mixe tres bien tout seul avec dmix.
je suis pas un utilisateur lambda, je suis un dev, mais je dit peut etre des conneries
[^] # Re: Ce qui est dommage
Posté par Anonyme . Évalué à 4.
Et tu fait comment pour profiter des super features en ligne de commande ? Fuse est génial car les applications pas mises a jour peuvent en profiter.
D'une manière générale, plus la transparence est profonde dans le système, plus on peut considérer les fonctionnalités apportées comme propre. Mais il y a un revers : il faut que cette ajout de fonctionnalité ne corrompe pas ni l'architecture ni la sémantique d'une API, et c'est une des raisons pour lequelles FUSE a mis tant de temps a être intégré au noyau.
Et si tu doute encore de celà, pose toi la question des loop devices pour monter des systèmes de fichiers stockés dans un fichier et non un disque : c'est exactement ce que fait FUSE (dans l'esprit hein, l'architecture n'a strictement rien a voir), mais limité aux systèmes de fichiers.
Enfin pour conclure : des VFS gérés par des librairies et qui du coup ne fonctionnent que dans des GUI Gnome et KDE, franchement je les utiliserais qu'a l'occasion, et jamais au grand jamais je prendrais l'habitude de me reposer dessus. Alors que FUSE ...
[^] # Re: Ce qui est dommage
Posté par gnumdk (site web personnel) . Évalué à 1.
>système, plus on peut considérer les fonctionnalités apportées comme
>propre.
Sauf que à l'heure actuel, nos noyau Unix (bsd, linux, ...) sont sales! Donc non je ne veux pas d'un systeme de fichier ssh en kernel space... Idem pour samba... idem pour...
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
- une gestion par le noyau
- une gestion par bibliothèque
La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.
La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.
Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.
Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.
Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.
Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)
[^] # Re: Ce qui est dommage
Posté par gnumdk (site web personnel) . Évalué à 1.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
La partie kernel space est donc juste une interface. Le plus gros problème est donc le passage d'un mode à l'autre qui grève les performances. C'est pour cela qu'il y a un nouveau système de fichier dans les derniers noyaux (je ne me souviens plus de son nom) pour améliorer tout cela.
[^] # Re: Ce qui est dommage
Posté par wahnby . Évalué à 0.
[^] # Re: Ce qui est dommage
Posté par Guillaume Knispel . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce qui est dommage
Posté par Croconux . Évalué à 8.
Mais ils sont aussi infiniment plus faciles à programmer aussi. Si tu es près à revenir au bon vieux temps de la programmation en assembleur, à ne pas utiliser des bibliothèque mais à recoder toi même juste la fonction dont tu as besoin dans ton appli, etc vas-y, fonce. Pour moi c'est non. Pouvoir programmer avec des frameworks propres, complets et évolutifs dans des langages de haut niveau permet de gagner du temps et de se concentrer sur son appli et pas sur "comment je fait pour envoyer une IRQ machin à la carte son". Les machines de bureau passent de toutes façon le plus clair de leur temps en idle.
Mais globalement je persiste, Gnome et KDE deviennent bloatted.
Tu as des mesures à l'appui ou c'est juste une impression ? L'équipe de KDE a plutot amélioré les choses depuis KDE3. Je n'ai plus le lien sur les mesures qui avaient été faites mais c'était assez significatif. Idem pour Gnome. Le plus dur est souvent de comprendre ce que les utilisateurs trouvent "lent". On entend dire "machin est lent" mais qu'est-ce qui est lent exactement ? A ce propos les slides Federico Mena-Quintero sont intéressants : http://primates.ximian.com/~federico/docs/2005-GNOME-Summit/(...) Souvent les utilisateurs se plaignent de lenteur alors que le CPU/GPU est loin d'être à 100%. C'est plutot la réactivité qui pose problème. L'utilisateur ne fait rien de sa machine 99% du temps mais quand il clique sur une bouton il s'attend à ce que quelque chose s'affiche à l'ecran dans la miliseconde. Ce n'est même pas le temps de traitement des taches qui gêne, c'est juste que la fenêtre n'apparait pas instantanément. La taille du framework derrière ne change pas grand chose. Il suffit de ne charger que le strict minimum lorsque l'action est déclenchée et de charger le reste en tache de fond, un peu comme Windows qui démarre soit disant plus vite mais qui en fait affiche rapidement l'invite de login mais continue à se charger en arrière plan. Peu d'utilisateurs se loguent et commencent à bosser dans le 1/4 de seconde mais ils se plaignent que leur machine est longue à démarrer donc on leur fait croire qu'elle est plus rapide. Bien sur s'ils se loguent tout de suite est tentent de bosser ils vont se rendre compte que la machine rame comme la mort parce qu'elle mouline encore sans le montrer mais comme personne ne le fait tout le monde est content.
[^] # Re: Ce qui est dommage
Posté par Juke (site web personnel) . Évalué à 3.
[^] # Re: Ce qui est dommage
Posté par herodiade . Évalué à 4.
Bref, c'est le prix à payer pour que les utilisateurs non occidentaux puissent utiliser Linux dans leur langue (si ça peut aider à faire passer la pillule ;).
(ps: et pour l'ex1: fuse n'a été intégré dans le noyau linux - et, au fait, seulement linux - que très récement, donc l'os ne pouvait pas founir ce service à l'époque de l'intégration systèmatique de gnome-vfs et kioslave).
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> systèmatique de gnome-vfs et kioslave
Sauf qu'on pouvait à l'époque mettre toute l'énergie disponible à construire une API propre (en gros Fuse) plutôt que de développer deux solutions transitoires.
Personnellement, j'utilise Linux depuis 10 ans tous les jours et je ne me suis quasiment jamais servis ni de l'un ni de l'autre. Ne pas les avoir n'aurait en aucune façon modifier mon utilisation de Linux.
[^] # Re: Ce qui est dommage
Posté par Narishma Jahar . Évalué à 3.
Sinon, il existe un kioslave qui s'appelle fuse_kio et qui permet de monter les ioslaves de KDE pour qu'ils soient accessibles à n'importe quelle application.
[^] # Re: Ce qui est dommage
Posté par tipote . Évalué à 10.
Je ne suis pas sûr que ce soit le point le plus important dans la complexité du rendu des polices. À mon avis, le rendu graphique des caractères est la partie lourde du traitement :
Il y a quelques années n'existaient que les polices "bitmap" : chaque caractère dans la police est représenté par une image d'un taille et d'une résolution fixées par avance. C'est super rapide à afficher à l'écran. Par contre, c'est très peu flexible, car on ne peut utiliser que les tailles dont on dispose réellement. Regardez par exemple dans /usr/X11/lib/X11/fonts (avec des variantes selon les distributions). Vous allez normalement trouver entre autres deux répertoires intitulés '100dpi' et '75dpi', contenant ces polices bitmap. Par exemple, j'ai :
courB08-ISO8859-10.pcf.gz
courB08-ISO8859-13.pcf.gz
courB08-ISO8859-14.pcf.gz
courB08-ISO8859-15.pcf.gz
courB08-ISO8859-1.pcf.gz
courB08-ISO8859-2.pcf.gz
courB08-ISO8859-3.pcf.gz
courB08-ISO8859-4.pcf.gz
courB08-ISO8859-9.pcf.gz
courB08.pcf.gz
C'est donc une police Courier, disponible en 100dpi et 75 dpi, et dans les tailles 1,2,3,4,9,10,13,14,15 et c'est tout.
Ce genre de polices est utilisé dans les terminaux Linux (tty), ou encore dans Xterm.
À côté de ça, on a des polices vectorielles, dont les "TrueType", "Type1", ou encore "OpenType". Ici, chaque caractère est enregistré sous formes vectorielle, donc peut être utilisé théoriquement pour n'importe quelle taille avec une "simple" mise à l'échelle. C'est très bien pour les imprimantes qui disposent d'une très bonne résolution, mais c'est beaucoup plus délicat quand on considère le rendu sur écran avec nos chers pixels.
Pour avoir quelque chose de correct, on ajoute de l' "antialiasing", ou lissage, qui consiste à utiliser des dégradés de couleurs au lieu de transitions brutes de la couleur de fond vers la couleur du caractère. Au départ, cet antialiasing était aussi relativement simple : un caractère en noir serait représenté avec des légers dégradés de gris. Mais, on peut faire mieux avec le 'subpixel antialiasing' : cette fois, le dégradé peut utiliser d'autres couleurs si nécessaire. C'est ce que Microsoft appelle le lissage "ClearType" sous Windows. Sous KDE, c'est traduit par "halo de sous-pixellisation".
Enfin, il est utile d'utiliser une étape de 'hinting' qui consiste à déformer légèrement le caractère pour que les lignes verticales et horizontales soient alignées sur les pixels de l'écran. Ceci rend le caractère plus net.
Pour expliquer cela, voici quelques copies d'écran grossies 3 fois :
Pas d' "antialiasing", pas de "hinting" :
http://tipote.free.fr/lissage/images/rien.png
Avec "subpixel antialiasing", pas de "hinting" :
http://tipote.free.fr/lissage/images/subpixel.png
Avec "subpixel antialiasing" et "hinting" :
http://tipote.free.fr/lissage/images/subpixel_hinting.png
Qui voudrait abandonner l'antialiasing et le hinting après avoir vu ça, hein ?
Toutes ces opération nécessitent d'analyser le dessin du caractère, et ça prend du temps, beaucoup de temps ! En tenant compte du nombre de caractères actuellement affichés dans ce commentaire, vous comprendrez que votre CPU a du bien travailler ! (eh oui, je dis bien CPU, parce que le 'subpixel antialiasing' n'est actuellement accéléré par aucune carte graphique à ma connaissance.)
Ajoutons à ça que de plus en plus de choses en dehors des polices de caractères sont "antialiasées" dans nos bureaux aujourd'hui. La librairie graphique Cairo en est l'exemple par excellence. Elle intègre maintenant gtk+2 et améliore considérablement le rendu de certains widgets comme le sélecteur de couleur. Les moteurs de thème l'utiliseront bientôt (gtk-engines 2.7 a été réécrit sur Cairo). Firefox 2 devrait utiliser Cairo également (ceci dit Firefox doit déjà profiter de l'antialiasing dans une certaine mesure avec son moteur actuel). Un dernier exemple de ces techniques d'antialiasing et de 'hinting' appliqué au tracé de graphes scientifiques : j'ai récemment écrit un nouveau terminal interactif et multiplateforme grâce à Cairo (ce que je n'aurais jamais pu faire sans cette "couche supplémentaire") pour gnuplot. Comparez vous-même le rendu sous ce nouveau terminal avec le terminal X11 original :
http://tipote.free.fr/wxt19.png
Encore une fois, qui voudrait retourner en arrière maintenant qu'on a ces librairies puissantes et faciles d'utilisation, même si la responsivité en a pâti un peu ? Nul doute que des optimisations comme le travail de Federico Mena-Quintero ( http://primates.ximian.com/~federico/news.html ) viendront améliorer tout ça.
P.S. : En plus, certaines algorithmes associés aux polices TrueType et destinés à faciliter ce traitement sous soumis à un brevet [1] , ce qui fait que la librairie FreeType [2] utilise dans la plupart des distributions une implémentation alternative, mais sub-optimale.
[1] http://www.freetype.org/patents.html
[2] http://www.freetype.org
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: Ce qui est dommage
Posté par Michel Pastor . Évalué à 2.
http://linuxfr.org/~tipote/21524.html
# Petite correction
Posté par Michaël Larouche . Évalué à 9.
Juste une petite correction sur un truc qui m'a dérangé quand j'ai lu ce journal ;)
# durée de vie de KDE.
Posté par Gof (site web personnel) . Évalué à 8.
> incompatibles. Pour KDE 4, on espère faire beaucoup mieux.
Il a duré bien plus.
KDE 3.0 est sortit en avril 2002 et KDE 4 ne sortira objectivement pas avant 2007
Si je calcule bien, ça fait presque 5 ans.
C'est donc pas mal
À titre de comparaison: KDE2, n'a duré que 1 an et demi. KDE 1 à duré 2 ans.
[^] # Re: durée de vie de KDE.
Posté par Raphaël G. (site web personnel) . Évalué à 3.
Au programme pour kde 3.5 un sacré nombre d'amélioration, et regardes les différences de perfs entre un kde 3.0 et un 3.5 vous verrez sérieusement la différence...
Quand au fonctions d'audio dans Kde, arts merde royalement, donc vivement d'avoir un truc qui plante pas tous les 4 matins...
Pour ce qui est de la non utilisation de gstreamer dans kde 4.0 directement, je comprend parfaitement le raisonnement des types de kde...
Pour avoir testé le packaging de amarok 1.4 beta avec gstreamer 0.10, il y a de très bonne raison d'éviter de s'enchaîner avec un tel framework...
Par exemple gstreamer 0.10 ne supporte pas les streamings web (donc vous dite adieu au streams ogg/mp3)
Je bénis en ce moment le seul framework qui marche : xine
(pourtant je trouve xine complètement pourrit)
Alors quand si ils choisissent de faire un simple binding qui fait les branchements qui vont bien, et bien c'est une bonne idée.
Bon ça va encore alourdir un peu le code, mais tant pis
(mon processeur tourne a 0% d'utilisation uc, alors je fait confiance aux dev de kde pour faire du bon boulot ;)
[^] # Re: durée de vie de KDE.
Posté par Ph Husson (site web personnel) . Évalué à 2.
Oui 'fin bon en meme temps il voulait dire que l'architecture globale n'avait pas bougé et a tres bien marché pendant 5 ans
Je bénis en ce moment le seul framework qui marche : xine
(pourtant je trouve xine complètement pourrit)
Tien toi aussi ?
(Enfin bon pour quand j'utilise amarok, mais ces bogues de moteurs me font tellement chier que je me mets en console à coup de alsaplayer pour les streams et mplayer pour le reste ....)
[^] # Re: durée de vie de KDE.
Posté par Gof (site web personnel) . Évalué à 4.
Le binaire d'une application compilée en 2002 pour KDE 3.0 fonctionne encore aujourd'hui avec les libraries de KDE 3.5, 4 ans plus tard
Si aRts avait été abandonné avant, une application KDE3.0 susceptible d'utiliser aRts n'aurait plus fonctionné.
Alors que la durée de vie des versions majeure de gstreamer est beaucoup plus courte (normale, on est au début, même pas encore en version 1.0)
[^] # Re: durée de vie de KDE.
Posté par agmk . Évalué à 4.
[^] # Re: durée de vie de KDE.
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Les "bugs" du compilateur ne sont pas vraiment imputables à KDE :)
[^] # Re: durée de vie de KDE.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
En effet, gcc ayant pas mal évolué, on a été obliger de modifier le code source pour tenir compte de cette évolution. Il n'est donc effectivement pas sur que si l'API n'ait pas changé, le code soit en pratique compatible.
Heureusement, le C++ est un peu plus stable aujourd'hui.
[^] # Re: durée de vie de KDE.
Posté par Gof (site web personnel) . Évalué à 1.
(mais gcc 3.3 est requis pour compiler KDE4)
De plus, il est en général assez facile de corriger les erreurs de compilation dû a une incompatibilité des compilateurs.
Par contre, faire compiler un programme écrit pour gstreamer 0.8 avec gstreamer 0.10 demande un réel travail (je pense)
[^] # Re: durée de vie de KDE.
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: durée de vie de KDE.
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
[^] # Re: durée de vie de KDE.
Posté par Gof (site web personnel) . Évalué à 2.
kdelibs 3.5.2 (mars 2006) avec kdemdemultimedia 3.0.0 (avril 2002)
Et puis, dans le monde du logiciel libre, il y a aussi la compatibilité des sources.
Le principe est que un gars qui à écrit une petite appli kde pour KDE 3.0 en 2002 fonctionnera encore en 2006 sous KDE 3.5 sans devoir changer une ligne de code.
Par contre, une application écrite en 1999 pour KDE1.1 nécessitera de grosse modification pour fonctionner aujourd'hui. La solution est d'installer les kdelibs 1.1.1.
Il est tout à fait possible d'avoir plusieurs version des kdelibs installée simultanément, et c'est ce qui sera fait lors de la transition de kde3 vers kde4
[^] # Re: durée de vie de KDE.
Posté par Infernal Quack (site web personnel) . Évalué à 4.
xine est tout de même le seul framework multimédia qui prend en compte les modifications à chaud : changement de langue des sous-titres, effets vidéo avec chainage,... alors que vlc, mplayer, (et les autres ?) relise la vidéo du début ou attende la prochaine vidéo.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: durée de vie de KDE.
Posté par Mark Havel . Évalué à 2.
Sinon, si je comprend bien, le but de Phonon, c'est de dire au niveau de KDE même quel environnement multimédia sera utilisé par tout le monde au lieu de le spécifier au niveau de l'application, c'est ça ?
[^] # Re: durée de vie de KDE.
Posté par Raphaël G. (site web personnel) . Évalué à 2.
(après il y aura surement un système de branchement backup genre :
gstreamer(mis en défaut)->alsa->xine->etc...)
[^] # Re: durée de vie de KDE.
Posté par dawar (site web personnel) . Évalué à 2.
Sinon c'est vrai que libxine est pas mal, mais xine-ui donne une image pas terrible du truc...
# précisions
Posté par herodiade . Évalué à 10.
- Comme Uraeus le fait remarquer à un moment dans les commentaires d'un des blogs, bien que les devs de Phonon aient au départ des ambitions modestes (le simple wrapper sur gst/nmm/xinelibs/...) et visait les cas d'utilisation les plus simples (qui sont aussi les plus courants: simple lecteur audio/vidéo, ou simple enregistreur), les utilisateurs potentiels de Phonon ont déjà commencé à faire le forcing pour le plomber de fonctionalités (VoIP etc). Or les devs de Phonon, qui avaient pourtant bien précisé au départ qu'ils voulaient couvrir les cas simples (et que les devs aux besoins avancés devaient se rabattre sur les fw mm directement), ils commencent peut à peut à céder à cette préssion et ont une wishlist qui devient énorme !
Du coup, le projet est (de l'avis d'Uraeus) un poil dévoyé: il va devenir gros (donc plus difficile à maintenir), il va implémenter des choses qui ne seront malheureusement pas mutualisables par les nombreuses aplis non kde. Et Uraeus souhaite que les devs travaillent plus pour mutualiser leurs efforts lorsqu'ils visent les mêmes objectifs (ce qui n'est en rien incompatible avec l'idée de Phonon comme wrapper, mais plutot avec Phonon comme réimplem des codecs voip/gsm, et tôt ou tard, s'ils ne posent pas de délimitations, de toutes les fonctions mm).
- L'intention fédératrice de GStreamer est tout de même louable: la dispertion à conduit les developpeurs à écrire une foultitude de frameworks multimedias (ou simples reimplems: vlc, xinelibs, mplayer, nmm, gstreamer, ...) qu'ils n'ont pas le temps de maintenir correctement (corriger les bugs etc), ou de mettre à jour pour suivre l'évolution sur rapide des codecs, ou de faire avec du code clean (sous tests unitaires, avec une API bien documenté etc), ou dont le modele "tout en un" (vs dlopen() des libs contenant les codecs à chaud) empeche l'intégration facile des codecs propriétaires ou brevetés dans les distros libres (gst, à ce niveau, propose un modèle assez intelligent) etc.
D'où leur investissement personnels très fort (vraiment) dans la qualité logicielle: gstreamer compile avec "-Wall -Werror", est sans cesse testé sous valgrind, est couvert par un énorme jeu de tests unitaires, testé en boucle sur plein de machines diverses, un coding style précis est imposé, un pipleine "efence" existe pour découvrir les moindres fuites mémoires, les devs ont une énorme collection de medias "vicieux" avec lesquels ils testent le svn-trunk quotidiennement ... et ils font de très gros efforts pour fermer les bugs au plus vite (je le sait, j'ai fait plusieurs bugs repports, ils ont été corrigés dans les un ou deux jours qui suivent !) et donc éviter que leur bugzilla ne grossise de façon incontrolable (cf. les devs de vlc: ils ont du fermer l'acces public à leur bugtracker tellement ils ont perdu pied ! ou mplayer, qui n'a même pas de bugtracker !).
Malheureusement ils manquent parfois de recul sur leur framework (je crois que leurs efforts pour la qualité du code, la position mentale que celà exige, y est pour qq chose: il faut être fier de son code et exigeant pour pouvoir refuser de le laisser partir à la dérive): comment peuvent-ils pester apres Phonon alors qu'ils n'ont pas encore écrit de binding C++ (condition minima pour être utilisable par les diverses applis mm de KDE) ? comment peuvent ils se dire "desktop agnostiques" alors qu'ils utilisent la glib de façon hardcore ? comment peuvent-ils dire qu'ils couvrent tout les besoins alors qu'en l'état, gst ne permet même pas de naviguer sur des DVD (entre autres grosses limitations) ? Comment peuvent-ils prétendre que leur API sera très stable pendant longtemps alors que la transition de 0.8 a 0.10 s'est faite dans le sang, les larmes et la douleur ? ...
- Certains commentaires l'ont clairement fait sentir: les developpeurs de gstreamer sont souvent trop enthousiastes au sujet de leur framework - et par contrecoup, n'ont pas l'oreille assez ouverte aux retours sur les problemes -: problèmes de portabilité (ils répètent a tout va que gst est ultra portable), manque d'API plus haut niveau pour les besoins simples de façon aisée et rapide (cf. les problèmes d'amaroK pour maintenir son portage sur gst, ou les débutants qui se plaignent de ne pas réussir à "renterer" dans le framework ou ne pas trouver de tutos clairs).
Il est évident que pour un dev de la lib gst, son utilisation est claire et simple, du coup cest dommage qu'ils n'entendent pas les appels à l'aide des developpeurs - moins familiers qu'eux avec les détails du fonctionnement de GStreamer - qui jugent l'API difficile d'accès, la doc pas pratique, même pour les besoins élémentaires (sachant que c'est un des principaux problème qu'entend adresser Phonon).
[^] # Re: précisions
Posté par herodiade . Évalué à 9.
- Tango (le projet d'unification des jeux de graphismes) : le but était d'avoir un look uni et cohérent, meme lorsqu'on lance des applis kde sous gnome et réciproquement. Des devs gnome ont lancé ça dans leur coin en croyant que les gens de KDE suivraient nécéssairement. Ce qu'ils n'ont pas fait, et pire, KDE a mis en place un projet équivalent (Oxygen) mais incompatible (la palette de couleurs n'est pas le même).
- Cairo : tout le monde etait censé definitivement adorer, et convertir tout les accès xlib sur cette lib vectorielle. Pas de bol, Qt4 est sorti avec sa propre lib vectorielle.
- GStreamer : dans l'esprit des auteurs, censé être la solution multimedia unifiée que les gros desktop environement devraient adopter définitivement. Mais en fait développé et maintenu par des devs gnome, totalement dépendant de libs gnomes (glib, liboil), et ne répondant pas aux besoins élémentaires des devs KDE (qu'ils auraient pu connaitre s'ils leurs avaient adréssé un petit mail, btw ...). D'où Phonon. Raté, donc.
- Telepathy: qui est sur le même chemin (deviendra une norme pure gnome, non supportée par kde, alors qu'elle se vend comme "cross-desktop voip/im framework").
- Orbit : idem, mais bon, on s'en sort bien avec D-Bus.
- je doit en oublier d'autres encore ...
L'attitude des developpeurs Gnome à cet égard me fait vraiment penser à l'attitude politique actuelle des USA vis à vis des instance internationales comme l'ONU: supposer que la démocratie, c'est leurs décisions unilatérales, que la discussion/négociation préliminaire est inutile, et que les autres approuveront leur idées puisqu'elles sont brillantes.
À cet égard j'aimerai aussi ajouter que freedesktop.org est une pure organisation de foutage de gueule (ou pire, un wiki pour que les devs gnome annoncent leurs directives aux devs kde), ou en tout cas, pas du tout une véritable instance de normalisation (aucune norme formelle n'est écrite, donc pas de votes, n'importe quel dev peut poser "sa norme universlle-cross-desktop-définitive" tout seul sur un coin de wiki etc.
Précision important à savoir, parcequ'on lis souvent sur linuxfr des commentaires qui ventent les qualités d'un DE par son taux de conformité "aux standards fd.o".
[^] # Re: précisions
Posté par Gof (site web personnel) . Évalué à 4.
Il n'y a là aucun objectif d'unification entre les différent desktop, mais le but est au contraire d'arriver à une charte graphique spécifique à KDE
- Certaines parties de Telepathy (protocole DBUS) seront utilisée dans KDE pour remplacer l'actuel KIMProxy (protocole DCOP), utilisé pour l'intégration entre KMail et Kopete par exemple.
(il n'est par contre pas question d'utiliser galago dans KDE, à priori)
[^] # Re: précisions
Posté par herodiade . Évalué à 2.
Il n'y a là aucun objectif d'unification entre les différent desktop, mais le but est au contraire d'arriver à une charte graphique spécifique à KDE
Oui je ne voulais pas dire qu'il y avait l'intention d'unification interdesktop du coté KDE. D'ailleur je trouve que les devs KDE n'ont pas ce defaut d'"unilateraliation".
D'ailleur le projet Tango a tellement capoté qu'il n'est même pas adopté comme jeux d'icônes par défaut dans gnome.
Merci pour la précision sur Telepathy (je crois que j'était resté avec des infos assez vieilles, au temps pour moi !).
[^] # Re: précisions
Posté par Misc (site web personnel) . Évalué à 0.
et la glib est une bibli généraliste qui ne tire pas un toolkit graphique particulier, tu confonds avec gtk.
ensuite, si gstreamer dépend de la glib, c'est surtout parce que plus personne ne code les bindings pour qt. Gstreamer a proposé plusieurs projets pour le summer of code, d'aprés ce que j'ai lu sur le canal, et notament un sur le sujet.
Maintenant, bien sur, si être utilisé par gnome fait d'un projet un truc gnome, comment est ce que kde fait avec gcc, le gnome c compiler ?
[^] # Re: précisions
Posté par herodiade . Évalué à 6.
C'est un peu comme si tu me disait « ah les devs gnome ne veulent pas devenir totalement dépendant de QtCore (la partie non-gui de Qt4), comme c'est bizzare, pourtant c'est une lib généraliste ». Un peu de sérieux.
ensuite, si gstreamer dépend de la glib, c'est surtout parce que plus personne ne code les bindings pour qt.
Absolument pas. Regarde les docs de l'API: le modèle objet GObject est au coeur de GStreamer.
C'est pas un simple wrapper objet autour des fonctionalités offertes par ce framework (et donc: même si un binding C++ ou Qt est écrit, ce sera simplement un enrobage, la dépendance à glib ne pourra pas être enlevée).
N'y vois pas une position religieuse de ma part: je deteste le C++ autant que le modèle objet de gnome.
[^] # Re: précisions
Posté par Thomas Douillard . Évalué à 1.
C'est le même G, à une indirection prêt qui fait que ton raisonnement tient plus ;)
[^] # Re: précisions
Posté par Gof (site web personnel) . Évalué à 2.
Ensuite, KDE n'a rien à voir avec GNU. Bien que KDE tourne sous GNU/Linux et compile avec, il fonctionne aussi sur d'autre UNIX, et compile avec d'autres compilateurs.
Et puis, le G de GTK vient aussi (indirectement) de GNU, cela signifie-t-il que KDE devrais aussi utiliser GTK.
C'est le même G, à une indirection prêt qui fait que ton raisonnement tient plus ;)
[^] # Re: précisions
Posté par Thomas Douillard . Évalué à 1.
Précision : mon post avait juste pour objectif de rectifier une erreur, je ne fais aucun raisonnement. D'ailleur je viens de m'apercevoir qu'entre autres erreurs je me suis trompé de post pour répondre, puique que c'est à herodiade qu'il s'adressait.
Boulet un jour, boulet toujours.
[^] # Re: précisions
Posté par Frédéric RISS . Évalué à 5.
Je te conseille de jeter un oeuil à ce blog d'un développeur de chez Trolltech: http://blogs.qtdeveloper.net/archives/2006/02/24/qt-and-glib(...)
surtout la dernière phrase.
A noter que je n'ai pas d'avis tranché à propos de Phonon, par contre j'ai du mal avec les avis plus qu'orientés qu'émettent les soi-disant défenseurs de chaque camp ( « {K|G} c'est de la merde » ). Les développeurs pour la plupart sont devenus beacoup plus raisonnables et au moins ils travaillent à faire avancer les choses (d'ailleurs ce qui est ici décrit comme une flamewar ressemble plus à un échange constructif d'idées entre amis).
[^] # Re: précisions
Posté par Ph Husson (site web personnel) . Évalué à 2.
Moi à la place des devels GStreamer je serais fier d'être utilisé par KDE alors que gstreamer était prévu pour GNOME!
Et surtout aussi que gstreamer est prévu pour avoir une API extrement complete et puissante qui le destine plus à des applis genre audacity (bon j'ai pas d'autres exemples en tete mais bon doit bien en avoir), alors que jack qui est dans le même genre que gstreamer (enfin lui ne fait que de l'audio) et pourtant a une utilisation extremement restreinte (le nombre de "grosse" appli qui doivent l'utiliser doivent pouvoir être compter sur les doigts (avec ceux des pieds qd meme)
[^] # Re: précisions
Posté par herodiade . Évalué à 3.
Arf, mon explication devrait être très floue parcequ'en fait c'est l'inverse: les developpeurs de GStreamer pensaient que ce framework était prévu pour tout les DE (et ne se sont pas apperçu de certains aspects trop gnome-centrique puisqu'ils étaient tous devs gnome) ; ils sont plutot surpris d'apprendre que KDE ne l'adopte pas comme seul framework possible (à priori Phonon laissera le choix à l'utilisateur/distributeur du fw mm sous-jacent, gstreamer ou autre), et sont surpris de découvrir soudainement que les developpeurs de juk, amaroK etc. ont tu mal à maintenir leur backend GStreamer.
alors que jack qui est dans le même genre que gstreamer
En fait non. Jack est un serveur de son multipiste orienté temps réel (il fait du multiplexage, ce genre de choses). Il est plutôt de la famille de ESD ou aRts que de Gst en fait. Jack ne fait pas d'encodage/desencodage ogg/mp3 par ex.
Et GStreamer n'est pas un serveur de son. C'est un framework multimedia: il fournis une API unfiée pour parler aux serveurs de son comme aRts ou ESD (ou aux pilotes de la carte son directement), une API unifiée sur les différents codecs (audio, vidéo, sous-titres: ça évite d'avoir des structures totalement différentes dans son code selon qu'on accède à un fichier ogg ou a un mp3, par ex.), de synchronisation etc. Par contre il ne gère pas le multiplexage entre les accès audio concurents de diverses applis (rôle d'un serveur de son).
Btw il existe d'ailleur une tentative de plugin GStreamer offrant un backend sur jack (très experimental !).
Un exemple, pour situer tout ça. Imagine un lecteur audio :
- Il peut se charger lui même de lire les fichiers audio ogg, mp3, flac, wav, cd audios etc. et envoyer le résultat à Jack (ou à alsa, ou arts ...) pour le rendu sonore. Mais dans ce cas, il doit faire toutes les conversions (codecs -> pcm raw) lui meme (en s'adaptant à chaque fois aux API des différentes libs), et gérer lui même les accès au serveur de son (avec là encore leurs diférentes API: jack, esd, ...) ou à la carte son directement (API/interface différentes à chaque fois: alsa, win32, oss, mac os x, *bsd, solaris ...)
- Il peut utiliser un "framework multimedia" (comme GStreamer, xinelibs ou NMM) qui se chargera à sa place de deviner le codec utilisé (ogg, mp3, wav etc) de fournir à l'appli le son dans une structure de donnée "unifiée" (quel que soit le codec d'origine) de façon transparente. Le framework fournira éventuellement la possibilité d'appliquer des effets à ce son, encore une fois avec une API unifiée quelque soit la provenance des "effets" (native, LADSPA, ...). Enfin, le framework se chargera aussi d'envoyer le son au serveur de son / à la carte son / sur le réseau / ... pour le rendu, là encore, via une API unique malgrè la différence de chaque type de sortie possible.
- Il peut enfin utiliser un wrapper (type Phonon, quand il sera fait) qui permet d'écrire les besoins simples (lis tel fichier, enregistre telle source, envoi le son sur telle sortie ...) en peu de lignes dans l'application multimedia, et qui se charge de transformer ça en appels à un framework multimedia sous-jacent (GStreamern ou NMM etc). Celà permet notament de remplacer le framework multimedia s'il ne convient pas, sans rien modifier dans l'application.
Bref, pour situer shématiquement leurs positions relatives: Phonon fournis une couche d'abstraction/simplification au-dessus de GStreamer qui fournis une couche d'abstraction au-dessus de Jack.
Les frameworks comme GStreamer permettent d'éviter à chaque appli multimedia de ré-écrire le même code chacune de leur coté. Les wrappers comme phonon leur permettent d'être indépendants du choix du framework comme GStreamer ou xlinelibs (et de mutualiser ce code d'abstraction: qui est actuellement implémenté en double dans juk et amarok par ex.).
[^] # Re: précisions
Posté par Ph Husson (site web personnel) . Évalué à 3.
je peux faire artsplay un.mp3 (enfin bon je peux pas tester vu qu'en ce moment moi et arts spa le grand amour, mais je suis un peu pres sur)
En plus amarok supporte arts comme moteur ca veut dire qu'il peut faire ca
À côté de ca tu cite NMM comme framework mais il me semblait que c'etait un démon (d'ailleur pour pouvoir gérer le réseau faut un serveur et à part les démons je vois pas)
[^] # Re: précisions
Posté par herodiade . Évalué à 3.
Je suppose que ça signifie que logiciel artsplay doit savoir convertir les mp3 en raw pcm et les envoyer à aRts (?) (c'est juste une hypothèse, hein).
En plus amarok supporte arts comme moteur ca veut dire qu'il peut faire ca
Je n'ai pas d'amaroK sous les yeux pour tester, mais soit il le fait en spécifiant explicitement au framework multimedia en cours d'utilisation d'utiliser aRts (je ne sait pas pour xinelibs, mais GStreamer permet de bybasser sa décision et de choisir soi-meme la sortie audio qu'il utilisera), soit c'est du code qui date d'avant l'inclusion des backends comme GStreamer dans amaroK.
À côté de ca tu cite NMM comme framework mais il me semblait que c'etait un démon (d'ailleur pour pouvoir gérer le réseau faut un serveur et à part les démons je vois pas)
Un petit texte sur NMM avec des jolis dessins ;)
http://www.linuxdevices.com/news/NS5209121793.html
Ça dit: « NMM works by moving multimedia applications away from their traditional client-server architecture, toward a more distributed middleware approach. ».
[^] # Re: précisions
Posté par Narishma Jahar . Évalué à 6.
[^] # Re: précisions
Posté par Infernal Quack (site web personnel) . Évalué à 4.
arts n'était pas maintenu mais si il l'avait été ça aurait été (ou c'est) un truc similaire à gstreamer mais uniquement pour le son.
Il suffit de lancer artsbuilder et d'ouvrir les exemples pour voir qu'arts permet de faire des redirections, du mixage,...
On peut aussi lancer artscontrol et aller voir les types de média supportés. Si je ne me trompe pas, c'est arts qui gère ces médias (mp3, ogg, mpg, qt,...) et pas l'application qui réinvente la roue à chaque fois.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: précisions
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Si je me souvient bien c'est parce qu'il était par essence mal conçu.
(je te renvoie a son mail, précédament posté dans une dépèche)
Et puis arts est passablement buggué...
(Pour l'avoir utilisé pas mal de temps, je passait plus de temps a rapporter des bugs qu'a lire mes fichiers audios sous amarok...)
Bon maintenant y a plus le choix, dans la version 1.4, le moteur arts a carrément été droppé...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.