J'y suis aussi (à la SG), et le nom "logitelnet" n'a évidemment rien à voir avec telnet. C'est tout simplement que leur premier service sur Minitel s'appelle "Logitel".
> C'est sur des fonctionnalités comme çà que je demande des arguments "techniques".
KDE dispose de toutes ces fonctionalités, sauf peut-être pour glade, mais Qt3 doit implémenter ça et franchement ça n'est pas bien compliqué à faire (j'ai fait un truc du genre pour la boite pour laquelle je bossais il y a quelques mois - une appli qui générait son UI à partir d'un fichier XML).
Je ne connais pas assez le détails des implémentations respectives pour faire un réel comparatif. Néanmoins, je peux te dire que l'appli KDE "de base" telle que la génère KDevelop ou kapptemplate utilise déjà toutes ces features (sauf kpart), et le développeur n'a pas besoin de s'en soucier (par ex. le premier dialogue d'ouverture de fichier venu est capable d'utiliser ftp ou http). Je ne sais pas si il en est de même pour Gnome.
Par ailleurs, développer en C++ est toujours plus rapide et sur qu'en C, à moins d'être une tanche complète, ou d'avoir un compilo C++ pourri. Les développeurs de KDE ne sont pas des tanches, et g++ n'est pas trop pourri. Donc, par simple statistique, je pense qu'il y a de bonnes chances pour que les versions KDE de ces technos soient mieux implémentées que leur version Gnome.
> Oui, quand je disais que C++ était pseudo objet [...]
OK, sur ce point on est d'accord.
> Or dans bien des projets, l'utilisation des mécanismes objet de C++ est équivalente à ce que fournit la glib au C
Je ne suis pas sur de comprendre ce que tu veux dire. Si tu fais en C++ la même chose que Gnome avec GtkObject/GObject (c'est à dire un petit nombre de classes énormes, et du bon vieux procédural pour le reste), c'est parfaitement inefficace.
> Tu le penses en tant que développeur, pour un projet à toi. Mais ça dépend de chacun et du projet.
Je pense en tant que développeur d'une application "end user" (un éditeur/sequenceur MIDI) qui utilise un environnement de développement fait précisément pour ce genre d'applis (tournant sur un desktop, bien integrées, etc...). Pour autant que je sache, Gnome a exactement les mêmes objectifs, et à mon avis, ayant essayé de développer sous les deux environnements, il n'y a vraiment pas photo pour voir lequel des deux marche le mieux.
Non, ça n'est pas du pseudo-objet. Il y a des langages avec un modèle objet plus évolué (Java), mais C++ n'en est pas moins un langage orienté objet (enfin, "pouvant être orienté objet", si c'est ce que tu voulais dire).
> Faire de l'objet en C n'est un problème que quand on doit implémenter les objets, l'utilisation ne pose pas de problèmes, autrement dit pas de difficultés pour Gnome.
Si, ça pose d'enormes problèmes d'utilisation, parce que c'est plus lourd qu'une classe C++ et des operations simples comme la dérivation ou l'ajout d'une méthode virtuelle sont beaucoup plus complexes qu'en C++.
> Chez Qt on a considéré qu'il était préférable d'avoir un langage proposant des classes, c'est un autre choix, pas moins bon, pas meilleur
Je pense au contraire que c'est clairement un meilleur choix.
> Mais en quoi Gnome est en retard sur KDE? Je parle du "noyau" technique et j'ai bien indiqué plus haut
Du point de vue développement, il n'y a rien sous Gnome que tu ne puisses faire sous KDE plus rapidement et avec moins de lignes de code. Essaie de développer une petite appli sous les 2, tu verras tout de suite. Une étude comparée précise prendrait du temps, mais pour moi la différence a été flagrante.
> Selon le site elle est terminée et utilisée
J'ai été co-mainteneur de Gtk-- pendant près de 3 ans. Crois-moi, c'est un boulot sans fin. La première version "stable" de Gtk-- (wrapper GTK+ uniquement) date de bien plus longtemps que ça, l'annonce récente ne concernait que Gnome-- (wrappers autour des libs Gnome), qui a été démarré en 98 si ma mémoire est bonne... Je ne sais pas si ils n'ont wrappés que les widgets Gnome ou les fonctions comme la gestion de config, etc...
Pour être complet il faudrait wrapper toutes les libs C qui composent Gnome, et il y en a trop. Par ailleurs, une interface wrappée n'est jamais aussi "agréable" qu'une interface C++ native. Ça se passe mieux pour des langages de script comme Perl ou Python, mais pour le C++ c'est flagrant. Ajoute à ça le fait que même au niveau C, l'API est un sacré bordel... bref, je crois qu'il est impossible que Gnome offre jamais une API C++ aussi cohérente et simple à utiliser que Qt/KDE.
A propos des applis dont tu cites les URLs :
gtkmail semble toujours maintenue, mais
- MAM ne fait aucune référence à Gtk-- (ça semble être basé sur Tcl/Tk plutôt)
- Grany (qui est un plus un projet d'université sur les automates cellulaires qu'une vraie appli) ne semble plus maintenu depuis un an (dernière release en aout 2000)
- gensql n'a jamais rien releasé. Par ailleurs, la mailing-list developpeur (gensql-devel) a eu 7 messages seulement pendant toute l'année 2000, tous au mois de mais et concernant un pb avec autoconf, et 3 cette année).
Ne crois pas que la "stabilité" de Gtk-- soit récente, la 1.0 date de mars 99 :
Et depuis tout ce temps, le nombre d'applis développées avec n'a pas dépassé, à ma connaissance, la dizaine. Il y a même eu des defections (des applis C++ qui utilisaient Gtk-- et sont passé à GTK+, comme Terraform et Gnomehack je crois).
> Je ne trouve pas que se soit un plus d'intégrer xml dans une librairie graphique
Et pourtant si. Je pensais comme toi, avant de passer à Qt. Mais une librairie de moins à maintenir dans son build, c'est très appréciable. Chaque fois que tu ajoutes une lib, il n'est pas évident qu'elle soit documentée, maintenue, etc... C'est aussi quelque chose dont on ne se rend compte que lorsqu'on développe vraiment avec la lib en question.
> J'entend des arguments et principalement sur le noyau "technique"
Le principal pb de Gnome est que le modèle objet étant lourd aussi bien à utiliser qu'en terme de perfs, il est rarement employé. Pour Gnome1, les seules "classes" sont des widgets. Vu qu'ils ont depuis extrait GtkObject de GTK pour en faire GObject, je suppose que maintenant il doit y avoir des classes autres que des widgets, mais les pbs de perfs cités dans le mail d'Alex et le fait que de toute façon GObject doit être au moins aussi lourd que GtkObject font penser qu'ils n'ont pas pu le déployer beaucoup.
En comparaison, en C++ il est trivial de faire une classe et ça ne coute pratiquement rien en place mémoire. L'API de KDE est donc beaucoup plus "orientée objet" que celle de Gnome. Regarde les classes non graphiques de KDE : http://developer.kde.org/documentation/library/2.1-api/classref/kde(...)
Tu ne trouvera aucun équivalent pour la plupart d'entres elles chez Gnome.
En résumé, faire une classe en Gnome c'est compliqué, et ça prend pas mal de place mémoire, donc ils ne le font presque jamais. En C++, c'est très simple et c'est quasi-gratuit, donc tu le fais plus volontiers. Le résultat est plus cohérent.
J'ai écrit un petit truc sur l'OO en C, ou j'explique plus en détails les problèmes que j'y vois :
Non, c'est vrai, et ce retard ne fait que s'amplifier. Je suis passé de Gnome a KDE il y a un peu plus d'un an (les premières betas de KDE2), pas seulement pour le desktop mais aussi pour l'environnement de développement. Le fossé entre les deux était déjà impressionnant.
> 1 - techniquement Gnome a des fonctionnalités "sexy" qui finiront par être au point :o)
KDE a les mêmes, elles sont au point et surtout elles sont très faciles à utiliser. J'ai récemment ajouté une interface DCOP à l'appli que je développe. C'était la première fois que je faisais ça, et il m'a fallu 15mn, montre en main, pour le faire. La doc, les exemples, tout était disponible et facile à trouver, et il y a tous les outils qu'il faut (dcopidl, règles de Makefiles) pour te pre-macher le boulot.
> Gtk--/Gnome--, le wrap c++ de gtk+/Gnome est terminé.
Non, il n'est pas terminé. Dès que GTK2 et Gnome2 seront stabilisés, ça sera reparti pour un tour. Et même, Gtk-- n'offre pas toutes les fonctionalités de Qt. Par exemple si tu veux un parser XML, tu l'as avec Qt. Si tu veux utiliser Gtk--, il va falloir prendre libXml, qui est en C, donc la wrapper aussi. De plus Qt reste incomparablement plus simple à utiliser que Gtk--.
> On peut maintenant développer en C, C++, Ada, Perl
Ça fait plusieurs années maintenant que Gnome promet ça, et les wrappers sont tous plus ou moins avancés. Pourtant le fait est qu'il n'y a qu'un très petit nombre d'applis Gnome qui ne soient pas écrites en C, et à ma connaissance aucune "standard" (genre console, client mail ou irc, etc...).
Le coté "multilangage" de Gnome est un doux mythe. En pratique, c'est du bon vieux C 99% du temps.
> Es-t-il possible avec KDE/QT de programmer en Perl, Python ou Php.
Python oui. Perl, je ne suis pas sur mais il me semble que les bindings ne sont plus trop maintenus. Php, non. Sinon il y a aussi Ruby, Java, et j'ai même vu passer un mail de quelqu'un disant qu'il allait démarrer des bindings OCaml.
Mais le plus important c'est qu'ils aient une bonne API C++.
Il me semble au contraire qu'il était très avancé (il y avait déjà eu des beta), et qu'il y a toujours eu plusieurs personnes dessus... Faudrait vérifier, mais j'ai un peu la flemme. :-)
Java a 2 pbs sur le desktop. Les applis graphiques sont assez lourdes en lentes, mais ça s'améliore beaucoup avec les dernières versions du JDK. Mais l'autre pb est qu'il est très facile de "décompiler" du byte-code java vers un code source tout à fait lisible. Pour les applis open-source, ça pose pas de pb, mais pour du propriétaire, ça craint un peu.
Les dernières que j'ai vu passer peu après GUADEC II étaient un API freeze vers fin juillet, et release en décembre 2001, donc tes infos doivent être plus fraiches que les miennes. :-)
Le mail d'Alex semble être une conséquence de ceux-ci. Je suis sur qu'ils arriveront à résoudre tout ça, mais pour tenir leurs dates ça va être dur. Et est-ce que les développeurs d'applis vont suivre...
Et alors, ce ne sont pas des acteurs ? C'est pas leur métier officiel, mais c'est pas loin quand même... :-)
Et puis ils sont toujours plus acteurs qu'Oracle ou WinME ne sont des logiciels libres :-).
Ou alors on peut la refaire moins discutable :
Si le concours du meilleur chien de berger est remporté par un chien de berger, est-ce que ça le ravit aussi ? Et si oui, est-ce qu'il a deprimé en voyant "Babe" ?
Et clairement plus que d'avoir des applis et un système stables, et de ne pas avoir à tout réapprendre parce que, justement, ça ressemble un peu à Windows ?
> voir le prix du "meilleur logiciel libre" remporté par un logiciel libre, ca me ravi énormement.
Et lorsque le prix du meilleur acteur est donné à un acteur, ça te fait pareil ?
> Avant la remise du prix, des rumeurs insinuaient que WindowsME et Oracle 8 étaient les mieux placés pour ce grand prix généraliste, mais je suis heureux et fier de voir que c'est un vrai projet libre qui a gagné.
Sérieusement, j'arrive pas à voir si tu plaisantes ou pas là. :-)
Ou alors c'est le fait que le concours Miss France ait été remporté par un homme qui t'a traumatisé ?
Je n'ai écrit qu'un truc sur Gtk-- (ou alors 2 en comptant celui sur Gnome multilangage) mais je ne pense vraiment pas qu'ils soient la seule cause de la réputation de Gtk--. Depuis que j'ai quitté le projet, j'ai discuté avec 3 ou 4 personnes différentes qui avaient essayé de développer avec et avait laissé tomber, pour en général passer à Qt.
Le fait qu'après plus de 3 ans de développement il n'y ait toujours pas d'application majeure développée avec, que la seule appli "fonctionnelle" (Terraform, http://terraform.sourceforge.net(...)) soit passé depuis à GTK+ (tout en restant écrite en C++), et qu'enfin il y ait plusieurs applis écrites en C++, utilisant GTK+ mais pas Gtk--, tout cela à du jouer un tout petit peu aussi.
> gtkmm a quand même la solide réputation d'être ingérable.
Oh, si peu :-).
> Petit rappel, Eazel avait commencé Nautilus en C++, et au bout de 3 mois ils ont tout foutu à la poubelle pour recommencer en C
Pas exactement. Ils l'ont fait parce qu'on (les leaders de Gnome, Miguel, Havoc, etc...) le leur a demandé. La principale raison invoquée était que la communauté Gnome ne saurait pas bien gerer le fait qu'un composant essentiel comme le file manager soit écrit en C++.
L'autre raison (plus officieuse) était de sérieux problèmes de perfs, le premier prototype prenait dans les 30Mb de mémoire (si je me souviens bien). Mais ils utilisaient une version de Gtk-- datant d'avant toute une séries d'optimisations que Karl Nelson avait fait concernant l'occupation mémoire, donc il est très possible que le pb aurait été moindre avec une version plus récente. Peut-être aurait-il été trop important malgrè tout, mais bon, c'était trop tard pour le savoir.
> Les "pros" se font plaisir en utilisant des langages de programmation à la mode (C++, Java, ...). Sans doute parce qu'ils croient que c'est plus simple et plus rapide.
Oui, certes. Maintenant il manque la partie où tu prouves que tu sais de quoi tu parles. :-)
> mais qui ont besoin d'un petit coup de pouce dans les domaines qu'ils ne maîtrisent pas encore - l'informatique en fait partie. Et c'est là que des logiciels comme Linux sont intéressants.
Oui, là je suis d'accord.
> Tu n'as pas beaucoup d'estime pour ces pays, vrai ?
Pourquoi dis-tu cela ?
> Tu te serais debrouillé avec ton manuel et tes VT100.
La doc n'est pas le point fort des LL... Ceci dit je suis d'accord sur le principe.
> Et là, l'intelligence humaine aurait baissé au point que les gens ne puissent plus faire comme avant et lire la doc ? Ils auraient besoin d'interfaces graphiques wizbang et tout ? Moi, j'y crois pas.
Non, c'est juste que tôt ou tard c'est ce à quoi ils vont être confrontés, parce que le monde industrialisé tourne avec des interfaces graphiques. Donc si ils peuvent très certainement se former à la programmation, il faudra bien qu'ils dépassent bash/vi/make/gcc.
Par ailleurs, ne serait-ce que pour acceder au Web ils vont en avoir besoin aussi.
Et enfin, pour en revenir à la question de départ, imagine qu'Eazel soit allé voir ses financiers en leur disant : "Bonjour, on va sortir Nautilus 6 mois plus tard que prévu, parce qu'il faut le temps de le faire tourner sur les 486 d'un village africain. Ils n'ont pas d'argent, donc il ne pourront jamais acheter les services d'hebergement qu'on offre parallèlement à Nautilus, autrement dit nous allons payer 13 développeurs pendant 6 mois de plus avec l'assurance que ça ne sera pas rentable. Vous voulez bien nous signer un chèque ?"
A ton avis, ils auraient signé ?
> Ceci parce que Linux est très adapté à tourner sur des PDA/embarqués etc. Autrement dit : parce qu'il est optimisé.
Non, parce qu'il est modulaire et surtout que les PDAs sont devenus très puissants. Les OS embarqués sont en général bien plus petits que Linux.
> Sincèrement, je viens du monde Atari, pour moi perdre des mégaoctets de RAM et des millions de cycles processeur pour rien, c'est sacrilège
Tu veux parler de l'Atari 512 ST ? Cet engin avec un CPU de la mort mais avec un OS si mal foutu qu'il fallait 512K pour faire péniblement tourner un pseudo-finder à peine mieux que le MouseDesk que je lançais sur mon //e avec 128K ? Tu plaisantes j'espère. :-)
> mais la mécanique derrière est foireuse. Je trouve ça vraiment dommage...
Ceux qui faisaient de l'assembleur ont dit ça à ceux qui faisaient du C. Ceux qui faisaient du C ont dit ça à ceux qui faisaient du C++. Ceux qui font du C++ disent ça à ceux qui font du Java...
[^] # Re: Konqueror : le MSIE de Linux ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview des développeurs de Konqueror. Évalué à 2.
[^] # Re: Les faits sont tetus
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Problème avec le projet Gnome?. Évalué à 1.
Par ailleurs, il y a des gens qui font du temps réel en C++ et même en Java :-).
[^] # Re: bouge ton Gnome.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
KDE dispose de toutes ces fonctionalités, sauf peut-être pour glade, mais Qt3 doit implémenter ça et franchement ça n'est pas bien compliqué à faire (j'ai fait un truc du genre pour la boite pour laquelle je bossais il y a quelques mois - une appli qui générait son UI à partir d'un fichier XML).
Je ne connais pas assez le détails des implémentations respectives pour faire un réel comparatif. Néanmoins, je peux te dire que l'appli KDE "de base" telle que la génère KDevelop ou kapptemplate utilise déjà toutes ces features (sauf kpart), et le développeur n'a pas besoin de s'en soucier (par ex. le premier dialogue d'ouverture de fichier venu est capable d'utiliser ftp ou http). Je ne sais pas si il en est de même pour Gnome.
Par ailleurs, développer en C++ est toujours plus rapide et sur qu'en C, à moins d'être une tanche complète, ou d'avoir un compilo C++ pourri. Les développeurs de KDE ne sont pas des tanches, et g++ n'est pas trop pourri. Donc, par simple statistique, je pense qu'il y a de bonnes chances pour que les versions KDE de ces technos soient mieux implémentées que leur version Gnome.
[^] # Re: Les faits sont tetus
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Problème avec le projet Gnome?. Évalué à 1.
OK, sur ce point on est d'accord.
> Or dans bien des projets, l'utilisation des mécanismes objet de C++ est équivalente à ce que fournit la glib au C
Je ne suis pas sur de comprendre ce que tu veux dire. Si tu fais en C++ la même chose que Gnome avec GtkObject/GObject (c'est à dire un petit nombre de classes énormes, et du bon vieux procédural pour le reste), c'est parfaitement inefficace.
> Tu le penses en tant que développeur, pour un projet à toi. Mais ça dépend de chacun et du projet.
Je pense en tant que développeur d'une application "end user" (un éditeur/sequenceur MIDI) qui utilise un environnement de développement fait précisément pour ce genre d'applis (tournant sur un desktop, bien integrées, etc...). Pour autant que je sache, Gnome a exactement les mêmes objectifs, et à mon avis, ayant essayé de développer sous les deux environnements, il n'y a vraiment pas photo pour voir lequel des deux marche le mieux.
[^] # Re: Les faits sont tetus
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Problème avec le projet Gnome?. Évalué à 1.
Non, ça n'est pas du pseudo-objet. Il y a des langages avec un modèle objet plus évolué (Java), mais C++ n'en est pas moins un langage orienté objet (enfin, "pouvant être orienté objet", si c'est ce que tu voulais dire).
> Faire de l'objet en C n'est un problème que quand on doit implémenter les objets, l'utilisation ne pose pas de problèmes, autrement dit pas de difficultés pour Gnome.
Si, ça pose d'enormes problèmes d'utilisation, parce que c'est plus lourd qu'une classe C++ et des operations simples comme la dérivation ou l'ajout d'une méthode virtuelle sont beaucoup plus complexes qu'en C++.
> Chez Qt on a considéré qu'il était préférable d'avoir un langage proposant des classes, c'est un autre choix, pas moins bon, pas meilleur
Je pense au contraire que c'est clairement un meilleur choix.
[^] # Re: bouge ton Gnome.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
Je pensais l'avoir fait, a propos des arguments sur le noyau "technique".
> S'il y a une réponse, je ne veux pas la connaitre ...
Pourquoi demander alors ? :-)
[^] # Re: bouge ton Gnome.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
Du point de vue développement, il n'y a rien sous Gnome que tu ne puisses faire sous KDE plus rapidement et avec moins de lignes de code. Essaie de développer une petite appli sous les 2, tu verras tout de suite. Une étude comparée précise prendrait du temps, mais pour moi la différence a été flagrante.
> Selon le site elle est terminée et utilisée
J'ai été co-mainteneur de Gtk-- pendant près de 3 ans. Crois-moi, c'est un boulot sans fin. La première version "stable" de Gtk-- (wrapper GTK+ uniquement) date de bien plus longtemps que ça, l'annonce récente ne concernait que Gnome-- (wrappers autour des libs Gnome), qui a été démarré en 98 si ma mémoire est bonne... Je ne sais pas si ils n'ont wrappés que les widgets Gnome ou les fonctions comme la gestion de config, etc...
Pour être complet il faudrait wrapper toutes les libs C qui composent Gnome, et il y en a trop. Par ailleurs, une interface wrappée n'est jamais aussi "agréable" qu'une interface C++ native. Ça se passe mieux pour des langages de script comme Perl ou Python, mais pour le C++ c'est flagrant. Ajoute à ça le fait que même au niveau C, l'API est un sacré bordel... bref, je crois qu'il est impossible que Gnome offre jamais une API C++ aussi cohérente et simple à utiliser que Qt/KDE.
A propos des applis dont tu cites les URLs :
gtkmail semble toujours maintenue, mais
- MAM ne fait aucune référence à Gtk-- (ça semble être basé sur Tcl/Tk plutôt)
- Grany (qui est un plus un projet d'université sur les automates cellulaires qu'une vraie appli) ne semble plus maintenu depuis un an (dernière release en aout 2000)
- gensql n'a jamais rien releasé. Par ailleurs, la mailing-list developpeur (gensql-devel) a eu 7 messages seulement pendant toute l'année 2000, tous au mois de mais et concernant un pb avec autoconf, et 3 cette année).
Ne crois pas que la "stabilité" de Gtk-- soit récente, la 1.0 date de mars 99 :
http://gtkmm.sourceforge.net/release_notes.html(...)
Et depuis tout ce temps, le nombre d'applis développées avec n'a pas dépassé, à ma connaissance, la dizaine. Il y a même eu des defections (des applis C++ qui utilisaient Gtk-- et sont passé à GTK+, comme Terraform et Gnomehack je crois).
> Je ne trouve pas que se soit un plus d'intégrer xml dans une librairie graphique
Et pourtant si. Je pensais comme toi, avant de passer à Qt. Mais une librairie de moins à maintenir dans son build, c'est très appréciable. Chaque fois que tu ajoutes une lib, il n'est pas évident qu'elle soit documentée, maintenue, etc... C'est aussi quelque chose dont on ne se rend compte que lorsqu'on développe vraiment avec la lib en question.
> J'entend des arguments et principalement sur le noyau "technique"
Le principal pb de Gnome est que le modèle objet étant lourd aussi bien à utiliser qu'en terme de perfs, il est rarement employé. Pour Gnome1, les seules "classes" sont des widgets. Vu qu'ils ont depuis extrait GtkObject de GTK pour en faire GObject, je suppose que maintenant il doit y avoir des classes autres que des widgets, mais les pbs de perfs cités dans le mail d'Alex et le fait que de toute façon GObject doit être au moins aussi lourd que GtkObject font penser qu'ils n'ont pas pu le déployer beaucoup.
En comparaison, en C++ il est trivial de faire une classe et ça ne coute pratiquement rien en place mémoire. L'API de KDE est donc beaucoup plus "orientée objet" que celle de Gnome. Regarde les classes non graphiques de KDE :
http://developer.kde.org/documentation/library/2.1-api/classref/kde(...)
Tu ne trouvera aucun équivalent pour la plupart d'entres elles chez Gnome.
En résumé, faire une classe en Gnome c'est compliqué, et ça prend pas mal de place mémoire, donc ils ne le font presque jamais. En C++, c'est très simple et c'est quasi-gratuit, donc tu le fais plus volontiers. Le résultat est plus cohérent.
J'ai écrit un petit truc sur l'OO en C, ou j'explique plus en détails les problèmes que j'y vois :
http://www.telegraph-road.org/writings/oo_in_any_language_myth.html(...)
[^] # Re: bouge ton Gnome.
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
Non, c'est vrai, et ce retard ne fait que s'amplifier. Je suis passé de Gnome a KDE il y a un peu plus d'un an (les premières betas de KDE2), pas seulement pour le desktop mais aussi pour l'environnement de développement. Le fossé entre les deux était déjà impressionnant.
> 1 - techniquement Gnome a des fonctionnalités "sexy" qui finiront par être au point :o)
KDE a les mêmes, elles sont au point et surtout elles sont très faciles à utiliser. J'ai récemment ajouté une interface DCOP à l'appli que je développe. C'était la première fois que je faisais ça, et il m'a fallu 15mn, montre en main, pour le faire. La doc, les exemples, tout était disponible et facile à trouver, et il y a tous les outils qu'il faut (dcopidl, règles de Makefiles) pour te pre-macher le boulot.
> Gtk--/Gnome--, le wrap c++ de gtk+/Gnome est terminé.
Non, il n'est pas terminé. Dès que GTK2 et Gnome2 seront stabilisés, ça sera reparti pour un tour. Et même, Gtk-- n'offre pas toutes les fonctionalités de Qt. Par exemple si tu veux un parser XML, tu l'as avec Qt. Si tu veux utiliser Gtk--, il va falloir prendre libXml, qui est en C, donc la wrapper aussi. De plus Qt reste incomparablement plus simple à utiliser que Gtk--.
> On peut maintenant développer en C, C++, Ada, Perl
Ça fait plusieurs années maintenant que Gnome promet ça, et les wrappers sont tous plus ou moins avancés. Pourtant le fait est qu'il n'y a qu'un très petit nombre d'applis Gnome qui ne soient pas écrites en C, et à ma connaissance aucune "standard" (genre console, client mail ou irc, etc...).
Le coté "multilangage" de Gnome est un doux mythe. En pratique, c'est du bon vieux C 99% du temps.
> Es-t-il possible avec KDE/QT de programmer en Perl, Python ou Php.
Python oui. Perl, je ne suis pas sur mais il me semble que les bindings ne sont plus trop maintenus. Php, non. Sinon il y a aussi Ruby, Java, et j'ai même vu passer un mail de quelqu'un disant qu'il allait démarrer des bindings OCaml.
Mais le plus important c'est qu'ils aient une bonne API C++.
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 2.
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
"Is GNOME 2 dead ?", M. Baulig :
http://mail.gnome.org/archives/gnome-2-0-list/2001-August/msg00282.(...)
"The Gnome-libs wars", Christian Schaller :
http://mail.gnome.org/archives/gnome-2-0-list/2001-August/msg00280.(...)
Le mail d'Alex semble être une conséquence de ceux-ci. Je suis sur qu'ils arriveront à résoudre tout ça, mais pour tenir leurs dates ça va être dur. Et est-ce que les développeurs d'applis vont suivre...
[^] # Re: Concurrence = Equilibre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche SUN présente son nouveau Star Office 6. Évalué à 1.
http://mail.gnome.org/archives/gnome-2-0-list/2001-August/msg00400.(...)
[^] # Re: Amplement mérité
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
Et puis ils sont toujours plus acteurs qu'Oracle ou WinME ne sont des logiciels libres :-).
Ou alors on peut la refaire moins discutable :
Si le concours du meilleur chien de berger est remporté par un chien de berger, est-ce que ça le ravit aussi ? Et si oui, est-ce qu'il a deprimé en voyant "Babe" ?
[^] # Re: Amplement mérité
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
[^] # Re: Amplement mérité
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
Et lorsque le prix du meilleur acteur est donné à un acteur, ça te fait pareil ?
> Avant la remise du prix, des rumeurs insinuaient que WindowsME et Oracle 8 étaient les mieux placés pour ce grand prix généraliste, mais je suis heureux et fier de voir que c'est un vrai projet libre qui a gagné.
Sérieusement, j'arrive pas à voir si tu plaisantes ou pas là. :-)
Ou alors c'est le fait que le concours Miss France ait été remporté par un homme qui t'a traumatisé ?
[^] # Re: Amplement mérité
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
[^] # Re: Pour aider a ta reflexion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KOffice-1.1 est sortie. Évalué à 1.
Je n'ai écrit qu'un truc sur Gtk-- (ou alors 2 en comptant celui sur Gnome multilangage) mais je ne pense vraiment pas qu'ils soient la seule cause de la réputation de Gtk--. Depuis que j'ai quitté le projet, j'ai discuté avec 3 ou 4 personnes différentes qui avaient essayé de développer avec et avait laissé tomber, pour en général passer à Qt.
Le fait qu'après plus de 3 ans de développement il n'y ait toujours pas d'application majeure développée avec, que la seule appli "fonctionnelle" (Terraform, http://terraform.sourceforge.net(...)) soit passé depuis à GTK+ (tout en restant écrite en C++), et qu'enfin il y ait plusieurs applis écrites en C++, utilisant GTK+ mais pas Gtk--, tout cela à du jouer un tout petit peu aussi.
[^] # Re: BIENTOT LA SORTIE DE STARO OFFICE 6 !!!
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KOffice-1.1 est sortie. Évalué à 1.
[^] # Re: Pour aider a ta reflexion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KOffice-1.1 est sortie. Évalué à 1.
Oh, si peu :-).
> Petit rappel, Eazel avait commencé Nautilus en C++, et au bout de 3 mois ils ont tout foutu à la poubelle pour recommencer en C
Pas exactement. Ils l'ont fait parce qu'on (les leaders de Gnome, Miguel, Havoc, etc...) le leur a demandé. La principale raison invoquée était que la communauté Gnome ne saurait pas bien gerer le fait qu'un composant essentiel comme le file manager soit écrit en C++.
L'autre raison (plus officieuse) était de sérieux problèmes de perfs, le premier prototype prenait dans les 30Mb de mémoire (si je me souviens bien). Mais ils utilisaient une version de Gtk-- datant d'avant toute une séries d'optimisations que Karl Nelson avait fait concernant l'occupation mémoire, donc il est très possible que le pb aurait été moindre avec une version plus récente. Peut-être aurait-il été trop important malgrè tout, mais bon, c'était trop tard pour le savoir.
[^] # Re: Enfin une suite pour Unix
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KOffice-1.1 est sortie. Évalué à 1.
Si, eux ils sont encore en activité et rentables. :-)
[^] # Re: Pour aider a ta reflexion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche KOffice-1.1 est sortie. Évalué à 1.
C'est vrai, ça doit surement être très facile. :-)
> qui est un swap c++ pour gtk++ et gnome.
Un swap ? C'est quoi un swap ?
[^] # Re: ca fait mal...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quand Alan Cox debogue Nautilus.... Évalué à 1.
Oui, certes. Maintenant il manque la partie où tu prouves que tu sais de quoi tu parles. :-)
[^] # Re: Je suis pas d'accord (le retour de la revanche)
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Quand Alan Cox debogue Nautilus.... Évalué à 1.
Oui, là je suis d'accord.
> Tu n'as pas beaucoup d'estime pour ces pays, vrai ?
Pourquoi dis-tu cela ?
> Tu te serais debrouillé avec ton manuel et tes VT100.
La doc n'est pas le point fort des LL... Ceci dit je suis d'accord sur le principe.
> Et là, l'intelligence humaine aurait baissé au point que les gens ne puissent plus faire comme avant et lire la doc ? Ils auraient besoin d'interfaces graphiques wizbang et tout ? Moi, j'y crois pas.
Non, c'est juste que tôt ou tard c'est ce à quoi ils vont être confrontés, parce que le monde industrialisé tourne avec des interfaces graphiques. Donc si ils peuvent très certainement se former à la programmation, il faudra bien qu'ils dépassent bash/vi/make/gcc.
Par ailleurs, ne serait-ce que pour acceder au Web ils vont en avoir besoin aussi.
Et enfin, pour en revenir à la question de départ, imagine qu'Eazel soit allé voir ses financiers en leur disant : "Bonjour, on va sortir Nautilus 6 mois plus tard que prévu, parce qu'il faut le temps de le faire tourner sur les 486 d'un village africain. Ils n'ont pas d'argent, donc il ne pourront jamais acheter les services d'hebergement qu'on offre parallèlement à Nautilus, autrement dit nous allons payer 13 développeurs pendant 6 mois de plus avec l'assurance que ça ne sera pas rentable. Vous voulez bien nous signer un chèque ?"
A ton avis, ils auraient signé ?
> Ceci parce que Linux est très adapté à tourner sur des PDA/embarqués etc. Autrement dit : parce qu'il est optimisé.
Non, parce qu'il est modulaire et surtout que les PDAs sont devenus très puissants. Les OS embarqués sont en général bien plus petits que Linux.
> Sincèrement, je viens du monde Atari, pour moi perdre des mégaoctets de RAM et des millions de cycles processeur pour rien, c'est sacrilège
Tu veux parler de l'Atari 512 ST ? Cet engin avec un CPU de la mort mais avec un OS si mal foutu qu'il fallait 512K pour faire péniblement tourner un pseudo-finder à peine mieux que le MouseDesk que je lançais sur mon //e avec 128K ? Tu plaisantes j'espère. :-)
> mais la mécanique derrière est foireuse. Je trouve ça vraiment dommage...
Ceux qui faisaient de l'assembleur ont dit ça à ceux qui faisaient du C. Ceux qui faisaient du C ont dit ça à ceux qui faisaient du C++. Ceux qui font du C++ disent ça à ceux qui font du Java...