ne serait-il pas possible (au moins théoriquement) d'utiliser QT ou GTK pour dessiner les widgets ?
Théoriquement, oui. Mais vu qu'on a déja un moteur de thème (camaelon), ben heu pour le moment je préfère me concentrer dessus hein :-)
Là pour le moment camaelon contient en fait deux parties:
- des categories sur les classes widgets, modifiant le code de façon à ce que toute la partie "dessin" soit effectué par une seule classe, GSDrawFunctions
- un moteur de thème pixmaps utilisant ce mécanisme pour fournir une implémentation de GSDrawFunctions qui utilise des pixmaps pour le dessin des widgets
Ca marche bien, et pas besoin de patcher quoique ce soit (merci objc). Maintenant, ce serait quand même intéressant de basculer la première partie (les modifs des widgets) directement dans le cvs gnustep, histoire que ce soit par défaut et de pas avoir d'éventuels problèmes de synchro entre les deux codes. C'est justement ce que je suis en train de faire en ce moment, et ça devrait être commité rapidement.
Une fois ce refactoring directement intégré dans le cvs, Camaelon ne sera plus qu'une implémentation donnée de GSDrawFunctions; l'implémentation par défaut de GSDrawFunctions étant tout simplement le code actuel du "thème" NeXT.
Bref pour simplifier, ça changera pas grand chose pour Camaelon, ni pour les utilisateurs de Camaelon / les gens qui veulent un thème. Mais par contre ça devrait aider/faciliter si quelqu'un veut faire une implémentation d'un thème autre qu'avec Camaelon. Exemple:
- un "thème" Windows qui utilise l'api de thème de win32, pour GNUstep/Windows, parce que bon ce serait mieux dans l'idéal qu'un thème pixmap fait avec Camaelon
- un thème qui utiliserait le moteur de thème de Gtk ou Qt
- autres thèmes "programmés" (comme le thème actuel NeXT), c'est à dire sans utiliser de pixmaps
[^] # Re: Theme Engine à base de QT/GTK
Posté par Nicolas Roard . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 6.
Théoriquement, oui. Mais vu qu'on a déja un moteur de thème (camaelon), ben heu pour le moment je préfère me concentrer dessus hein :-)
Là pour le moment camaelon contient en fait deux parties:
- des categories sur les classes widgets, modifiant le code de façon à ce que toute la partie "dessin" soit effectué par une seule classe, GSDrawFunctions
- un moteur de thème pixmaps utilisant ce mécanisme pour fournir une implémentation de GSDrawFunctions qui utilise des pixmaps pour le dessin des widgets
Ca marche bien, et pas besoin de patcher quoique ce soit (merci objc). Maintenant, ce serait quand même intéressant de basculer la première partie (les modifs des widgets) directement dans le cvs gnustep, histoire que ce soit par défaut et de pas avoir d'éventuels problèmes de synchro entre les deux codes. C'est justement ce que je suis en train de faire en ce moment, et ça devrait être commité rapidement.
Une fois ce refactoring directement intégré dans le cvs, Camaelon ne sera plus qu'une implémentation donnée de GSDrawFunctions; l'implémentation par défaut de GSDrawFunctions étant tout simplement le code actuel du "thème" NeXT.
Bref pour simplifier, ça changera pas grand chose pour Camaelon, ni pour les utilisateurs de Camaelon / les gens qui veulent un thème. Mais par contre ça devrait aider/faciliter si quelqu'un veut faire une implémentation d'un thème autre qu'avec Camaelon. Exemple:
- un "thème" Windows qui utilise l'api de thème de win32, pour GNUstep/Windows, parce que bon ce serait mieux dans l'idéal qu'un thème pixmap fait avec Camaelon
- un thème qui utiliserait le moteur de thème de Gtk ou Qt
- autres thèmes "programmés" (comme le thème actuel NeXT), c'est à dire sans utiliser de pixmaps
voila voila..