Guillaume Laurent a écrit 1148 commentaires

C'est grand de dire :
- "Gtk n'arrive pas à la cheville de Qt."

C'est l'expression d'un fait, établi par plusieurs années d'expériences sur les 2 toolkits, et n'importe quel developpeur "adulte" te dira la même chose.

Retournes jouer avec Qt.

Je ne fais que ça depuis 3 ans.

Donc il faut faire comme Trolltech ? Non merci.

Ta position n'a aucune cohérence. Trolltech dit "si vous faites du libre, on vous file notre produit sous license libre, si vous faites du proprio on vous vend notre produit avec une license proprio", et tu trouves que c'est mal. A coté, tu trouves bien que GTK+ soit LGPL, ce qui permet à ceux qui veulent faire du proprio de l'employer sans rien donner aux gens qui s'en occupent.

Ce qui t'enerve c'est juste qu'on dise que GTK+ n'est pas la meilleure des toolkits, parce que tu es fan de Gnome/GTK, comme une gamine peut être fan de Britney Spears. C'est du même niveau. Après tu cherches des arguments tordus qui se contredisent, mais tu n'as visiblement qu'une très faible expérience de ce qu'est le développement logiciel, et aucune connaissance du paysage industriel actuel.

Hé, les Qt-man, vous sentez pas obligé de vomir sur Gtk. Je vomis pas sur Qt.

Grandis un peu. C'est pas "vomir sur GTK" que dire qu'elle est moins bien que Qt. J'ai suffisamment bossé avec les deux pour le savoir. GTK est une excellente toolkit C, bien meilleure que Motif (quoique moins bien documentée), mais Qt reste un produit d'un tout autre ordre de qualité.

C'est vrai que Linux et Kde c'est d'un lent au niveau du développement.

Oui, c'est lent. Par rapport à ce que ça serait si ils pouvaient être tous au même endroit et y bosser en permanence, c'est très lent. Y a que dans le petit monde enchanté de l'Open Source qu'on trouve qu'il vont vite. Lis les compte-rendus de toutes les réunions genre Kernel Summit, KDE Conference, même GUADEC. Ils disent tous que ça a été très productif parce qu'on résout bien mieux les problèmes quand on discute avec quelqu'un en face de soit que par mail. Y a pas de miracle, envoyer un mail ça prend plus de temps qu'aller dans le bureau d'a coté.

Et faire du GPL n'est pas incompatible avec le business contrairement à certains sous-entendus.

Dans le cas d'un produit comme une toolkit, c'est quand même assez difficile. Le support ne rapporte pas tant que ça (surtout que l'interêt de Qt c'est que le produit est tellement bon et bien documenté que tu as rarement besoin du support).

Gtk prouve qu'on peut faire un bon toolkit sans utiliser de licence proprio

Encore une fois : Gtk n'arrive pas à la cheville de Qt. Il y a 40 dev qui bossent sur Qt, qui écrivent la doc, font du spport, etc... Si tu veux une équipe de dev efficace, tu les mets dans le même batiment avec de bonnes machines, et tu les payes pour qu'ils puissent bosser à plein temps. Pour ça il faut des ressources financières. Développer en remote et ne communiquer que par mail/irc, ça marche, mais c'est beaucoup plus lent.

Gnome sera livré en standard dans Solaris 10 ... qui n'est pas encore sorti...

Sur : http://wwws.sun.com/software/star/gnome/(...)

"Availability

GNOME 2.0 Desktop for the Solaris OE is available now. "

Rire. Fais un tour sur freshmeat.net.

Ouhlaaa... On parle de gens qui développaient sous Solaris/Motif. C'est à dire à 99% des industriels. Et tu parles de Freshmeat...

Sur ta planète on n'est pas très informé. OSF est devenu DecUnix qui est devenu Tru64 qui existe toujours :

