"Tu peux préférer faire du vélo à conduire une voiture, c'est pas ça qui te fera aller plus vite en vélo qu'en voiture :-)."
Tout dépend du niveau d'encombrement de l'axe de circulation... ;-)
"Tu peux adorer GTK+ et être super-bon avec, ça n'arrange rien au fait que n'importe qui de pas trop mauvais utilisant C++/Qt ou Java/Swing ira beaucoup plus vite que toi pour développer une appli."
Ca dépend de l'appli. Pour faire une grosse appli super complexe, oui clairement (encore que, peut gtkmm, mais je connais mal).
Pour faire vite-fait une couche graphique sur un petit outil systeme (par exemple), gtk est tout indiqué (de même que c'était tk il y'a encore peu de temps): rapide, tournant sur plein de langages, y compris des langages sans-objets (C).
C'est la même chose pour les toolkits graphiques et les langages: y'a pas UN bon toolkit et des mauvais: ils ont chacun leur specificité, et leur domaine d'application propre.
[^] # Re: MDI
Posté par Olivier M. . En réponse à la dépêche Miguel de Icaza s'explique sur .NET. Évalué à 6.
Tout dépend du niveau d'encombrement de l'axe de circulation... ;-)
"Tu peux adorer GTK+ et être super-bon avec, ça n'arrange rien au fait que n'importe qui de pas trop mauvais utilisant C++/Qt ou Java/Swing ira beaucoup plus vite que toi pour développer une appli."
Ca dépend de l'appli. Pour faire une grosse appli super complexe, oui clairement (encore que, peut gtkmm, mais je connais mal).
Pour faire vite-fait une couche graphique sur un petit outil systeme (par exemple), gtk est tout indiqué (de même que c'était tk il y'a encore peu de temps): rapide, tournant sur plein de langages, y compris des langages sans-objets (C).
C'est la même chose pour les toolkits graphiques et les langages: y'a pas UN bon toolkit et des mauvais: ils ont chacun leur specificité, et leur domaine d'application propre.