Journal Gnome vs Canonical: l'avis de Aaron Seigo

Posté par (page perso) . Licence CC by-sa
Tags :
28
8
mar.
2011

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 . É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 (page perso) . É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 . Évalué à 8.

        Non parce si on s'en tient aux faits

        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.

        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".

        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).

        Qu'est ce que tu appelles "réécrire l'histoire" ?

        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 . Évalué à 9.

          un foetus de spécification

          Le journal contre l'avortement, c'est pas ici !

        • [^] # Re: Lire le billet original de Dave Neary (encore lui !) avant

          Posté par . É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 . Évalué à 4.

            arglll lire DCOP a la place de DCONF naturellement...

          • [^] # Re: Lire le billet original de Dave Neary (encore lui !) avant

            Posté par . Évalué à -3. Dernière modification le 09/03/11 à 16:08.

            Tu vas peut etre nous citer une normalisation faite par KDE que GNOME a implemente?

            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.

            DCONF -> DBUS en est le meilleur exenple

            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.

            Mais peut etre que les devs de KDE sont tous des cons et sont incapables de normaliser un truc pour l'ensemble des bureaux?

            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 . É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 . Évalué à 3.

                DBUS est si complique que KDE a fait un QDBUS pour retrouver la simplicite et la puissance de DCOP!

                1. l'implémentation de référence de D-Bus est volontairement bas-niveau pour faciliter l'écriture de wrappers. De même GNOME a développé dbus-glib et maintenant GDBus (intégré à la GLib).
                2. QDBus est un wrapper de libdbus, pas une réimplémentation.
                3. mauvais exemple

                J'attend le nom de technos KDE que Gnome a reutilise dans les 5/6 ans

                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.

                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.

                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.

                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

                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 . É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 . Évalué à 2.

                    premiere proof-of-concept je trouve cela tres tres normal

                    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.

                    car justement ils n'ont pas pris a partir de KDE mais a partir de Apple

                    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/

                    et cela date de plus de 5 ans non?

                    Au plus tôt 2007

                    les tres celebres network-manager

                    Ça n'a jamais été proposé en tant que spécification.

                    (que je trouve tout pourris par rapport a Wicd par exemple)

                    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.

                    et surtout pulseaudio

                    1. tu noteras que de base PA n'a aucune dépendances spécifiques à GNOME (je te mets au défi de trouver un composant directement issus de KDE qui n'ait pas de dépendances lourdes à celui-ci) ce qui facilite son adoption par d'autres.
                    2. la très grande majorité des problèmes de PA sont dûs ALSA et aux pilotes.
                    3. GNOME n'a pas plus son mot à dire dans le développement de PA que KDE, le terroriste Lennart est le seul au commande.
                    4. il n'y a pas d'alternatives à PA (j'anticipe: Jack et PA n'ont juste pas du tout la même cible d'utilisateurs).
                    5. ça n'a jamais été proposé en tant que spécification.

                    je nomme ces projets pour donner des exemples de projet Gnome qui ont ete force sans aucune discussion avec qui que ce soit.

                    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 . Évalué à 3.

                      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/

                      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.

                      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.

                      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 (page perso) . É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 !

                        DCOP etait trop KDE oriente du coup cela a ete CORBA avec le succes que l'on connait

                        Il y a de quoi rire aussi :

                        Et niveau protocole ils ont aussi pris les icones

                        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 . É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 . Évalué à 10.

                          Parmis les reponses du blog de Aaron on trouve cela:

                          OK, now I'm back, I'd just like to inform some of you that YOU ARE MISSING THE POINT ENTIRELY. The point isn't "We said it first!", the point is that both GNOME and KDE wanted to re-design the spec., KDE created a working implementation, then took the critisisms of GNOME and fixed them as well as implementing new features for the sole purpose of satisfying the GNOME developers and making a single, unified cross-platform system-tray specification and now, GNOME is doing their own thing.

                          The point is that KDE could have decided to completely ignore GNOME and implement a system tray specification that depended on KDE technology or was specific to the KDE workspace in some way, but they chose to talk to the GNOME developers and worked on the specification to fit their needs and now, GNOME is implementing their own, GNOME-specific technology that is incompatible. GNOME apps using the GNOME 3 system tray specification won't have consistent system tray behaviour in KDE, and KDE apps won't have consistent system tray behaviour in GNOME, for absolutely no reason except because GNOME doesn't want to use KDE's work, even after KDE designed the specification to GNOME's wishlist, for all intents and purposes.

                          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 . É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 . Évalué à -3.

                        c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre

                        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 ?

                        Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.

                        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.

                        Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango.

                        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.

                        L'un comme l'autre ont été imposé par GNOME.

                        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.

                        Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues.

                        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 (page perso) . Évalué à 4.

                          Je ne crois pas que KDE fasse plus que GNOME à ce niveau.

                          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 (page perso) . Évalué à 4.

                          Du coup, ça expliquerait pas mal de choses, c'est juste qu'ils ont pas compris comment fd.o fonctionne !

                          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...

                          nan mais McCann est un "designer" tu comprends, il sait tout mieux que nous et on a plus le droit de rien dire

                          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 . Évalué à 5.

                          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.

                          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.

                          tu gères comment la dépendance circulaire, si on doit jouer au zero sum entre GLib et QtCore ?

                          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.

                          GStreamer est le seul framework multimédia potable sous *nix

                          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.

                          Pango n'est pas hébergé par FreeDesktop ni même utilisé par Qt ou KDE.

                          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.

                          Par ailleurs, GStreamer est né en dehors de GNOME et a une vie indépendamment de celui-ci.

                          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.

                          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

                          Tu veux dire "faire comme les devs GNOME" ?

                          • [^] # Re: Lire le billet original de Dave Neary (encore lui !) avant

                            Posté par . Évalué à 1. Dernière modification le 10/03/11 à 13:40.

                            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

                            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.

                            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.

                            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.

                            Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là

                            Ce ne sont PAS des frameworks multimédias ! (du moins pas aussi complet que GStreamer dans le cas de Xine)

                            • Xine a un champs d'action beaucoup plus réduit que GStreamer, il est clairement passé en mode maintenance et son architecture peu modulaire n'aide pas à sa diffusion.
                            • MPlayer est un gloubiboulga qui fait lecteur (certes, il le fait très bien!)
                            • FFmpeg une collection de codecs et de petits programmes. KDE a développé Phonon parce que GStreamer n'offrait pas suffisamment de garantie de stabilité d'API/ABI (GStreamer 0.10 est sortie en 2006, et on peut installer en parallèle plusieurs versions), FFmpeg c'est pire, bien pire, encore bien plus pire que ça.

                            comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques

                            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 ?

                            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)

                            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.

                            même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies 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.

                            Tu veux dire "faire comme les devs 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 . Évalué à 4.

                              Mais bien sur les trois trucs suivant ont ete fait en collaboration avec KDE avant toute implementation...

                              • NM
                              • Gstreamer aussi d'ailleurs ca c'est bien le truc qui a ete fourre aux utilisateurs sans veritables raisons alors que a l'epoque xine, mplayer, vlc existait et gstreamer il a fallu des annees avant que cela soit capable de lire un dvd mais bon c'etait tout de meme le truc utilisait par gnome...
                              • PA fonctionnait (comme NM) chez toi sous Fedora mais pas chez tout le monde non. Ubuntu l'a integre comme un cochon ca c'est clair mais bon il a fallu bien des annees avant que l'on trouve efin une utilite qui fonctionne par rapport a Alsa c'est le truc avec le bluetooth.
                              • [^] # Re: Lire le billet original de Dave Neary (encore lui !) avant

                                Posté par (page perso) . É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 . Évalué à 3. Dernière modification le 09/03/11 à 20:24.

                      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.

                      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:

                      sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
                      sudo /etc/dbus-1/event.d/26NetworkManager stop
                      

                      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 . Évalué à 10.

          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.

          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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 1.

    Tout se trouve sur ce billet. Bonne lecture !

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org

      Posté par (page perso) . É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 (page perso) . É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 :

        The main complaint from Seigo on his blog is that GNOME is deviating from freedesktop.org standards consistently in the last few years and this is unhealthy for cross desktop applications. […] It remains to be seen if this is the personal opinion of Seigo or if the KDE Board/Project too feels the same.

        Personne n'est parfait donc.

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

        • [^] # Re: Petit résumé du troll GNOME-Canonical-KDE-Freedesktop.org

          Posté par . É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 . Évalué à 2.

    http://www.markshuttleworth.com/archives/654

    What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

    • [^] # Re: au tour de Mark Shuttleworth

      Posté par (page perso) . Évalué à 1.

      Il y a eu quelques réactions :

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: au tour de Mark Shuttleworth

        Posté par . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.