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: bouge ton Gnome.
Posté par Guillaume Laurent . 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++.