Mes arguments ne sont pas du tout contradictoire, ils ne visaient qu'à montrer une chose : wxWidget n'a pas été conçu pour résoudre le problème de la portabilité (GTK et Qt sont des exemples parmis d'autres) mais bel et bien pour résoudre un autre problème l'intégration visuelle.
Evidemment que c'est du ressort du programmeur de bien architecturer son application, mais lorsqu'un toolkit lui propose tout et n'importe quoi, des objets d'IHM en passant par les threads et la couche réseau, celà va être dûr de concevoir une application indépendante du toolkit en question.
Et comme je l'ai déjà dis, wxWidget a des objectifs louable en soit mais il cache trop souvent un autre problème et finalement ne résoud en rien l'intégration puisqu'il conduit à des logiciels difficilement modifiables.
Donc bref, rien ne vaut une bonne sensibilisation aux vrais problèmes que wxWidgets ne résoud pas pour qu'il soit utilisé en tant que solution "intermédiaire" et no définitive comme on le voit trop souvent.
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . En réponse au journal wxWidgets 2.5.4 disponible sur SF. Évalué à 1.
Evidemment que c'est du ressort du programmeur de bien architecturer son application, mais lorsqu'un toolkit lui propose tout et n'importe quoi, des objets d'IHM en passant par les threads et la couche réseau, celà va être dûr de concevoir une application indépendante du toolkit en question.
Et comme je l'ai déjà dis, wxWidget a des objectifs louable en soit mais il cache trop souvent un autre problème et finalement ne résoud en rien l'intégration puisqu'il conduit à des logiciels difficilement modifiables.
Donc bref, rien ne vaut une bonne sensibilisation aux vrais problèmes que wxWidgets ne résoud pas pour qu'il soit utilisé en tant que solution "intermédiaire" et no définitive comme on le voit trop souvent.