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 rewind (Mastodon) . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. É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.