Ah oui, j'avais oublié ce dernier renommage. Il existe toujours, et en haut à droite de la page tu as un beau lien "Tru64Unix to hp/ux". Faut pas rever, HP ne va pas maintenir 2 lignes de produits Unix très longtemps.

Lorsqu'il faudra développer de nouvelle appli, Motif ne sera pas utilisé. Il y a principalement Qt et Gtk.

Pourquoi tu parles au futur ? Ça fait des années qu'on ne développe plus sous Motif. Pour les applis ayant besoin d'un certain niveau de perfs, c'est Qt (une grande partie de leurs clients viennent de Motif). Pour toutes les autres, la majorité, c'est Java, et maintenant C#.

Ou alors Trolltech vend des licences proprios et c'est retour à la case Motif.

Ils en vendent déjà, depuis un bout de temps :-).

si c'est un succès, on peut se demander si Trolltech va beaucoup bosser sur la version GPL...

Mais c'est un succès (pas énorme, mais très suffisant pour que la boite soit profitable). Et la version GPL de Qt est la même que l'Enterprise Edition, c'est le même code, seule la license change.

Ici on aime qu'un boîte vende des licences proprios

J'ai rien contre le logiciel propriétaire. Je pense que les deux doivent co-exister. Et pourquoi y trouves-tu à redire, alors que 2 lignes plus haut tu dis que le fait que Gtk soit LGPL est un avantage par rapport à la GPL ?

Mais Gtk c'est tout neuf pour Sun.

Si je me souviens bien l'annonce de l'inclusion de Gnome par Sun remonte à 2000. 3 ans pour établir un support sur un produit, c'est un peu beaucoup.

Mais tout les développements qui se faisaient sous Unix avec Motif vont être fait sous Gtk+/Gnome.

De quelle couleur est le ciel sur ta planète ? Sun ne fera jamais le moindre developpement sous Gtk+/Gnome. Leur seul interêt c'est Java. Ils ont bien alloué quelques ressources à Gnome pour peaufiner un peu l'UI et écrire de la doc, histoire d'avoir un produit présentable, mais jamais ils n'écriront le moindre soft avec. De toute façon vu leur situation actuelle et leur déclin qui s'accélère, ce qu'ils feront ou pas n'aura bientôt plus d'importance.

À moins que vous allez m'expliquer que tout le monde va passer sous C++ et choisir Qt

Tout le monde est passé sous Java et/ou C#. Qt est anecdotique en comparaison, et Gtk+ n'existe même pas. Ça va te faire un choc, mais il y a tout un monde réel derrière ta petite bulle rose.

Partiquement tout les Unix commerciaux switchent sous Gtk/Gnome

Euh, combien d'Unix commerciaux reste-il ? Solaris, HP/UX (je crois qu'OSF dégage après le rachat de Compaq par HP), et AIX. Sun a adopté Gnome, on est d'accord. HP avait décidé d'adopter Gnome à la place de CDE, ils n'ont jamais vraiment participé au projet lui-même, et a récemment laissé tomber :

http://h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,481(...)

IBM n'a jamais été interessé par Gnome, mais ils ont vaguement filé quelques ressources à KDE. Eux aussi sont à fond dans Java. Donc de "pratiquement tous" on passe à "1 seul, et encore c'est juste pour faire joli".

Continuer de répendre qu'il n'y a qu'avec des solutions bien proprio

"Ouiiiinnn, vous ètes tous que des méchants qui font rien qu'a dire du mal de mon environnement à moi".

On parle du fait que Qt n'est pas GPL sous Windows.

Le début du thread c'était "Qt est passé sous GPL car GTK commençait a faire une grosse concurrence.", et on t'explique pourquoi cette phrase est une annerie.

Bizarre, ce qui n'est pas apprécié (à juste titre) chez Suse (à cause de yast) est apprécié chez Trolltech.

