> 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 :
[^] # Re: bouge ton Gnome.
Posté par Guillaume Laurent . 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(...)