http://aseigo.blogspot.com/2011/03/collaborations-demise.html
Article interessant sur le blog de aseigo.
On y découvre le manque de volonté du projet Gnome pour collaborer avec les autres projets et en particulier avec Ubuntu.
On y voit comment Canonical arrive a discuter avec le projet KDE (même si ils ne sont pas toujours d'accord) pour trouver des compromis avec certaines technologies là ou Gnome refuse le dialogue avec des arguments qui ne semblent vraiment ne pas tenir la route (comme le démontre Aaron).
Si j'ai bien compris, il semble même que les specs Freedesktop ne venant pas de Gnome ne sont pas intégrées (usage metadata for freedesktop.org specs).
Peut être que quelques devs Gnome vont pouvoir nuancer tout cela ? ;)
ps: désolé, on est pas vendredi mais c'est pas ma faute à moi!
# Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 4.
http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/ C'est facile de réécrire l'histoire après coup et ça ne réponds toujours pas à l'interogation de Dave Neary (qu'on peut difficilement accuser d'anti-canonical-isme primaire)
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par monde_de_merde . Évalué à 4.
Qu'est ce que tu appelles "réécrire l'histoire" ? Non parce si on s'en tient aux faits, il n'y a effectivement pas de développeurs Gnome parlant au nom de Gnome dans la discussion pour l'établissement de la spécification "status notifier".
Peut être que son exemple est mal choisi et qu'effectivement Canonical n'a jamais proposé son aide à Gnome. Ce que je peux dire à la lecture des 2 articles c'est que sur cette exemple là, plus qu'à Canonical c'est à une bonne partie de la communauté qu'ils ont tourné le dos.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 8.
Si on s'en tient aux faits: - 2009: KDE bosse sur une implémentation de la zone de notification basé sur D-Bus au lieu de XEmbed qui aboutit à KNotificationItem
septembre 2009: Marco Martin propose un ersatz de spécification initialement nommé KNotificationItem après finalisation de l'implémentation éponyme. (Frédéric Peters de GNOME intervient lors de cette première discussion)
fin 2009/début 2010: les gars de Canonical s'acoquinent avec les gars de KDE à ce sujet pour proposer appindicators dans Lucid Lynx (10.04)
un foetus de spécification[1] digne de ce nom est proposé fin décembre 2009
une discussion a lieu sur la mailing-list en janvier 2010 sans réellement aboutir.
Je note avec amusement que les gens de KDE qui accusent fd.o d'être le cheval de Troie de GNOME pour imposer leurs technos, ont été nettement plus bourrins que GNOME en proposant directement de normaliser un truc déjà implémenté dans KDE sans réelle discussion. En général, les gens de GNOME démarrent la discussion AVANT ou au DEBUT d'implémenter la spécification, ce qui est plus logique.
Dans les faits, il y a eu deux discussions sur la liste xdg alors qu'Aaron Seigo parle de plusieurs (à mon avis, il doit se mélanger les pinceaux avec les discussions internes à KDE et Canonical), la première étant une tentative avortée. La seconde discussion a vu les interventions notables de Dan Winship (Novell), Matthias Clasen (Red Hat), Vincent Untz (Novell), trois poids lourds de GNOME).
Si on se base uniquement sur les faits, la version d'Aaron Seigo qui voudrait que GNOME ait refusé la discussion sur "notifier status" est fausse puisque les seules discussions ont été internes à KDE et Canonical excluant de fait GNOME. De plus, la non-intégration de libindicators dans GNOME résulte plus de la mauvaise foi de Canonical que de la mauvaise volonté de GNOME [3]. En gros, Canonical s'attends à ce que GNOME accepte ses conditions sans discussion et surtout pas répondre aux questions de la communauté. Red Hat et Novell qui ont un poids autrement plus important dans GNOME sont loin d'avoir un comportement aussi cavalier (pourtant, c'est pas les cow-boys qui manquent dans l'équipe desktop de Red Hat). L'inaptitude de Canonical (feinte ou réelle) à collaborer avec upstream n'a rien de neuf, ça fait 7 ans que Debian, GNOME, et plusieurs autres acteurs du libres s'en plaignent sans que Canonical change quelque chose à sa façon de faire à part des effets d'annonces (annonces souvent non suivi d'effets ou bien abandonné deux semaines après).
[1] http://www.freedesktop.org/wiki/Specifications/StatusNotifierIcon
[2] http://lists.freedesktop.org/archives/xdg/2010-January/thread.html
[3] http://www.advogato.org/person/mbanck/diary/48.html
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par windu.2b . Évalué à 9.
Le journal contre l'avortement, c'est pas ici !
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 10.
Tu vas peut etre nous citer une normalisation faite par KDE que GNOME a implemente? Parceque les exemples dans l'autres sens sont legions et les abandons des solutions KDE pour se "normaliser gnome" aussi (DCONF -> DBUS en est le meilleur exenple).
Mais peut etre que les devs de KDE sont tous des cons et sont incapables de normaliser un truc pour l'ensemble des bureaux?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 4.
arglll lire DCOP a la place de DCONF naturellement...
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à -3. Dernière modification le 09 mars 2011 à 16:08.
Si KDE s'investissait un peu plus dans FreeDesktop.org et essayait de proposer une implémentation de référence neutre, ça arriverait plus souvent.
Tu veux dire DCOP (et non pas DConf qui est le nouveau backend de configuration GNOME). DBus n'a jamais caché être un DCOP NextGen, le but était de proposer un DCOP amélioré, interopérable et neutre (l'implémentation de référence ne requiert que l'API Posix et utilise les sockets Unix ou TCP).
DCOP avait une dépendance forte par rapport à Qt3 et ICE (donc X11), donc pas réutilisable par les autres.
Non, loin de là mais fournir une implémentation non seulement achevée mais également fortement couplé à Qt voire aux kdelibs et dire "c'est ça la spécification", même les tyrans de GNOME n'osent pas en rêver.
Ouvrir la discussion avant de coder (ou un avec un début d'implémentation), et proposer une implémentation de référence neutre (avec au plus une dépendance vers la GLib), c'est quand même un peu mieux.
J'ai l'impression que KDE a pas compris le fonctionnement d'un comité de normalisation et après se plaint que ça ne marche pas.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 3.
Je me suis corrige pour DCOP (cf message au dessus). DBUS est si complique que KDE a fait un QDBUS pour retrouver la simplicite et la puissance de DCOP!
Et ceci n'etait qu'un exemple. J'attend le nom de technos KDE que Gnome a reutilise dans les 5/6 ans. La meme question a ete pose sur le blog de Aaron et la aussi les reponses ne sont pas legions ou du style de la tienne, a cote.
Il est question d'un probleme de collaboration ou pas mal de monde (y compris des devs Gnome) sont d'accord que ce projet fait ce qu'il veut sans tenir compte de ce qui se fait a cote. L'exemple des notifications montre le probleme mais n'est qu'un exemple parmis d'autre. Au passage que le projet Gnome ne veuille pas prendre l'implementation de la norme qui etait en train d'etre cree et d'etre utilise par tous les projets autre que Gnome cela ne les excuses pas de ne pas avoir implemente leur propre notification suivant la norme tel que defini sur fd.o!
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 3.
Facile, WebKit. GNOME ne rechigne pas à utiliser une technologie issue de KDE si elle est neutre. Si WebKit a connu un plus grand succès que son prédécesseur KHTML, c'est principalement du au fait qu'Apple a pris soin de découpler WebCore de Qt et KDElibs. Si GNOME emprunte moins de technologies à KDE que l'inverse, c'est principalement dû au fait (que j'ai déjà souligné auparavant) que KDE ne propose JAMAIS d'implémentation générique ou essaie toujours d'imposer un truc FINI avant même de discuter des choix.
Sur le blog d'Aaron, Dan Winship a rappelé que lui et Matthias Clasen avait tenté de discuter la proposition de "status notifiers" pour se voir opposer une fin de non recevoir et bizarrement Aaron n'a pas su répondre.
C'est un non-sens total, certes GNOME n'est pas obligé d'utiliser l'implémentation de référence (et vice-versa) mais tu ne peux pas arriver avec une implémentation finie, vendor-specific et balancer un "c'est la norme, point barre". Les mecs de KDE ont refusé de discuter des choix de conception (un comble pour une proposition de spécification), parce qu'ils avaient déjà un truc en place et estimaient qu'ils avaient déjà résolus tout les problèmes.
Quand on veut démarrer une norme, soit on accepte de partir d'une feuille blanche (ce qui n'empêche de s'inspirer de l'existant comme avec DBus/DCOP), soit on propose une implémentation de référence que tout le monde peut bidouiller. Dans tout les cas, ça implique de discuter des choix de conceptions et de faire des compromis, quitte à casser des choses existantes mais les gars de KDE n'était pas prêts pour ça.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 3.
Tu sais tres bien que implementer un norme c'est le meilleur moyen de trouver les problemes dedans donc que KDE arrive avec une premiere proof-of-concept je trouve cela tres tres normal. De plus par rapport aux notations c'est pas comme si cela etait pas connu de Gnome le protocol en question.
Ton exemple de Webkit est super mauvais car justement ils n'ont pas pris a partir de KDE mais a partir de Apple et cela date de plus de 5 ans non?
Par rapport au normes que Gnome impose avec son implementation sans discussion avec qui que ce soit je ne nommerai que les tres celebres network-manager (que je trouve tout pourris par rapport a Wicd par exemple) et surtout pulseaudio. Un truc typiquement Gnome qui a mis des annees a fonctionner a peu pres correctement!
Je ne dis pas que les technos KDE etaient mieux dans ces cas la, je nomme ces projets pour donner des exemples de projet Gnome qui ont ete force sans aucune discussion avec qui que ce soit.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 2.
Sauf que depuis le début, je t'explique que les mecs de KDE sont débarqués avec un truc finalisé et pas un POC. Dan Winship a rappelé sur le blog d'Aaron Seigo qu'ils avaient même refusé de discuter le design.
Parce que justement Apple a pris le temps de découpler WebCore des KDElibs et Qt sans quoi, c'était inutilisable. Avant même WebKit, Nokia avait financé un portage Gtk+ de WebCore (d'abord la variante KHTML puis WebKit) pour finalement abandonné car ça revenait à forker ce dernier. http://gtk-webcore.sourceforge.net/
Au plus tôt 2007
Ça n'a jamais été proposé en tant que spécification.
Tu n'as jamais regardé le code de Wicd pour dire ça, de plus NM est bien plus qu'une applet de connexion réseau, c'est également un framework pour gérer le réseau.
Personne n'a forcé personne, c'est juste un vieux fantasme des KDE-istes qui crachent sur toute techno dont le nom ne commence par K. Ils ont juste pas compris qu'une fort couplage à Qt ou pire aux KDELibs était un frein majeur à l'adoption des technos maisons chez les autres.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 3.
Et Gnome n'avait pas voulu faire cela car cela venait de KDE.
DCOP etait trop KDE oriente du coup cela a ete CORBA avec le succes que l'on connait mais comme il ne fallait toujours pas avouer que l'on avait tord, Gnome a pondu DBUS completement repompe sur DCOP mais en moins bien ou plutot en plus complexe, a tel point que tout le monde est oblige de faire des trucs plus haut niveau pour s'en servir... Et la encore c'est KDE qui s'est adapte.
C'est amusant car de l'autre cote ils sont moins bornes et ont pris network-manager qui utilisent a fond les Glib et cie... (entre autre) comme quoi le moins bornes sont peut etre par les KDEiste... Et niveau protocole ils ont aussi pris les icones (un truc pondu par Gnome sans concertation aucune).
Et de tout de facon ici il etait question d'un putain de protocole et vu que des projets Gnome (Conky et le truc de ubuntu par exemple) utilise cela c'est que cela doit etre totalement decouple de KDe non? Est-ce que l'equipe de Gnome-shell a communique sur sa nouvelle facon de gerer les notifications sur fd.o avant 2009? Il me semble bien que la reponse est non mais peut etre vas tu nous fournir un lien prouvant le contraire.
Dans les autres exemples ou Gnome n'aime pas integrer KDE, c'est du cote de KDE et uniquement KDE que les projets gtk-qt et qt-gtk qui permettent d'avoir la meme apparence dans les applications que tu sois sous Gnome ou KDE ont ete fait. Gnome n'a strictement rien fait pour s'integrer a KDE (niveau apparence) ou inversement integrer les applis KDE. Ceci demontre l'etat d'esprit Gnomiste et la raison pour laquelle je n'aime pas ce projet.
Je pourrait parler du super concept "spatial" qui a ete force au niveau utilisateur. La meme erreur est en train de se produire avec Gnome-shell qui par exemple ne permet pas de reduire les applications "car cela est contraire au concept". C'est amusant cela va encore a l'encontre du desir des utilisateurs. Comme je suis a peu pres persuade le fait que les notifications vont marcher sous gnome-shell uniquement et avec aucun des autres projets necessitant ce genre de chose meme ceux qui etendent les capacites de Gnome (conky).
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par jbbourgoin (site web personnel) . Évalué à -4.
Vous mélangez tout, et le plus drôle c'est que lorsque vous traitez réellement du sujet de votre interlocuteur c'est pour lui donner raison !
Il y a de quoi rire aussi :
Tout le reste de votre discours consiste à dire pourquoi vous n'aimez pas la manière dont les devs de GNOME conçoivent GNOME. C'est bien, mais ça n'est pas le sujet !
KDE reprendre des trucs de GNOME ? C'est bien, mais ça n'est pas le sujet !
Le sujet est : qu'est-ce qu'une spécification et comment les projets KDE et GNOME se situent par rapport à la réalisation d'une specs.
En gros mon impression est celle-ci : GNOME a une approche specs, on intègre ce qui vient de chez nous (normal) ou les trucs freedesktop. KDE a une approche "pratique" : on intègre ce qui fonctionne, y compris si c'est un truc GNOME, mais on est incapable de faire une spec car on est persuadé que cela consiste uniquement à proposer un truc fonctionnel et tout prêt, qu'il soit ou non dépendant de toutes les libs KDE.
Canonical a une approche semblable à celle de KDE : "Quoi ? On propose un truc qui fonctionne et vous refusez, c'est inacceptable !"
Jusqu'à preuve du contraire le projet GNOME a encore le droit de choisir ce que son environnement intègrera "officiellement". Pour ceux qui veulent appindicator, il suffit d'installer la lib et d'utiliser les logiciels qui l'utilise, mêmes les applis GNOME ne manquent et je ne crois pas que le projet GNOME voit cela d'un mauvais œeil.
Les "nazis" de l'interface ne sont pas ceux que l'on croit. Certes le projet GNOME est très circonspect quand il s'agit d'intégrer des fonctionnalités nouvelles à son bureau mais au moins il n'a jamais dit à la communauté KDE la manière dont elle devait gérer leur projet...
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par ecyrbe . Évalué à 2.
Moi ce que je vois, c'est qu'il y a des torts des deux côtés.
KDE produit effectivement rarement des technologies non liées à Qt, et celà freine forcément l'adoption de ces technologies sur d'autres environnements. Gnome possède un processus très lourd (et lent) dans sa façon de normaliser une techno.
Pour ce qui est de réinventer la roue, les deux projets ont autant de mérites.
Cependant, pour les technologies issues de gnome, pulseaudio et DBus n'en font pas parti. Ce sont plutôt des technos de RedHat qui voulait dans les deux cas des implémentation qui ne soient pas dépendantes de l'une ou l'autre des plateformes. Ils ont refait DCOP en DBUS, car DCOP était trop couplé à Qt. Pour PulseAudio, les solutions qui existaient (ESD, ARTSD, JACK) ne répondaient pas bien au problème de mixage audio et chaque plateforme avait la sienne.
Le fait que gnome ait été prompt a adopter ces technologies et a participer a leur développement n'en fait pas des technologies issues de gnome pour autant.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 10.
Parmis les reponses du blog de Aaron on trouve cela:
Gnome-shell n'est pas finalise que je sache alors que le changement de notification utilise dans KDE a bien 1 an ou 2 cela veut dire que si Gnome avait voulu etre compatible ils avaient LARGEMENT le temps de s'adapter. Mais ils ont fait expres de faire un truc different. Resultat pour les utilisateurs: des applis qui seront incompatibles entre elles au niveau du systray... Genial.
Visiblement Gnome ne fera jamais la moindre concession et donc ca va se terminer comme d'hab, KDE qui va devoir utiliser un truc pourri car eux ils veulent la meilleure integration possible pour l'utilisateur finale quitte a se palucher des truc gnomesque!
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . Évalué à 10.
C'est marrant, tu dis plus haut qu'une dépendance à la GLib, c'est pas grave, mais une dépendance à Qt Core (l'équivalent de GLib en somme), c'est inacceptable. Pourtant, quand on regarde de près, c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre. D'ailleurs, on constatera que dans les dépendances de KDE, il y a GLib mais dans les dépendances de GNOME, point de Qt Core. Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.
Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango. L'un comme l'autre ont été imposé par GNOME. GStreamer étant la solution son de GNOME, et Pango étant la solution de rendu de fontes (issue à la base de Gtk si je me souviens bien, qui est quand même le concurrent de Qt Gui). Les deux, en plus de la GLib, se traîne GObject ! On pourrait aussi citer PolicyKit ou DeviceKit ou encore le vénérable HAL. Tous sont dans ce cas d'utiliser GLib+GObject. Hormis Pango (pour lequel il existe un équivalent dans Qt), KDE n'a jamais refusé d'intégrer ces composants développés par RedHat pour la plupart et donc avec GNOME en tête.
Dans le cas présent, pour une fois, c'est KDE qui propose la première implémentation. Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues. Ça va de "ça ne nous intéressait pas" (contredit plus loin par "on l'a mis dans GNOME Shell") à "ça s'est fait sans nous" (alors que aseigo montre que KDE a pris en compte les remarques venant de GNOME). Bref, que des justifications très égocentriques.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à -3.
La lib QtCore fait entre 2 et 3 fois la taille de la GLib, sans compter qu'intégrer une lib C++ dans une lib C c'est moins évident que l'inverse. De plus, la GLib est une petite lib C généraliste utilisable indépendamment de GObject ou Gtk+, on peut en dire autant de QtCore (jusqu'à il n'y a pas si longtemps, Qt était encore un framework monolithique). Puis, tu gères comment la dépendance circulaire, si on doit jouer au zero sum entre GLib et QtCore ?
Je ne nie pas que Nokia a fait un gros effort pour s'intégrer à GNOME (intégration de la mainloop GLib, thème Gtk etc ...), mais Nokia != KDE. Je ne crois pas que KDE fasse plus que GNOME à ce niveau.
discutable en quoi ? GStreamer est le seul framework multimédia potable sous *nix, Pango n'est pas hébergé par FreeDesktop ni même utilisé par Qt ou KDE.
Faut arrêter de dire n'importe quoi, depuis quand GNOME impose des technologies ? si les gars de KDE utilisent GStreamer, c'est bien parce qu'ils le veulent bien. Par ailleurs, GStreamer est né en dehors de GNOME et a une vie indépendamment de celui-ci.
T'es allé sur les mailings-lists ou tu t'es juste arrêté aux billets d'humeurs d'Aaron Seigo et Mark Shuttleworth ? Parce que des pointures de chez GNOME ont participé à la discussion lancé sur fd.o pour se faire balancer une fin de non-recevoir par Aaron Seigo. Forcément, si les mecs de KDE croient que pour balancer une spécification, suffit de balancer une implémentation complète puis de faire un plébiscite, je comprends pourquoi ils râlent depuis des années: ça se trouve, ils n'osaient pas participer à fd.o en croyant que ça marche comme ça ! Du coup, ça expliquerait pas mal de choses, c'est juste qu'ils ont pas compris comment fd.o fonctionne !
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par gnumdk (site web personnel) . Évalué à 4.
Oxygen-gtk au hasard ? GNOME n'a pas a faire le boulot vu que Nokia l'a déjà fait.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par gnumdk (site web personnel) . Évalué à 4.
C'est toi qui n'a rien compris...
Ils ont fait une implémentation pour prouver le concept, mais une fois cela fait, ils ont attendu toutes les critiques afin de la modifier pour les besoins de GNOME...
De plus, quand je vois le climat dans le projet GNOME, j'ai du mal à voir comment ils pourrait travaillé avec KDE...
Voilà ce qu'un dev Gnome m'a répondu quand au placement complétement stupide de la barre d'outils dans Nautilus version Gnome3. On sent que c'est facile de discuter avec certaine personne, même au sein du projet.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . Évalué à 5.
Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M. Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject, tous les projets cités l'utilisent. Donc GObject = 309K. Et bien tu vois, entre l'un et l'autre, honnêtement, il n'y a pas tant de différence. Il y aurait un facteur 10, je dis pas, on pourrait critiquer, mais là, moins de 3, ça va pas chercher très loin, on reste dans le même ordre de grandeur.
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre. Et un projet peut utiliser soit l'une, soit l'autre.
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là. Les dev GNOME ne jurent que par GStreamer qui n'a jamais été massivement adopté pour des raisons à la fois de non-stabilité (comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques) et de non compatibilité de l'API entre la 0.8 et la 0.10.
Il est cité comme projet fd.o sur les wikipedia fr et en. Donc il est supporté par fd.o même s'il n'est pas hébergé par fd.o. Et oui Qt avait sa propre solution (et je ne pense pas que l'un ait eu l'antériorité sur l'autre) donc KDE utilisait le truc de Qt. Mais il se trouve qu'un nouveau projet est arrivé pour unifier tout ça : HarfBuzz. Attendons de voir ce que ça donnera.
Ha ça c'est sûr, tout le monde en est convaincu : d'ailleurs, si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy), GStreamer est utilisé par GNOME depuis 2002 (alors que seuls quelques applis KDE l'ont utilisé : Juk et Amarok (même si tout le monde utilisait le backend Xine d'Amarok pour les raisons cités précédemment)), et même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME. Vraiment, là, c'était trop gros, ça ne passe pas.
Tu veux dire "faire comme les devs GNOME" ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 1. Dernière modification le 10 mars 2011 à 13:40.
Que tu comptes ou pas GObject, GLib reste 2 à 3 fois plus petit que QtCore. Dans des systèmes embarqués, ça n'a rien de négligeable (d'ailleurs, tu peux compiler QtCore sans le support de la GLib pour cette raison).
Mais bon, ça n'élimine pas le problème du C++ et de son ABI de merde.
Mes confuses, on ne s'est pas compris, c'est juste qu'exiger que la Glib ait un requirement vers QtCore parce que QtCore a une dépendance vers GLib, c'est juste stupide.
Ce ne sont PAS des frameworks multimédias ! (du moins pas aussi complet que GStreamer dans le cas de Xine)
PA va se trainer pendant combien de temps, les casseroles d'Ubuntu ? PA a été intégré dans Fedora 8 par son mainteneur et ça a fonctionné correctement dès le PREMIER jour, Mandriva, SuSE l'ont fait dans les 6 mois qui suivent sans problèmes majeurs.
Les branquignols de Canonical l'ont intégré comme des bourrins dans une version LTS sans prendre le temps de tester ni même contacter Lennart et après, c'est de la faute de PA ?
Est-ce que quelqu'un a offert de sponsoriser le voyage du développeur à aKademy ? Non.
À l'origine, c'était un projet universitaire et il s'est écoulé deux ans entre la première release publique et le rapprochement avec GNOME.
Idem pour la page Qt qui le cite comme une technologie KDE, dois-je en conclure que KDE développe Qt ?
En parlant de Qt, c'est un peu agaçant de dire que KDE fait plus d'efforts que GNOME en terme d'intéropérabilité alors que rien n'est plus faux (pour autant GNOME n'en fait pas plus, on est bien d'accord).
La plupart des initiatives d'intéropérabilité viennent de Trolltech puis Nokia pour diverses raisons: ils vendent un framework cross-platform qui doit s'intégrer le mieux possible à la plateforme native GNOME compris. Les gens de KDE sont pas plus altruistes que ceux de GNOME.
en l'occurrence s/GNOME/KDE/ ! Je pense qu'il y a un gros problème de communication.
Au début, t'as un mec qui bute régulièrement sur un problème commun à tous, selon son background, il aura une approche différente: GNOME: je propose une spécification avec un début d'implémentation, on discute, je modifie mon implémentation, si tout le monde est d'accord, c'est tacitement accepté.
KDE: je propose une implémentation fonctionnelle voire intégré à une version sortie, et on fait une spécification autour puis c'est explicitement accepté. Tu rajoutes la mauvaise foi coutumière des geeks libristes et ça donne un mélange explosif.
Donc forcément, les gens de GNOME voient les gens de KDE comme passifs et renfermés et les gens de KDE ceux de GNOME comme autoritaires. C'est un peu le problème de fd.o qui n'est pas vraiment un organisme de normalisation mais avant tout un forum de discussion, il faudrait éventuellement formaliser le processus pour gommer ce genre d'incompréhension.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 4.
Mais bien sur les trois trucs suivant ont ete fait en collaboration avec KDE avant toute implementation...
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par gnumdk (site web personnel) . Évalué à 3.
Et encore, gstreamer ca reste une grosse merde à l'heure actuelle...
KDE 4.6: phonon-xine est déconseillé, j'avais migré sous phonon-vlc mais un bug génant avec amarok (micro coupure au milieu des chansons) m'a fait passer à phonon-gstreamer...
Résultat ?:
- Des mp3 ou j'ai pas de son
- Des mp3/ogg ou je peux pas me déplacer dans le morceaux...
Vraiment, y'a pas à dire, gstreamer c'est de la balle... Pour info, rien à voir avec phonon ou amarok, ca me fait pareil avec clementine qui utilise directement gstreamer...
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 3.
ca je ne peux pas dire je n'utilise JAMAIS ce truc. Cela ne marche quasiment jamais correctement que ce soit avec la lecture des mp3, la lecture des DVDs ou la lecture de fichiers avi (avec totem donc rien avoir avec KDE).
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par nicolas . Évalué à 2.
Si t’es sous Debian et dérivées, c’est probablement un paquet gstreamer-* qui manque, non ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, ils sont tous installés et j'ai jamais dit que j'arrivais pas à lire les mp3/ogg, j'ai dit certain mp3/ogg...
En clair vivement que phonon-vlc soit stable que je me débarrasse de ce truc.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par Albert_ . Évalué à 3. Dernière modification le 09 mars 2011 à 20:24.
Oui mais il y en a un qui fonctionne sans aucun probleme est un autre qui fait n'importe quoi quand ca lui prend et pour l'arreter et le demarrer c'est tellement intuitif:
ca c'est du service facilement redemarrable quand il plante ce qui arrive bien souvent.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . Évalué à 1.
Si tu es vraiment obligé de taper cette commande pour relancer le service NM, plains-toi à ton distributeur. Sinon, pour une utilisation mobile, NM se révèle très fiable et je n'ai jamais eu à m'en plaindre.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par cedric . Évalué à 10.
Alors ca, ca me fait sauter au plafond ! Et ca explique plein de chose concernant la pietre qualite des standards Freedesktop ! Si tu tentes de definir un standard sans avoir jamais code au minimum un proof of concept, tu n'as pas idee de ce qui va techniquement te poser des problemes. Il faut deja avoir du code et de l'experience dans le domaine d'un standard pour avoir une chance de faire quelque chose d'efficace, peren et utilisable !
# Comments
Posté par torturedutopian . Évalué à 6.
Faut lire les nombreux commentaires sur le blog d'Aaron, c'est assez passionnant et instructif. L'objectif d'Aaron n'est pas, selon lui, de pointer du doigt un coupable, mais d'améliorer la coopération à l'avenir.
[^] # Re: Comments
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 9.
Pour connaitre Aaron, et avoir bu quelques bières avec lui, je confirme l'état d'esprit du personnage:
Un gas très positif, cherchant à améliorer ce qui ne va pas, dans le but d'un monde meilleur pour tous. Un grand personnage du libre trop méconnu.
Je rajouterai que son blog est en général très intéressant, et pas forcement centré KDE. Avis aux amateur de flux RSS sympa.
# C'est drôle...
Posté par jbbourgoin (site web personnel) . Évalué à 0.
C'est assez drôle l'arrivée de GNOME 3, on retrouve à peu près la même ambiance que lors de l'arrivée de KDE 4.0...
Bah, dans un an les choses se seront tassées, les technos auront été polies et tout le monde se fera gentiment la bise.
# Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org
Posté par Sébastien Wilmet . Évalué à 1.
Tout se trouve sur ce billet. Bonne lecture !
[^] # Re: Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org
Posté par gnumdk (site web personnel) . Évalué à 6.
Mwai, une fois de plus, ca tourne autour du pot...
En clair, si je résume la pensé GNOME: "nous, on fait des spécifications, on la valide et après on code" et chez KDE/Canonical: "on fait une spec, on la code pour voir si ca marche, on la valide".
Je suis désolé, mais je vois pas comment ils font chez GNOME pour valider un truc dont on ne sais absolument pas si cela va fonctionner...
[^] # Re: Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org
Posté par Sébastien Wilmet . Évalué à -1.
Non ce n'est pas ce qui est dit dans le billet.
Ce qui est reproché à Canonical pour libappindicator c'est de ne pas avoir communiqué pendant deux ans et puis d'avoir balancé d'un seul coup tout le code.
Ce qui n'est pas dit dans le billet mais qui est logique de mon point de vue, c'est que GNOME communique beaucoup plus, et dès le début. C'est comme ça que fonctionne le Libre, et c'est comme ça qu'une spécification doit être élaborée.
Par ailleurs, il est dit :
Personne n'est parfait donc.
[^] # Re: Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org
Posté par Albert_ . Évalué à 4.
Gnome communique tellement que leur nouveau systeme de notification il n'y a strictement que eux qui l'utilise. Meme les autres projets tournant autour de Gnome n'en avait pas entendu parler et ont implemente ce qui se trouvait sur fd.o...
Amusant!
# au tour de Mark Shuttleworth
Posté par Albert_ . Évalué à 2.
http://www.markshuttleworth.com/archives/654
[^] # Re: au tour de Mark Shuttleworth
Posté par Sébastien Wilmet . Évalué à 1.
Il y a eu quelques réactions :
[^] # Re: au tour de Mark Shuttleworth
Posté par Albert_ . Évalué à 2.
La reponse de Aaron:
http://aseigo.blogspot.com/2011/03/shoot-messenger.html
En resume cela consiste a dire que les attaques "ad hominem" il en a un peu marre et que pour lui le probleme majeur que cela entraine c'est au niveau des utilisateurs chose que les gnomistes oublient volontiers (probablement que le fait d'avoir ete cree pour contrer KDE et visiblement de continuer sur cette ligne cela n'aide pas. C'est moi et les autres je m'en tape. C'est un peu triste de voir cela dans le logiciel libre car ce genre de comportement et de refus d'utilisation de normes et de creation de sa propre norme c'est plus dans le style de la boite de redmond ou de cupertino...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.