Ce ne sont pas les mêmes qui apprécient que Qt soit payant sous Windows que ceux qui n'apprécient pas que YAST ne soit pas GPL (personnellement je trouve tout à fait normal que Qt soit payant pour Windows, et je me fous que YAST ne soit pas GPL).

Sun propose maintenant Gnome par défaut. Tu crois que Sun ne va pas faire de support pour les développeurs comme Sun le faisait pour Motif ?

Franchement, oui, je crois. Sun n'a rien à battre de Gnome, il veulent juste un remplaçant pas cher pour CDE. Sun, c'est Java, point barre. Si tu arrives en leur disant "je développe sous Solaris en GTK+, j'ai besoin de support", je pense qu'ils te diront de passer sous Java avant de les recontacter :-). (une fois qu'ils auront récupéré du fou-rire qu'une telle requete ne manquera pas de leur donner).

Cherche "gtk support" sur sun.com pour voir :

http://www.google.com/search?as_q=gtk+support&num=10&hl=en&(...)

La seule page d'info c'est ça : http://wwws.sun.com/software/star/gnome/developer/(...)

et ça renvoie à gtk.org, gnome.org, etc...

Mais OOUUII. Tout comme Linux ne concurrence pas les Unix commerciaux. Mais OOOUUUIII.

J'ai eu l'occasion d'en discuter avec le chef de leur departement marketing. GTK+ n'est jamais opposé à Qt chez les clients. Ce qui est parfaitement compréhensible quand tu regardes les deux toolkits, GTK+ ne boxe pas dans la même catégorie.

Linux concurrence les Unix commerciaux dans certains domaines (pas encore tous) parce qu'il fait aussi bien, voire mieux, pour moins cher, et tourne sur du matos courant. Il n'y a pas le même rapport entre GTK+ et Qt.

Comprend pas. La version GPL ne peut pas concurrence la version non GPL d'après toi. Où est le problème ?

Si Qt avait été GPL dès le départ, Une plus grosse boite (Sun, IBM) avec plus de ressources aurait pu s'en emparer et commencer à développer leur propre version (toujours GPL), et la diffuser (voire aussi la porter sous Windows tout en la laissant GPL). Trolltech n'aurait jamais pu suivre.

Qt est passé sous GPL car GTK commençais a faire une grosse concurrence.

Non, ils ont attendus d'être assez solides pour être surs qu'aucune boite ne puisse forker Qt et faire mieux qu'eux. GTK n'a jamais été un concurrent de Qt sur le plan commercial.

Je ne te parle pas que des plantages mais de la qualité générale du support C++. Et ma config est tout ce qu'il y a de plus standard.

C'est pas le contraire que tu veux dire ?

Non. Si des mainteneurs ne voient pas d'eux-même des pbs aussi gros, c'est pas la peine de le leur signaler, ça ne servirait à rien.

http://developer.kde.org/documentation/tutorials/dot/dcopiface/dcop(...)

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rosegarden/gui/roseg(...)

T'as fait un rapport de bug ?

Non. Si ils ne s'en sont pas rendu compte eux-même, c'est pas la peine de leur envoyer un bug report. A vue de nez, ils le savent mais n'ont pas les ressources pour s'y coller.

Tu connais mieux ?

Gratuit et sous Linux, non. Pas gratuit, y a TotalView, mais c'est un produit pro donc une license coute dans les 10KF.

Donc si tu utilises KFile, c'est pas utilisé automatiquement.

KFile est un composant standard de KDE, avec dedans tout ce qu'il faut pour sérialiser les types Qt. Pour utiliser les fonctions système Unix à la place, faut être maso, parce que tu vas devoir coder 20 fois plus.

faut juste taper sur les developpeurs d'applis poru qu'ils utilisent ça

C'est toute la différence avec KDE. Pas besoin de taper, ils le font d'eux-même, parce que c'est facile. Il m'a fallu 30mn pour ajouter le support DCOP à Rosegarden, lecture de la doc comprise. Ça se résumait en un .h et une entrée dans le Makefile.am.

