Je suis un peu surpris par ton commentaire. Tu es sûr que tu as fait du Qt récemment ?
Peut-être que j'arrive pas à cerner précisément le problème que tu rencontres mais j'ai jamais eu l'impression d'être noyé par les callback sous Qt. L'aspect slot justement est plus fin qu'un callback puisque tu n'as pas besoin de connaitre précisément l'appelant.
Quant à la propagation des modifications, sur des écrans de fonctionnalité assez simples, évidemment, quelle que soit la méthode, ça reste simple. Sur des écrans assez complexes, je me retrouve souvent à utiliser du modèle/vue, que ce soit celui fourni par Qt pour des widgets types lists, arbres ou tables, ou bien celui fourni indirectement par le flux de circulation des signaux.
Par exemple, pour cacher une entrée dans un menu en haut de la fenêtre + menu du click + bouton de la barre d'outil, j'ai juste à utiliser l'action d'origine actionMachin.setVisible(False).
On est bien dans une logique modèle/vue où le module (le QACtion) propage son changement dans toutes les vues (3 vues ici). Et tu as seulement besoin de toucher au modèle.
Les mises à jour visuelles se font aussi selon une chaîne de réaction qui ressemble à ce que j'ai vu sous React. L'évenement de base est propagé en descendant (par exemple un click) et tu choisis de le gérer au niveau qui t'interesse en mettant à jour les widgets qui te conviennent. Qt fait ensuite l'analyse en remontant pour voir quels parties de l'écran il doit redessiner.
Autant j'ai bien compris l'intérêt de React par rapport à de la programmation web javascript classique à coup de callback qui est vraiment lourd, autant je lui vois aucune supériorité par rapport à de la programmation en Qt. Les principes de fonds sont à peu près les mêmes, avec quelques particularités liées à la technologie d'implémentation.
React ne résout pas tout non plus. J'ai eu à debugger une application un peu complexe récemment, j'ai du m'accrocher pour comprendre la chaîne d'évènements qui mettait à jour ou pas une partie inappropriée de l'interface. Mon inexpérience côté web a certainement joué, mais il m'a pas semblé que j'étais arrivé dans un monde de simplicité et de clarté que tu vantes ici.
[^] # Re: Trop simple ?
Posté par Philippe F (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 6.
Je suis un peu surpris par ton commentaire. Tu es sûr que tu as fait du Qt récemment ?
Peut-être que j'arrive pas à cerner précisément le problème que tu rencontres mais j'ai jamais eu l'impression d'être noyé par les callback sous Qt. L'aspect slot justement est plus fin qu'un callback puisque tu n'as pas besoin de connaitre précisément l'appelant.
Quant à la propagation des modifications, sur des écrans de fonctionnalité assez simples, évidemment, quelle que soit la méthode, ça reste simple. Sur des écrans assez complexes, je me retrouve souvent à utiliser du modèle/vue, que ce soit celui fourni par Qt pour des widgets types lists, arbres ou tables, ou bien celui fourni indirectement par le flux de circulation des signaux.
Par exemple, pour cacher une entrée dans un menu en haut de la fenêtre + menu du click + bouton de la barre d'outil, j'ai juste à utiliser l'action d'origine actionMachin.setVisible(False).
On est bien dans une logique modèle/vue où le module (le QACtion) propage son changement dans toutes les vues (3 vues ici). Et tu as seulement besoin de toucher au modèle.
Les mises à jour visuelles se font aussi selon une chaîne de réaction qui ressemble à ce que j'ai vu sous React. L'évenement de base est propagé en descendant (par exemple un click) et tu choisis de le gérer au niveau qui t'interesse en mettant à jour les widgets qui te conviennent. Qt fait ensuite l'analyse en remontant pour voir quels parties de l'écran il doit redessiner.
Autant j'ai bien compris l'intérêt de React par rapport à de la programmation web javascript classique à coup de callback qui est vraiment lourd, autant je lui vois aucune supériorité par rapport à de la programmation en Qt. Les principes de fonds sont à peu près les mêmes, avec quelques particularités liées à la technologie d'implémentation.
React ne résout pas tout non plus. J'ai eu à debugger une application un peu complexe récemment, j'ai du m'accrocher pour comprendre la chaîne d'évènements qui mettait à jour ou pas une partie inappropriée de l'interface. Mon inexpérience côté web a certainement joué, mais il m'a pas semblé que j'étais arrivé dans un monde de simplicité et de clarté que tu vantes ici.