Discussion :

[koala01]

Ce que j'entends par "intégration" effectivement la création d'éléments d'interfaces facilitant la création de services tels que le parsing XML, l'accès aux SGBD, l'utilisation de différents protocoles,...

Comme je l'ai fait remarquer, ce sont des éléments qui devraient parfaitement pouvoir être générés a mano par l'utilisateur, si on arrive à garder la bibliothèque non intrusive, mais, d'un autre coté, s'il y a moyen, à terme, d'éviter à l'utilisateur de devoir gérer sa propre "boite à outils" d'éléments d'interfaces, ce ne sera pas plus mal (étant entendu que certains aspects devront sans doute être mis en place plus vite que d'autre )

Si certains aspects devront être utilisés en interne (je pense à la possibilité d'ajouter une image dans l'interface, et donc à la gestion de l'affichage de certains format d'images), la grosse majorité des intégrations ne servira qu'à facilité la vie de l'utilisateur

Pour ce qui est de l'aspect d'internationalisation de l'interface, il y a deux points à prendre en compte:

Il y a, effectivement, le problème de la gestion des différentes fontes, mais d'un autre coté, il y a l'aspect de la simple "traduction" des textes visibles dans l'interface:

Même en restant sur les langues utilisant la table de caractères "latin-1" (ou équivalente ), comment ferons nous pour que "dormir" soit affiché comme tel en français mais soit affiché "slaapen" en néerlandais, "nuuka" en finnois ou "to sleep" en anglais, si, du moins l'utilisateur veut pouvoir fournir son application en différentes langues

Au delà, il y a effectivement le problème du sens de lecture, de la présence ou non de tables de caractères adaptées pour les autres langues, et de la gestion des fontes...

Mais, pour autant que je sache, la plupart des systèmes d'exploitations fenêtrés disposent de leur propre moyen de gérer les différentes fontes, et il n'y a a priori pas forcément besoin de fournir autre chose qu'une façade permettant de les gérer (ou en tout cas de choisir celle qui est utilisée) de la même manière sous nix que sous windows

[epsilon68]

Ce dont vous parlez: un C++ moderne, des techniques avancées, me font penser à GTK++ ....

http://www.telegraph-road.org/writings/gtkmm_vs_qt.html

en gros:

Murray : (...)Chief among these is its modification of the C++ language and the use of its own non-standard string class. It isn't necessary, as we've proved.

Regarding QString, it is undoubtedly necessary because std::string doesn't handle Unicode. gtkmm itself has Glib::ustring, I see that you made its interface similar to std::string, and I also think it's a bad idea, because no matter how standard it is, it's not very convenient nor powerful. QString offers very useful features like arg(), sprintf(), section(), simplifyWhiteSpace(), toInt() and its siblings, setNum(), and of course regexp support, which are invaluable in everyday development.

Now about these ever controversial modifications of the C++ language. You argue that they aren't necessary. It's true, although you haven't proven it quite totally because gtkmm doesn't provide all the features Qt's "extensions" do.

Murray : (...) I believe that you'll love gtkmm if you love C++, and that gtkmm is a better role-model if you're learning C++. (...)

I'm not sure about gtkmm being a "better role-model" for C++ students, but your saying "you'll love gtkmm if you love C++" is the core of the problem, and the reason you still fail to understand why Qt is better. I don't love C++. I don't care about C++. I care about writing applications that do useful things. So I don't mind using a library which adds non standard keywords to C++, as long as it helps development. But you care for C++, so you can't do this. You care up to the point where you're oblivious of its flaws, and you don't realize that by trying to remain "faithful" to it, you make your life harder, not easier. Again, this is exactly how Gnome's C hackers happily handle the GTK+ Object System, not realizing that they could achieve the same things so much faster using C++ and Qt, and utterly convinced that what they do is "easy", because they love C and they don't need to learn another language.

Standards aren't sacred things. Theoretically you'll be better off following them, but in practice it's not always the case, simply because they were devised by fallible humans. And tools or languages shouldn't be loved, they should be used appropriately. Otherwise, when a better alternative comes around you'll ignore it, because you don't want to give up your own precious one.

Le mieux est l'ennemi du bien !

[JolyLoic]

J'ai uniquement lu en diagonale la discussion, et ne pourrait participer que sporadiquement. Ça fait un an environ que je fais de l'IHM avec WPF, et que je trouve ça bien plus puissant que les modèles de type Qt (j'en suis resté à une vieille version, ça a pu changer depuis), C++ builder, WinForms... que j'avais vu jusqu'à présent. Voici quelques points qui me semblent intéressants en Wpf, et que j'aimerais trouver dans une autre bibliothèque d'IHM, en C++ :

- Une véritable séparation entre le rôle d'un composant et sa représentation graphique
- Une très grande composabilité des composants (un item d'une listbox peut être composé d'un text, à côté d'une image et d'un bouton, ce dernier étant lui même composé d'un texte à coté d'une image à côté de...)
- Une notion de databinding permettant de lier une valeur d'une propriété quelconque à une autre, ou à une donnée du modèle situé derrière, et de ne plus se préoccuper de la mise à jour de cette valeur

Il y a d'autre points intéressants (et certains un peu moisis), mais ces derniers me semblent les plus remarquables.

[metagoto]

Ça fait un an environ que je fais de l'IHM avec WPF, et que je trouve ça bien plus puissant que les modèles de type Qt (j'en suis resté à une vieille version, ça a pu changer depuis), C++ builder, WinForms... que j'avais vu jusqu'à présent. Voici quelques points qui me semblent intéressants en Wpf, et que j'aimerais trouver dans une autre bibliothèque d'IHM, en C++

Ces trucs WPF, tu fais ça en C# ?

Il y a quelques années, j'avais testé Winform avec C++/CLI. J'avais trouvé ça super. L'extension CLI de microsoft était vraiment bien foutu. Je n'ai pas suivi ce qu'il s'est passé depuis..

[JolyLoic]

Oui. Hélas...

[koala01]

- Une véritable séparation entre le rôle d'un composant et sa représentation graphique

Je *crois* comprendre ce que tu dis, mais je t'avouerai que j'ai malgré tout un doute...

Si c'est ce à quoi je pense, c'est effectivement une idée qui vaut d'être retenue, mais, pour en être certain, pourrais tu développer un peu

- Une très grande composabilité des composants (un item d'une listbox peut être composé d'un text, à côté d'une image et d'un bouton, ce dernier étant lui même composé d'un texte à coté d'une image à côté de...)

Cela pourrait effectivement être intéressant... reste à savoir comment il est possible d'appliquer l'idée, de telle sorte qu'il reste facile pour l'utilisateur de faire cette aggrégation

- Une notion de databinding permettant de lier une valeur d'une propriété quelconque à une autre, ou à une donnée du modèle situé derrière, et de ne plus se préoccuper de la mise à jour de cette valeur

Effectivement, cela pourrait être "'achement utile"

Il y a d'autre points intéressants (et certains un peu moisis), mais ces derniers me semblent les plus remarquables.

N'hésite pas à les proposer, on fera le tri

[Klaim]

Cela pourrait effectivement être intéressant... reste à savoir comment il est possible d'appliquer l'idée, de telle sorte qu'il reste facile pour l'utilisateur de faire cette aggrégation

Peut être en considérant la manière la plus abstraite de considérer des widgets? (Personellement, je ne comprends pas comment on peu appeler widget des composants qui ne sont pas visible. Pour moi ce sont d'autres composants, les widgets étant tout ce qui est "interractif".).

On a, en gros, une surface--l'interface-- qui est composée de plusieurs autres surfaces--les "widgets"-- dont certains sont interactifs et d'autres non. Par interraction on sous entends qu'il y a réaction face à une action--une entrée-- qui concerne la ou les surfaces.
Si un widget (une zone de texte) est juste un bout de surface, alors il peut être composé d'autres surfaces (boutton sous le texte, radio-boutton, etc.).

Il me semblait qu'il était possible d'avoir une vidéo ou une image dans une combo-box dans Qt, non? Dans les WPF il me semble que c'est possible mais je n'y ai pas touché concrètement. C'est un peu la même idée, non?

[ElPedro]

Bonjour,

je ne vais pas vous aider (à moins que vous ayez besoin de macros, je suis assez à l'aise n'hésitez pas à me mp) :
perso, je pense qu'un générateur de code est + simple à utiliser qu'un dsel.

Cependant voici quelques trucs :
1/boost.fusion. Cela me semble une très bonne option pour faire des data-bindings faciles. D'ailleurs, si vous connaissez spirit, alors je pense que vous l'aviez déjà en tête ?

2/ tant que vous ne donnez pas des vidéos / protos visuels de ce que vous voulez faire comme IHM vous ne serez pas efficace.

ex: je veux pour un jeux que l'interface représente une plage vue du dessus. Lorsque la souris fait un rollOver, le texte du menu dessiné dans le sable sort du sol, renversant du sable partout. Le vent et l'eau peuvent émousser le texte, mais il ne s'écroule vraiment que lorsque la souris s'éloigne. A partir de ce niveau, il est clair que la notion de Zorder on peut oublier , de même que la zone de dessin.
Bref, avoir des exemples de ce que vous souhaitez pouvoir faire : quid de l'utilisation des differents doigts (pouce/index..) pour le tactile ? de la pression ? etc... Je ne parle même pas de la reconnaissance de gestes, de son, de facial, de force du souffle (ça existe, j'ai une interface comme ça chez moi )...

Bref : qu'est ce qui ne va pas être autorisé? qu'est-ce qui va l'être? cela permettra de déterminer plus facilement le nécessaire de la conception. Et valider aussi vos objectifs.

3/ Idem pour les interfaces de programmation. Proposez des interfaces de programmation. Celle de yan avec les streams est sympa par exemple. Est-ce que la lib utilisera de l'introspection? Est-ce qu'elle utilisera/fournira de la serialization? etc...

4/ Perso je serai parti sur un génerateur de code. En effet, mon expérience avec les templates me dit que bof (faire du debug avec des templates je trouve ça chiant, sans même parler des erreurs de compil). Surtout, je ne les trouve pas assez généralistes. Mon expérience avec template + macros me dit que c'est mieux qu'avec juste les templates, mais loin d'être extras. Bref, je ne vais pas vous suivre, et continuer sur mes projets dans mon coin .

De mon point de vue, pour l'ihm de papa maman 'utile et moche', autant utiliser direct FLTK.

Juste une idée comme ça : j'aurais tendance à privilégier des approches non-absolue. Bref, utiliser des pourcentages. Un message est envoyé avec 90% de force vers tel truc, et 10% vers tel autre etc... Bref, avoir une panoplie de paramètres écoutables préparés (temps écoulé, cos du temps écoulé, framerate, distance du pointeur, variance de la position du pointeur, etc...), un peu comme les parametres shaders dans ogre3D (juste sous 'param_indexed_auto' sur le lien suivant :
http://www.ogre3d.org/docs/manual/manual_23.html#SEC125). Bon, ceci est juste une idée en passant.

Bon courage à tous!

[JolyLoic]

Je *crois* comprendre ce que tu dis, mais je t'avouerai que j'ai malgré tout un doute...

L'idée, par exemple, c'est de dire qu'une listbox, ce n'est rien d'autre qu'une zone affichant des sous items, et permettant d'en sélectionner un ou plusieurs. Ca, c'est l'aspect fonctionnel. Et l'aspect visuel peut entièrement customisé sans écrire de classe dérivée :
- L'aspect global de la listbox peut être remplacé
- La manière dont les items sont positionnés les uns par rapport aux autres peut être rédéfinie
- Les décorations apportées à un item pour montrer qu'il est sélectionné peuvent être redéfinies
- La manière d'afficher un item peut aussi être redéfinie
- ...
- Mais le comportement (sélection simple ou multiple, touches clavier, évènements quand un objet est ajouté à la sélection...) reste le même.

L'idée est que l'arbre logique des contrôles (une listbox qui contient des items) se trouve déployé en arbre visuel (on a en fait un rectangle avec effet 3D qui contient un panneau qui contient...) et que ce déploiement est configurable.


Peut-être le survol de http://drwpf.com/blog/2009/05/12/ite...-for-lookless/ donne-t-il plus d'idées.

[yan]

@jolyloïc :Si je me trompe pas (j'ai pas encore fait beaucoup de wpf), Qt va proposer quelques chose de semblable, en particulier avec QML qui est grosso modo leur réponse à xaml.

Ils ont déjà fait des petite chose, comme l'utilisation de css pour customiser l'ihm
http://qt.developpez.com/doc/4.7-snapshot/stylesheet/

et leur système de MVP
http://qt.developpez.com/doc/4.7-sna...w-programming/

Il me semble que GTK prépare aussi quelque chose.

De ce que j'ai compris de adam&eve ca semble assez proche de ce que propose xaml.

[koala01]

Cependant voici quelques trucs :
1/boost.fusion. Cela me semble une très bonne option pour faire des data-bindings faciles. D'ailleurs, si vous connaissez spirit, alors je pense que vous l'aviez déjà en tête ?

On a déjà indiqué que le principe était d'utiliser la STL et boost pour ainsi dire à outrance... Nous devons donc "simplement" évaluer quelle partie de boost sera à la fois suffisamment stable et la plus facile et/ ou la plus efficace pour résoudre un problème donné.

Boost.fusion ne fait donc absolument pas exception

2/ tant que vous ne donnez pas des vidéos / protos visuels de ce que vous voulez faire comme IHM vous ne serez pas efficace.

Faut il rappeler encore une fois que le but de cette discussion est de réfléchir à la faisabilité et à l'intérêt d'une nouvelle bibliothèque, ainsi qu'à ce que l'on souhaite pouvoir faire avec

Si nous venions à fixer un cadre trop "rigide" à l'idée même de ce que permet la bibliothèque, nous limiterions fatalement sa plage d'utilisation, et donc les possibilités de propositions.

Il faudra sans doute faire un tri de tout ce qui aura été dit, mais, en laissant le sujet "dans le vague" (bien que certaines décisions aient déjà été prises et que certaines propositions soient déjà acceptées dans le principe), nous laissons la possibilité à tous de donner leur avis

ex: je veux pour un jeux que l'interface représente une plage vue du dessus. Lorsque la souris fait un rollOver, le texte du menu dessiné dans le sable sort du sol, renversant du sable partout. Le vent et l'eau peuvent émousser le texte, mais il ne s'écroule vraiment que lorsque la souris s'éloigne. A partir de ce niveau, il est clair que la notion de Zorder on peut oublier , de même que la zone de dessin.

L'idée est de fournir quelque chose permettant au développeur de donner une IHM à son application et non de la spécialiser pour une application donnée.

Par contre, tu mets effectivement le doigt sur un point important: les différentes "propriétés" des éléments visuels doivent être "facilement désengageables" (comprend: si le zorder n'a pas lieu d'être, le développeur devrait être en mesure de... faire sans...)

Bref, avoir des exemples de ce que vous souhaitez pouvoir faire : quid de l'utilisation des differents doigts (pouce/index..) pour le tactile ? de la pression ? etc... Je ne parle même pas de la reconnaissance de gestes, de son, de facial, de force du souffle (ça existe, j'ai une interface comme ça chez moi )...

Là encore, tu sembles avoir tendance à partir d'hypothèses beaucoup trop particulières qui risquent de restreindre la bibliothèque dans une niche, sans doute intéressante, mais trop particulière:

Il faut effectivement prendre en compte les "nouvelles technologies" (allez, disons plutôt les technologies émergentes ), entre autre, au niveau des entrées et sorties, mais tout le monde n'a pas *forcément* un écran tactile et tout le monde n'a pas *forcément* envie de gérer *toutes* ses applications à coup de clin d'œil ou de reconnaissance vocale...

Le mieux à faire, pour l'instant, me semble être de considérer le fait que la souris est... un système de pointage, tout comme peut l'être le doigt avec un écran tactile ou comme pourrait l'être l'oeil avec une camera.

Par la suite, si l'on trouve quelqu'un qui est capable de fournir le support des écrans tactiles ou des caméra et qui soit, surtout, en mesure de tester ces possibilités, il ne faudra effectivement pas manquer le coche, mais nous n'en sommes vraiment pas encore là

Bref : qu'est ce qui ne va pas être autorisé? qu'est-ce qui va l'être? cela permettra de déterminer plus facilement le nécessaire de la conception. Et valider aussi vos objectifs.

A priori, rien n'est encore refusé, pour autant que l'on reste dans les limites de ne pas en arriver à vouloir créer un super objet ou un "précompilateur" quelconque...

Il y a de la marge pour avancer, non :quesiton:

3/ Idem pour les interfaces de programmation. Proposez des interfaces de programmation. Celle de yan avec les streams est sympa par exemple. Est-ce que la lib utilisera de l'introspection? Est-ce qu'elle utilisera/fournira de la serialization? etc...

Voilà des questions intéressantes, qui méritent d'être un minimum étudiées

Il me semble difficile de faire sans un minimum d'introspection et de sérialisation...

Maintenant, que faut il entendre par sérialisation le fait de pouvoir exporter et récupérer la manière dont l'interface se présente, ou le fait d'être en mesure de sauvegarder les données manipulées par celle-ci

Dans le premier cas, il me semble effectivement que l'on ne pourra pas faire sans, dans le second cas, je dirais qu'il faudrait pouvoir donner la possibilité de disposer de son propre système de sérialisation ou d'en utiliser un qui serait fourni par certains widget.

4/ Perso je serai parti sur un génerateur de code. En effet, mon expérience avec les templates me dit que bof (faire du debug avec des templates je trouve ça chiant, sans même parler des erreurs de compil). Surtout, je ne les trouve pas assez généralistes. Mon expérience avec template + macros me dit que c'est mieux qu'avec juste les templates, mais loin d'être extras. Bref, je ne vais pas vous suivre, et continuer sur mes projets dans mon coin .

Soyons clairs : les macros sont une partie intégrante de C++, et il n'est donc absolument pas question de les bannir...

Cependant, le choix de les préférer ou non à des template devra être évalué pour chaque situation

Par contre, il y a de la marge entre l'utilisation de macro et... le fait de faire passer le code par la moulinette d'un programme externe (autre que le préprocesseur qui est, d'office, appelé lors de la compilation), comme le fait Qt (pour ne citer que lui).

Cet cet excès qui consiste à faire passer le code en revue par un système externe que je veux éviter à tout prix

Maintenant, je respecte ta décision de ne pas participer, bien que l'on puisse la regretter

De mon point de vue, pour l'ihm de papa maman 'utile et moche', autant utiliser direct FLTK.

Et pourtant, si l'ihm "moche et utile" de papa/maman n'existait pas, tu serais occupé à lire un horrible texte jaune ou blanc sur fond noir

S'il faut effectivement veiller à ne pas brider la créativité des gens vers le haut, il ne faut pas non plus oublier que certains peuvent avoir besoin de "bête boutons rectangulaires"

Juste une idée comme ça : j'aurais tendance à privilégier des approches non-absolue. Bref, utiliser des pourcentages. Un message est envoyé avec 90% de force vers tel truc, et 10% vers tel autre etc... Bref, avoir une panoplie de paramètres écoutables préparés (temps écoulé, cos du temps écoulé, framerate, distance du pointeur, variance de la position du pointeur, etc...), un peu comme les parametres shaders dans ogre3D (juste sous 'param_indexed_auto' sur le lien suivant :
http://www.ogre3d.org/docs/manual/manual_23.html#SEC125). Bon, ceci est juste une idée en passant.

Pour certains aspects, ce pourrait effectivement être une idée à creuser

Bon courage à tous!

Merci

L'idée, par exemple, c'est de dire qu'une listbox, ce n'est rien d'autre qu'une zone affichant des sous items, et permettant d'en sélectionner un ou plusieurs. Ca, c'est l'aspect fonctionnel. Et l'aspect visuel peut entièrement customisé sans écrire de classe dérivée :
- L'aspect global de la listbox peut être remplacé
- La manière dont les items sont positionnés les uns par rapport aux autres peut être rédéfinie
- Les décorations apportées à un item pour montrer qu'il est sélectionné peuvent être redéfinies
- La manière d'afficher un item peut aussi être redéfinie
- ...
- Mais le comportement (sélection simple ou multiple, touches clavier, évènements quand un objet est ajouté à la sélection...) reste le même.

L'idée est que l'arbre logique des contrôles (une listbox qui contient des items) se trouve déployé en arbre visuel (on a en fait un rectangle avec effet 3D qui contient un panneau qui contient...) et que ce déploiement est configurable.

C'est donc bien ce que j'avais compris...

Et je confirme que l'idée est donc à retenir, du moins tant que l'on n'a pas la preuve de son infaisabilité

[Invité]

L'idée, par exemple, c'est de dire qu'une listbox, ce n'est rien d'autre qu'une zone affichant des sous items, et permettant d'en sélectionner un ou plusieurs. Ca, c'est l'aspect fonctionnel. Et l'aspect visuel peut entièrement customisé sans écrire de classe dérivée :
- L'aspect global de la listbox peut être remplacé
- La manière dont les items sont positionnés les uns par rapport aux autres peut être rédéfinie
- Les décorations apportées à un item pour montrer qu'il est sélectionné peuvent être redéfinies
- La manière d'afficher un item peut aussi être redéfinie
- ...
- Mais le comportement (sélection simple ou multiple, touches clavier, évènements quand un objet est ajouté à la sélection...) reste le même.

Typiquement, ca se gère avec des callbacks ca, non?

En gros, une listbox est un "widget maigre", qui met à disposition de ses utilisateurs un certain nombre de fonctions de dessin ou de sélection, qui peuvent toutes être redéfinies par l'utilisateur. Elle s'alimente en données auprès d'un "conteneur" qui peut être ce qu'on veut, il lui suffit de disposer d'un itérateur qui permet de les parcourir.

Ce qui fait le comportement du widget, ce sont ses fonctions : une interface, ou un contrat, si tu veux... (et note bien que dans ce contexte, il n'y a plus de différence réelle entre une ListBox, une Combobox, un radiogroup... ce sont des widgets qui affichent des listes et permettent d'en choisir un élément... qui se distinguent par le paramétrage de leur paint(), et leur measure())

Dans les IHM à superobjet, on fait ca en créant une méthode "standard" (DoPaint()), et en autorisant l'utilisateur à la redéfinir, souvent via des évènements de type OnPaint(). Ici, on pourrait imaginer un système plus avancé (enfin bon, sans doute pas les pointeurs sur fonctions membres du C++, peut être un des trucs les plus crades du langage), qui permettrait de redéfinir les comportements.

Pour la Listbox, il faudrait trois choses :

1- un Paint() customisable "par morceaux" (en gros, on peut surcharger tout ou partie du comportement de dessin),
2- un PaintItem() délégué aux Items (avec un ItemMeasure qui renvoie la taille nécessaire au parent)
3- une structure de Composite pour les items (et pas de bête liste)

C'est probablement sur ce genre de chose que l'approche "non objet" qu'on voudrait poursuivre est intéressante. Dans des hiérarchies de classe, on ne peut étendre les propriétés par défaut qu'en dérivant, et ce qui n'est pas prévu dans les dérivations possibles, n'est juste pas possible.

@ElPedro: les exemples que tu cites relèvent exclusivement du rendu, je ne suis pas du tout certain que cela invalide la notion de widget (tu parles de menu, hein?)

@klaim: on peut effectivement séparer les éléments de l'IHM en "dessinable", "saisissable", etc... mais j'ai l'impression que cette distinction n'apporte pas grand chose. Quelque chose de dessinable, c'est juste un "élement d'interface" qui a une méthode Paint()

@koala : le zOrder, c'est une propriété de l'OS, pas du framework... On ne peut le débrayer, sauf à changer l'OS.

Francois

[JolyLoic]

Typiquement, ca se gère avec des callbacks ca, non?

Justement, non... Ca se fait sous forme de templates, qui sont des données membre, et qui indique en quoi va être expandé telle ou telle partie. C'est bien plus puissant, dans le sens où la définition d'un template utilise exactement les mêmes mécanisme que la définition d'une boîte de dialogue, et donc peut facilement être mis en place grâce à un outil de design, sans changer de paradigme et sans écrire de code (et éventuellement par des graphistes, et non par des codeurs). En outre, comme ces objets savent où ils sont, leur taille... il n'y a pas besoin de modifier du tout le code de gestion des évènements, même si le contrôle a entièrement changé de forme.
Et grâce au binding on peut dire que la couleur de tel rectangle correspondra au backgroundColor de l'objet que l'on est en train de déployer.

J'ai bossé avec Qt2 (qui fonctionnait comme tu dis) et Wpf, et franchement, même si on peut obtenir le même résultat dans les deux cas, la liberté et la facilité apportées dans Wpf pour faire ça incite à bien plus explorer cette voie.

D'ailleurs, un autre point que j'aime bien, c'est que le dessin est globalement déclaratif et non procédural. On dit : Là, il y a un rectangle, là un cercle avec tel effet d'ombre. On ne dit pas : Pour te redessiner, passe par telle procédure. Ça facilite grandement les choses et libère l'esprit de tâches bas niveau (j'ai bougé tel objet, je dois redemander à ce qu'il y a derrière de se redessiner).

[Klaim]

@klaim: on peut effectivement séparer les éléments de l'IHM en "dessinable", "saisissable", etc... mais j'ai l'impression que cette distinction n'apporte pas grand chose. Quelque chose de dessinable, c'est juste un "élement d'interface" qui a une méthode Paint()

De manière plus abstraite, je dirais plutôt qu'il y aurait des éléments qui n'ont pas de réactions et d'autres qui en ont, sans forcément les séparer concrètement (avec ou sans listeners?).

Il faut effectivement prendre en compte les "nouvelles technologies" (allez, disons plutôt les technologies émergentes ), entre autre, au niveau des entrées et sorties, mais tout le monde n'a pas *forcément* un écran tactile et tout le monde n'a pas *forcément* envie de gérer *toutes* ses applications à coup de clin d'œil ou de reconnaissance vocale...

Le mieux à faire, pour l'instant, me semble être de considérer le fait que la souris est... un système de pointage, tout comme peut l'être le doigt avec un écran tactile ou comme pourrait l'être l'oeil avec une camera.

En fait, entre la partie "entrées" et la partie principale qui décrit l'interface, si la communication ne se fait qu'avec des signaux/events qui fournissent un objet qui contient des informations décrivant la zone ou la position ou autre élément spatial ou abstrait type touche de clavier qui serait concernée par le message, alors on peut gérer n'importe quel type de périférique vu qu'il suffit ensuite d'effectuer une sorte de test de collision pour savoir quels éléments réagissent.

[koala01]

Cela me semble réellement intéressant, d'autant plus que cela tend à confirmer le recours à une séparation franche entre le moteur de rendu, la déclaration des éléments visuels et la récupération des événements de périphériques d'entrées...

J'adore

Une fois l'interface créée (éventuellement par un graphiste qui ne s'occupe que de cela), il serait effectivement très simple pour le développeurs de rajouter les signaux et les slots (ou tout mécanisme similaire) aux différents élément pour permettre à l'application de fonctionner.

[Invité]

Justement, non... Ca se fait sous forme de templates, qui sont des données membre, et qui indique en quoi va être expandé telle ou telle partie.

Au bout du bout, tu auras une fonction "qui fait quelque chose".

Maintenant, tu l'implémenteras probablement comme une "données membre", parce que tu veux pouvoir la redéfinir à l'exécution, et avoir une fonction différente pour chaque instance (c'est l'esprit même d'un callback).

Ce que j'appelle "callback", c'est cette idée de pouvoir remplacer les procédures d'un composant par d'autes. C'est différent de l'approche consistant à modifier les paramètres d'appels de ces procédures 'fixes'.

En C++, on peut le faire de plusieurs facons, qui vont des pointeurs "closure" sur fonction membre, aux pointeurs sur fonctions "libres", aux foncteurs et à des classes templatisées plus complexe, mais ca reste des callbacks...

Francois

[Invité]

Une fois l'interface créée (éventuellement par un graphiste qui ne s'occupe que de cela), il serait effectivement très simple pour le développeurs de rajouter les signaux et les slots (ou tout mécanisme similaire) aux différents élément pour permettre à l'application de fonctionner.

Euh, attention... Ca, ça ressemble terriblement aux tables de messages de MFC, qui n'ont pas laissé un bon souvenir à ceux qui les utilisent...

En gros, oui, ca marche forcément comme ca au niveau le plus bas, mais le but d'un framework d'IHM, c'est de ne pas avoir à le faire de manière systématique.

Si tu n'en es pas convaincu, je te conseille d'aller voir dans la doc API Windows, et de voir combien de messages différents sont "gérables" par une bête combobox, même pas paramétrable... La derniere chose que tu veux, c'est demander au programmeur de tous les connaitre pour changer l'apparence de son composant...

(Et puis, un framework ou il faut un graphiste et un programmeur, ce n'est pas une avancée : ca augmente le cout de développement...)

Francois

[JolyLoic]

Au bout du bout, tu auras une fonction "qui fait quelque chose".

Maintenant, tu l'implémenteras probablement comme une "données membre", parce que tu veux pouvoir la redéfinir à l'exécution, et avoir une fonction différente pour chaque instance (c'est l'esprit même d'un callback).

En l'occurence, non, ce ne sont pas des callbacks, quelle que soit la manière de les implémenter. Par exemple (ce n'est pas la syntaxe du tout, c'est juste pour donner une idée) :
Une simple listBox :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

<ListBox ItemSource="{binding}" />

La même mais où je prends le contrôle du dessin de la bordure :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<ListBox ItemSource="{binding}">
  <ListBox.Template>
     <StackPanel>
         <Border BorderWidth="2" Brush="{TemplateBinding Brush}">
              <ItemsPresenter />
         <Button Content="Sort the list"/>
     </StackPanel>
  </ListBox.Template>
</listbox>

La même où je prend le contrôle du positionnement des objets à l'intérieur de la zone client :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<ListBox ItemSource="{binding}">
  <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
          <WrapPanel />
        </ItemsPanelTemplate>
  </ListBox.ItemsPanel>
</ListBox>

Dans tous les cas, je n'écrit pas de code procédural, qui dirait dessine ainsi ou ainsi, mais je dis plutôt : Voilà de quoi est composé telle ou telle partie de toi. De la même manière dont je dirais qu'une boîte de dialogue est composée d'une ListBox et de deux boutons.

[JolyLoic]

(Et puis, un framework ou il faut un graphiste et un programmeur, ce n'est pas une avancée : ca augmente le cout de développement...)

En pratique, c'est un framework où il faut un programmeur pour faire un programme fonctionnel. Si en plus, on veut un programme qui soit sexy, à la dernière mode, alors on peut prendre en plus un graphiste, et ce dernier pourra bosser en grande partie sans embêter les programmeurs à leur demander d'écrire du code pour changer l'aspect, ou à s'entendre dire que ses projets d'IHM sont très jolis mais trop chers.

[JolyLoic]

@jolyloïc :Si je me trompe pas (j'ai pas encore fait beaucoup de wpf), Qt va proposer quelques chose de semblable, en particulier avec QML qui est grosso modo leur réponse à xaml.

Ils ont déjà fait des petite chose, comme l'utilisation de css pour customiser l'ihm
http://qt.developpez.com/doc/4.7-snapshot/stylesheet/

et leur système de MVP
http://qt.developpez.com/doc/4.7-sna...w-programming/

Il me semble que GTK prépare aussi quelque chose.

De ce que j'ai compris de adam&eve ca semble assez proche de ce que propose xaml.

J'ai un peu regardé tes liens (rapide survol), et j'aime bien le fait qu'ils n'ont pas choisi un truc lourdeau comme le XML comme base de leur declarative UI.

Par contre, même si j'ai vu des aspects liés au binding, je n'ai pas trop compris comment lier des éléments de l'IMH à des éléments du code, or ce fait est essentiel en WPF et est à la base du framework M-V-VM qui est recommandé avec lui (au lieu de MVC/MVP), et qui me semble mieux correspondre à ce que j'imagine d'une architecture d'IHM.

Pour les feuilles de style, j'ai l'impression que tu peux modifier des propriétés d'éléments dans l'arbre de composition de contrôles, mais pas midifier cet arbre lui même ? Si c'est le cas, c'est une limitation assez forte.

Adam&Eve, je n'ai jamais eu le temps de regarder...