GeneralZod a écrit 2316 commentaires

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 !

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.

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.

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.

Pour mon édification personnelle, j'aimerais savoir pourquoi ce post a été "inutilité".

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.

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

Lis l'accord (page 3 section 2 plus précisement)
http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

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)

Tu négliges la fameuse poison pill qui permet à la KDE Qt Free Foundation de placer unilatéralement la dernière version disponible de Qt sous une licence type BSD si dans les douze mois qui suivent, aucune mise à jour conséquente de la version libre de Qt n'a été sortie.

Digia n'a aucun intérêt à forker Qt, la version libre faisant office de référence (d'autant plus depuis le passage à la LGPL).

Tu négliges la fameuse poison pill qui permet à la KDE Qt Free Foundation de placer unilatéralement la dernière version disponible de Qt sous une licence type BSD si dans les douze mois qui suivent, aucune mise à jour conséquente de la version libre de Qt n'a été sortie.

Digia n'a aucun intérêt à forker Qt, la version libre faisant office de référence (d'autant plus depuis le passage à la LGPL).

je peux compiler pour Qt 4.3 avec une version 4.7 sans trop de probleme en éliminant les trucs non supportés dans les versions suivantes à cout de #ifdef QT_VERSION

Qt ne garantit que la compatibilité descendante (backward), la compatibilité ascendante (forward) n'a jamais été garantie.

La version Mac Cocoa est disponible et stable.

s/stable/utilisable/ reste quelques bizarreries et problèmes de performances (en grande partie résolu dans Qt 4.8 [1]) pour que ce soit à parité avec les autres plateformes.

[1] http://labs.qt.nokia.com/2011/02/23/alien-widgets-on-mac/

et bonjour aux belles tables d'évènements façon MFC... C'est plus tout à fait vrai, tu as la possibilité de connecter dynamiquement les gestionnaires d'événements à l'aide de méthode Connect. À partir de la version 2.9/3.x, l'utilisation des tables d'événements devient même déconseillée.

Sinon dans l'ensemble, je partage ton avis, wxWidgets est un toolkit complexe, lourdingue et bien crado.

wxWidgets fournit également des fonctionnalités lié aux réseaux, bases de donnée, XML même si il est globalement moins riche que Qt.

en comptant les charges bien sûr (du coup, c'est nettement moins folichon comme salaire).

Je vois pas le rapport ...

Si vous passez par le store amazon via le Banshee d'Ubuntu, 25% des revenus iront à la fondation GNOME, sur n'importe qu'elle autre distribution, 100%. Un lien pour vous rappeler à quel hauteur, Canonical contribue à GNOME. http://linuxfr.org/news/gnome-census-qui-cr%C3%A9e-gnome

---

Sérieusement, c'est une stratégie de Canonical pour déstabiliser les trolleurs du vendredi que de pinailler sur 10k$ (environ deux mois de salaire d'un développeur) qui au final iront à la fondation GNOME ou quoi ? Le projet GNOME et ses contributeurs (hors Canonical) développant 99% du bureau fourni dans Ubuntu ... Mark Shuttleworth est devenu pauvre pour que Canonical s'abaisse à ce genre de manoeuvres ? Le plus drôle c'est que Jono Bacon (aka JobALaCon) propose aux développeurs de Banshee de proposer une extension qui rétablit le comportement original, une alternative à leur propre code, super !

KRH travaille pour Intel actuellement (et il n'est toujours pas payé pour travailler sur Wayland). Jusqu'à présent, l'implication de RedHat dans le projet s'est limité à permettre à certains employés du groupe desktop (entre autre Ray Strode) de consacrer une partie de leur temps de travail sur Wayland il y a quelques temps.

Mis à part Django qui n'est pas basé sur WSGI, le portage des frameworks web majeurs est tributaire de l'avancement du support de python3 par celui-ci. Le moins qu'on puisse dire est que ça traine depuis quelque temps et aucun consensus ne semble s'être fait. http://lucumr.pocoo.org/2010/5/25/wsgi-on-python-3/ http://wsgi.org/wsgi/Python_3

Les avatars nuisent à la lisibilité des fils.

> Dans ce cadre, la normalisation était nécessaire et s'est faite dans les règles.
Faut juste accepter de cracher les royalties demandées par le MPEG pour pouvoir l'utiliser, exit les logiciels libres, les petites structures etc ...

> SI l'ISO ne te suffit pas, je ne sais pas ce qu'il te faut.
au temps pour moi, mais une norme non librement réutilisable, ça vaut pas grand chose ...

> Et donc, qui le prend réellement en charge à part Google ?
Skype le propose déjà en production, GStreamer, FFMPeg, MPlayer, VLC également.

> Tu connais une seule carte nVidia, AMD, TI ou ARM capable aujourd'hui d'accélérer la lecture de WebM
Rockship a sorti la première puce matérielle capable de décoder du webM en début d'année (soit environ 6 mois après la libération de webM), ARM, Broadcom, AMD, TI devraient en sortir cette année ...

> Pourquoi accepter par défaut un codec qui remplit un mot sur deux des principes
Primo, H264 est un standard industriel soutenu par UN consortium industriel et non pas une norme (édicté par un organisme de normalisation).
Secundo, certes webM n'est pas un standard, mais c'est un projet open source qui implique de nombreux acteurs (industriels: nVidia, AMD, ARM, TI, Qualcomm, Rockship etc ..., développeurs: Mozilla, Opera, Gstreamer, FFMPeg, Skype, Logitech, fournisseurs de contenus etc ...). De plus Google a accordé une licence irrévocable et royalty-free des brevets logiciels autour de webM.
Certes, ce n'est pas parfait mais c'est nettement plus clair qu'avec H264 qui après coup, propose une licence gratuite temporaire taillé sur mesures pour les éditeurs de navigateurs web mais envoie chier les fournisseurs de contenus (hein, on parle du web, pas du minitel 2.0, tout le monde est potentiellement un fournisseur de contenu)

> Ouvert ne veut pas dire "non soumis à royalties".

Tu fais exprès ou t'es juste malcomprenant ?
ouvert dans le sens "tout le monde est libre d'utiliser le standard comme bon lui semble et sans aucune restriction".
H264 n'a absolument rien d'un format ouvert, sauf dans le monde // de zenitram.

> le problème de royalties certes même si Mozilla n'aurait pas à payer

C'est drôle, mais ton argumentation n'a pas changé d'un iota depuis le début or tu as toi-même reconnu que cela n'est vrai que depuis le changement du contrat de licence par le MPEG. Je suppose que tu es capable de tordre la réalité voire tu as créé une nouvelle branche de la logique, c'est la seule explication rationnelle (sauf à réfuter l'axiome fondamental régissant l'univers zenitramien: "zenitram n'est jamais de mauvaise foi")

> mais le fait qu'il soit soumis à royalties ne fait pas de ce standard un standard fermé

Dans les univers non-zenitramiens, ça entrave sérieusement l'utilisation de ce standard si on n'est pas une multinationale pété de thunes.

> vous passerez pour des gens n'ayant rien compris à H.264 et son modèle de développement plus qu'ouvert

Mais quel bande de nazistes ces libristes !

> et donc on vous rira au nez avec vos arguments faux

on apprécie l'ironie de ce morceau d'humour pur.

Je veux un navigateur web, pas une liseuse HTML ...