Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
c'est ultra moche!
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à -1.
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.