Philippe F a écrit 2217 commentaires

A mon avis, c'est a l'etat d'idee. Genre, "si on le fait, on le fera comme ca", parce que les hackers n'ont pas envie de repartir de zero et d'oublier toutes les fignolages qu'ils ont glisses dans DCOP.

> DBUS n'a pas pour vocation de remplacer DCOP

Ben si. Ca fait exactement la meme chose, sauf que en plus, ca s'interface a HAL, ca ne depend pas de libice et donc de X11, et ca ne gere pas les petits plus de dcop pour l'integration dans Qt/KDE.

> L'usage de DBUS/HAL est actuellement ici :
> - NetworkManager
Ca veut dire quoi ?

> - bluez
connait pas.

> - cups
Ah, KDE utilise kpart et dcop pour ca.

> - desktop-printing
Je sais pas ce que c'est mais j'imagine que c'est l'equivalent de kprint. Je pense que KDE s'interface directement avec cups pour ca et qu'il n'y a pas besoin de DCOP.

> - gnome-volume-manager (Gnome)
Il me semble, mais ca serait a confirmer que cette information est lue directement par le systeme et qu'il n'y a pas besoin de framework de comm pour ca. Si il y en a un, c'est forcement dcop.

Comme tu vois, DCOP est deja la ou DBUS aura sa place. C'est donc pas facile de remplacer l'un par l'autre.

> - D-BUS supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a
> per-user-login-session daemon (for general IPC needs among user applications).

DCOP n'est que un serveur per-login-session dans KDE. En revanche, la gestion de la queue de l'imprimante est fait directement par cups il me semble, et je suis surpris de voir qu'il faut HAL + DBUS pour faire ca .

> Si KDE était plus "motivé", cette partie "system daemon" serait deja integree

Ben voyons, t'imagines que ca se fait tout seul ? Ca prend du temps et si c'est arrive dans Gnome 2.8, c'est parce que des gens ont passe beaucoup de temps a bosser dessus.

Pour ce qui est de cups, KDE l'utilise depuis longtemp (bien avant Gnome) et je vois pas trop ce que DBUS va apporter a ca.

> DBUS n'a pas les mêmes fonctionnalités/objectifs que DCOP.

C'est pas tout a fait vrai. DBUS est un framework de communication tres similaire a DCOP dans ses fonctionnalites, qui a ete modele d'apres DCOP en partie, pour pouvoir a terme le remplacer et pour repondre au meme besoin.

DCOP presente l'inconvenient de dependre de je-sais-plus-quelle-lib X11 pour sa communication. Note que c'est un exemple ou contrairement a ce que tu affirmes, KDE s'est appuye sur une techno existante.