Le système de notification de GConf est à mon avis une de ses grandes forces

Possible.

Le C++ j'en fais parfois.

Fais-en un peu plus, en utilisant des features avancées genre templates, et re-essaie gdb dessus. Tu changera vite d'avis. Dernièrement on arrivait à faire crasher gdb lui-même.

C'est pas vraiment un secret que gdb digère mal C++. Ça fait des années que ça dure.

L'un des pbs c'est que Michael Meeks est extrèmement hostile à l'idée de laisser tomber bonobo.

Puis libxml, c'est pas hébergé par gnome ?

Seulement hebergée. Daniel Veillard veille à ce qu'elle soit indépendante de du framework Gnome.

Vérifie.

Ça serait plutôt à toi de faire ça.

Il n'ont pas de fonctionnalité type pango alors...

C'est dans Qt 3.2.


> KDE avait l'anti-aliasing bien avant Gnome.

Prouve le.


Je rève : http://dot.kde.org/984198998/(...) : 10/Mar/2001. Ça fait 2 ans que j'ai des fontes antialiasées sur mon desktop.

C'est baleze KDE si quand tu fais un read Unix ca utilise automatiquement les kioslaves ;)

Tu ne fais pas de read(2) dans une appli KDE, tu utilises KFile.

Est-ce que KConfig permet à des applis de demander à être prévenue quand la valeur d'une preference est modifiée ?

Non.

Les autres, eclipse, kdevelop, kdbg utilisent gdb.

Je sais, et ils ne fonctionnent pas mieux que ddd.

T'es vraiment un comique toi.

Ça fait combien de temps que tu codes en C++ sous Linux ?

La libxml n'est pas gnome (gnome l'utilise, c'es tout) et KDE l'utilise uniquement pour parser ses fichiers de doc.

KDE n'utilise pas pango.

KDE n'a pas grand chose à faire d'un equivalent à gconf pour le moment, et comme dit plus bas en faire un ne prendrait pas bien longtemps.

Qt est GPL, Trolltech la vend a des vrais clients qui font des choses utiles avec. Du coup les features qui sont dans Qt sont des features utiles pour faire des programmes utiles.

KDE avait l'anti-aliasing bien avant Gnome.

La question de gstreamer a été vaguement évoquée, c'est tout.

une foule d'applications ont été portées a gconf
de plus en viennent à gnome-vfs aussi

Alors que les technos équivalentes pour KDE sont utilisés systématiquement, parce qu'il n'y a rien de spécial à faire pour les mettre en oeuvre.

gnome est plus "ambiiteux" technologiquement que KDE

Ça c'est leur thèse. En pratique, Gnome est l'archétype du fourvoiement total. Que des "grandes théories", aucun pragmatisme. OO en C (donc les codeurs font - mal - le boulot d'un compilo C++), bindings (longs à faire si on veut les faire bien, dur à maintenir, doc à ré-écrire), CORBA (beaucoup trop complexe à mettre en oeuvre, inutile pour un desktop). En gros "on va faire mieux que tout le monde", au lieu de "on va faire quelque chose qui marche et dont les utilisateurs on vraiment besoin".

que kde adoptent "gconf"

Pourquoi faire. Il suffit d'écrire un backend LDAP à KConfig pour avoir la même fonctionalité. L'architecture est déjà là.

As-tu sérieusement utilisé ddd ?

Moi oui. Sur du C ça va, sur du C++ c'est une daube (vu le support C++ de gdb, c'est un peu normal).

On entend ça depuis des centaines d'années au minimum. Toujours le même disque.

Parce que c'est vrai depuis KDE 2.

Je veux dire pour l'utilisateur final.

Des applis développées plus vite, mieux intégrées, avec plus de fonctionalités, et un desktop plus cohérent.

Je doit conclure quoi ?

Que les technos KDE sont plus faciles à mettre en oeuvre que celles de Gnome.