Si DBUS peur remplacer completement DCOP a terme, c'est bien parce qu'ils servent a la meme chose. Maintenant, DBUS a plusieurs avantages sur DCOP, c'est d'une part qu'il a moins de dependances, d'autres part qu'il s'integre avec HAL pour nous faire des choses sympatiques. Note que ces dernieres fonctionnalites ne sont pas stable (je suis d'ailleurs etonne que tu me dises que c'est deja utilise dans Gnome, je n'etais pas au courant).

Donc DBUS integre a HAL, ca fait plus que DCOP et c'est pour ca que j'espere que KDE va y passer. Maintenant, tu ne remplaces pas une techno stable depuis 3 ans qui a fait ses preuves et est parfaitement integre par une techno pas encore tout a fait stable, encore relativement peu utilise et qui presente des inconvenients (DCOP gere les signaux et slot de facon tres pratique) sans reflechir attentivement a l'impact que ca va avoir dans KDE.

Meme si tous les hackers de KDE etaient a fond pour DBUS, ils ne pourraient pas le faire rentrer demain dans KDE. L'utilisation de DBUS va casser la compabilite binaire de KDE, et n'est donc possible que pour KDE 4.


> - gstreamer : framework multimédia, le serveur est/sera MAS
> - DBUS : serveur
> - HAL : serveur

> Tout ça, KDE ne l'a pas.

HaL, personne ne l'a puisque ca date de cette annee. DBUS, KDE avait une equivalent qui remplissait tres bien la tache mais qui n'est pas integre a HAL (qui de fait n'existait pas jusqu'a il y a peu). Pour gstreamer, KDE avait une solution merdique mais presente de puis longtemp.

Malgre la meilleure volonte du monde, on ne peut pas faire rentrer ces technos dans KDE en quelques semaines. Elles sont rentrees plus facilement dans Gnome car c'est la qu'elles ont ete developpees initialement.

> Ben dans les fait, ce n'est pas toujours vérifié.

Ben si, la volonte de KDE est verifiee dans les faits, cf le titre de la news. Maintenant, ce n'est pas verifie dans les faits qui semblent te tenir a coeur, mais je pense que tu as tort d'interprter ca comme une volonte de KDE de ne pas vouloir aller dans cette direciton. Il faut juste plus de temps.

> Gnome puise le maximum de technologies de freedesktop.

L'initiative a ete fondee par des hackers de Gnome, donc c'est clair que Gnome a eu initialement une meilleure entree dans le projet.

> KDE, il faut les motiver pour qu'ils participent à freedesktop (lecture forcement recommendée) :

J'ai lu ledit document mais je ne vois pas ou tu lis que KDE n'est pas motive pour participer aux developpements des standarts de freedesktop. Au contraire, KDE participe et a integre des technos freedesktop. En general, ca s'est fait tres rapidement. Par exemple, la spec pour les menus a ete integree en moins d'un mois par Waldo Bastian (suite aux initiatives de Redhat qui l'a fait sans retourner le code a KDE ou sans meme prevenir le projet). La semaine derniere, David Faure a pousse au redeveloppement d'une spec pour la gestion de la poubelle qui est par les faits deja implementee dans KDE.

La ou evidemment, ca pose plus de problemes, c'est pour les technologies de freedesktop qui viennent en concurrence de technologie KDE, lesquelles sont en general anterieures a l'existence de freedesktop ou des projets souc-jacents: arts, dcop, ...

Mais contrairement a ce que tu dis, il y a des gens tres motives chez KDE pour plus d'integration. Il faut lire le blog de Zack pour comprendre que ce projet, c'est bien plus que l'integration de Gecko dans Konqueror, Zack souhaite que Firefox deviennent un citoyen KDE et va donc travailler sur d'autres zones de l'integration.

Zack n'en est d'ailleurs pas a son premier projet, il a aide sodipodi a faire l'integration de la boucle d'evenement Qt dans Gtk, permettant a une application Gtk d'utiliser des dialogues KDE (http://developer.kde.org/documentation/tutorials/qtgtk/main.html(...))

Il s'agit d'un fork mais il y a des echanges reguliers dans les deux sens. Ils ne partagent pas le meme CVS en revanche, ce qui fait que les contributions doivent etre comittees explicitement des deux cotes.

Je parlais de documents publies avant l'existence du brevet. Evidemment que le brevet est publie, c'est une des contreparties essentielles de son existence.

Moi, j'avoue que j'ai du mal a imaginer comment ils vont gagner tant de l'argent. Vu la difficulte technologique du truc (optimiser X comme un malade), avec un client libre sous linux, un client gratuit sous windows, un serveur libre sous linux, il reste peu d'interet d'achter la version payante. Surtout que sous linux, l'interet peut etre d'avoir un 10 serveurs tournant sur la meme machine, servant 10 clients. Mais sous windows, il n'y a qu'un seul utilisateur actif par machine, donc le serveur n'a qu'un interet hyper limite (comme vnc quoi).

Pour moi, la question c'est plutot :
quels sont les problemes avec www.openoffice.org ? Pourquoi y a-t-il besoin d'un serveur separe ?

Et il y avait eu des menaces du cote de valgrind ? Comme il s'appuie sur pas mal de trucs publies, il se peut que les brevets ne valent pas un clou.

J'ai pas encore eu le temps d'evaluer la solution mais gcov semble avoir l'inconvenient enorme d'ecraser les fichiers de couverture existant. Dans mon fonctionnement, j'ai besoin de faire une dizaine de run avec des programmes de tests differents pour en deduire la couverture du code. gcov n'a pas l'air de supporter ce concept et fonctionne en mode oneshot.

Puisqu'on est dans les outils C++, j'ai eu besoin d'un outil pour controler la couverture de code de mes test. J'ai ete surpris de voir que valgrind ne faisait pas ca, mais on trouve des choses quand meme du cote du libre:

http://covtool.sourceforge.net/(...)

> Il y a des compilateurs C++ qui convertissent le C++ en code C puis le passent à un compilateur C "normal".

Ouai, en 1979, c'est comme ca qu'on faisait un compilateur C++. Bienvenue dans le nouveau millenaire.

La richesse syntaxique du C++ permet au compilateur de mieux comprendre l'intention du programmeur et d'y faire des optimisations specifiques.

En faisant un framework objet en C, tu perds toutes ces optimisations faites par le compilateur et tu dois te palucher bien plus de code a la main.

Sinon, je tiens a defendre ton point de vue : le choix de gnome de faire du C se defend, notamment du point de vue des bindings. L'autre argument, c'etait tout simplement la disponibilite de Gtk bien qu'en y repensant, wxWindows devait etre deja disponible.

L'argument du C++ mal supporte n'est pas genial : d'une part, Qt s'en sortait donc il n'y a pas de raison que Gtk en s'en sort pas non plus. D'autre part, un projet comme Gnome vise sur le long terme et peut compter sur l'amelioration des compilateurs.

Je pense personellement que ce n'etait pas un bon choix parce qu'une appli graphique est fondamentalement objet et qu'il semble des lors plus approprie de choisir un langage dont la caracteristique objet fait partie du coeur.

Sinon, on peut faire de l'objet en assembleur.

Le binding C est genere automatiquement. Ce n'est pas un binding pour utilisateurs, contrairement aux premieres versions de Qtc. C'est pour ca que je dis qu'il n'y a pas de "binding C".

J'utilise PyQt tous les jours dans des applis professionelles.

Qt# s'est casse la gueule vu que c'etait justement une horreur a generer mais en train de repartir.

Il faut lire les blogs KDE pour voir l'apparente facilite de KDE + Qt avec le binding javascript.

rubyQt a la faveur de Richard Dale, donc je pense qu'on va le voir avancer pas mal.

perlQt a ete ecrit uniquement par David Faure, pour tenter de convaincre les developpeurs des outils mandrake de passer de perlGtk a perlQt. Honnetement, je pense que faire du perl avec du Qt, c'est un peu comme se mettre la tete dans un vide-ordure.

> Je ne comprends pas qu'on puis discuter ça. gtk+/Gnome a été fait avec les bindings en tête et Qt non.

Ca, c'est indeniable. Maintenant, dans les faits et sur le long terme, je pense que l'approche Gnome ne sera pas la meilleure.

Cela dit, les bindings semblent en effet beaucoup moins utilises que sous Gnome. Du cote KDE, on explique ca par le fait que Qt etant beaucoup plus facile a utiliser que Gtk, les gens ont beaucoup moins ressenti la necessite d'acceder a la lib dans d'autres langages plus facile a manipuler.

Il y a aussi le fait que a premiere vue, les bindings sont plus faciles a generer pour Gtk / Gnome.

Et quand la communaute Gnome se dit qu'il faudrait trouver un langage plus facile pour developper avec Gnome et reflechit a C#, on se marre vu que developper avec KDE est facile (une fois que tu as passe la douloureuse etape de generation des makefile)

Moi ca me gene. Je ne vois pas l'interet d'apprendre une syntaxe par application. A chaque fois que je modifie lilo.conf, j'ai besoin de la page de man. Puis apres c'est ddclient, puis encore une autre pour apache et encore une autre. Heureusement qu'elles se ressemblent deja beaucoup. Seules quelques rares applications tres evoluees ont besoin d'une syntaxe tres specifique (genre mon filtrage du mail avec plein de criteres differents et plein d'actions possibles).

> Mais c'est bien pratique pour stocker des configs complexes.

Et t'as des exemples de config sufisamment complexes pour qu'elles ne puissent pas etre stockes sous forme de cle/valeur + section. Pour info, toutes les applis KDE utilisent ce systeme, ainsi que toutes les applications windows (la base de registre n'est qu'une suite de sections avec des cles et des valeurs). Si ca suffit a toutes ces applications, je pense que c'est suffisant.

Le xml, c'est bien mais faut pas en abuser.

Je vous offre la discussion qui a eu lieu sur freedesktop sur le sujet :
http://freedesktop.org/pipermail/xdg/2004-April/003720.html(...)

En gros, le mec s'est fait allume. En theorie, ca a l'air pas mal et ca repond a un besoin, au moins du point de vue utilisateur. Maintenant, quand on laisse parler les gens qui se sont reellement penches sur le sujet, comme ceux qui s'occupent de gconf, linux registry ne repond pas un certain nombre de problematiques pourtant importantes dans une gestion de configuration globale.

Ah, je ne comprenais pas.

Un autre probleme de la gentoo, c'est qu'elle evolue tres vite et que j'ai parfois des compilations qui foirent, parce que le developpeur a teste avec un systeme parfaitement a jour alors que j'ai quelques versions de retard.

Bon, tout d'abord, il faut preciser que rien n'est C++ friendly. Le C++ est un langage complexe, surtout quand on le taquine un peu.

> De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.

Ah ouai ? Je me demande comment fait KDE pour faire des bindings. Ca doit etre impossible puisqu'il y a besoin du langage C. Va dire ca au mecs qui font PyQt, java for Qt, Qt#, rubyQt, perlQt, il seront content de savoir qu'ils ont besoin de faire du C.

Tu peux interpreter ca comme le fait que je fais expres d'ignorer cet argument parce qu'il me parait plus bancal qu'autre chose.

Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.

> Le C++ à part être "C++ friendly" est assez limité dans ce domaine [des bindings]

La on rentre dans un debat d'expert. Si tu discutes avec des gens qui font les bindings dans KDE et dans Gnome, tu pourras te faire ta propre opinion. La mienne (suite a ce genre de discussion), c'est que l'apparente facilite de generer des bindings en C cache une grande complexite, notamment au niveau de la maintenance. La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.

Ah, je realise qu'il y en effet une grosse confusion de ma part entre glib et gobject. C'est plutot gobject que je critique dans l'absolu.

> Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
> dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?

C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.

Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.

> Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »

C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.

On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.

> Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...

Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.

> > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
> Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...

Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).

> Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser

Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.

Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.

Pourquoi, un kio_slave, c'est mal ?

Je ne penses pas que les conversions glib <-> Qt aient un impact majeur dans ce cas precis. Mais il faut penser au contexte general. Si KDE commence a se lier avec glib, quelles vont etre les consequences. Est-ce que d'autres applications vont l'utliiser aussi, etc.

> Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx =
> developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.

C'est pas tant la glib elle-meme qui est critiquee que le fait qu'elle fasse doublon avec d'une part la stl, d'autre part la QTL.

D'un point de vue personnel, j'admire beaucoup le travail qui a ete fait sur la glib, mais je ne vois pas du tout son interet. Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ? Pourquoi faire du C objet ? Sincerement, j'aime bien coder en C, mais quand je code en C, c'est pas pour faire du C++, c'est pour faire du C. Il y a quand meme une grosse incoherence dans ce choix, qui d'un cote preconise un langage relativement simple et refuse absoluement le C++, et de l'autre cote, s'amuse a refaire un framework objet en C. Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder. On n'en arrive meme a la situation de gtkmm qui wrappe en C++ une lib en C qui emule un comportement objet. Deux niveaux d'indirections !

> Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly

La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet, ce qui est tres souhaitable pour une appli graphique ou tu manipules des tonnes d'objets.

> KDE n'est pas C friendly

Non. Et tu sais quoi ? Ca ne manque a personne.

> > toute dependance n'est jamais la bienvenue

J'aurai de preciser toute dependance qui duplique une fonctionnalite existante. En dehors de l'approche gstreamer, quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?

Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.

Oui, enfin la theorie du compilateur, c'est que les options d'optimisations affectent la vitesse d'execution mais pas le resultat en lui-meme. Dans quelques cas, c'est vrai que si tu utilises -fmachin -fbidule -O27 -archoptimise-a-more , tu peux avoir quelques instabilites que n'a pas celui qui compile en -O2, mais ca ne va pas tres loin.

On n'est pas du tout dans la situation que tu as l'air de decirre, ou chaque mec a des options de compile differentes et obtiens un resultat stable differamment.

Personellement, je trouve tes commentaires assez penible a lire, non pas pour leur contenu, mais parce qu'on dirait que tu t'obstines a ne pas vouloir comprendre ce que disent les autres. C'est comme si tu avais pose un jugement sur les opinions de telle ou telle personne et que tu ne puisses pas envisager qu'il pense autre chose.

> Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.

> 2 - Gstreamer à l'origine cible Gnome.
C'est plus du tout le cas. Et il est aussi tres populaire chez KDE. De toute facon, une appli qui marche est toujours plus populaire qu'une appli qui ne marche pas.

> 1 - Gstreamer utilise glib.

J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.

Ensuite, il faut voir qu'il y a des gens qui n'ont pas glib sur leur PC, tout comme il y a des gens qui n'ont pas Qt sur leur PC. Toute dependance supplementaire n'est _jamais_ bienvenue.

> "j'avance et tu recule, je tourne à droite et je regarde à gauche..

On parle et tu refuses d'ecouter, je pense que tu es aussi tres fort a ce jeu.

Ben, t'as de la chance de pas avoir achete une webcam il y a un mois. Sinont, tu aurais peut-etre prise celle-la puisqu'elle etait supportee.