Discussion :

[koala01]

Salut,

Je présume que beaucoup d'entre vous (parmi ceux qui n'y ont pas participé) ont au moins aperçu le débat portant sur les framework utilisant un super objet.

Si, de manière générale, il ressort une chose certaine du débat, c'est que l'on se rend compte que la plupart des framework actuels ont été débutés lorsque... il aurait été difficile de faire sans super objet (soit dit sans tenter de minimiser en quoi que ce soit la valeur des projets).

Par contre, j'ai l'impression qu'il pourrait ne pas être totalement impossible, entre la SL, les template et boost (plus l'une ou l'autre des capacités de C++ n'entrant dans aucune de ces catégories), de créer une bibliothèque d'IHM et un framework associé (comprenez : capable de fournir tous les services que l'on retrouve dans Qt, par exemple) qui pourrait s'avérer aussi puissant, portable et souple sans avoir besoin de recourir à un super objet.


Je n'ai pas la prétention de connaitre toutes les bibliothèques graphiques existantes, et c'est la raison pour laquelle je voudrais avoir votre avis sur les questions suivantes :

1. Existe-t-il un framework d'IHM de ce style (adam et eve, peut être )
2. Si la réponse à (1) est "non", y aurait-il un intérêt quelconque à proposer un tel framework
3. Quels seraient difficultés majeures rencontrées lors de la mise au point d'un tel projet
4. Trouveriez-vous, par exemple, un intérêt quelconque à pouvoir créer un "data grid" basé sur des templates, un peu comme n'importe quelle collection de la STL
5. Certains d'entre vous seraient-ils intéressés par le fait de collaborer à un tel projet s'il était lancé
6. Toutes les questions qui pourront s'imposer en cours de discussion

Pour l'instant, je lance une idée en l'air, histoire de voir ce qui en ressortira avant de faire le tri. N'hésitez donc pas à donner votre avis, ni à justifier et commenter vos réponse, et encore moins à faire des propositions

Merci d'avance

[bruno_pages]

Bonjour,

le but est créer une une bibliothèque d'IHM et un framework associé juste pour éviter l'existence d'un super objet ? ca parait un peu non ?

comme tu l'as dit il y a Qt, et la version 4 est open source, même si j'ai une dent contre la 'version' 4 (qui n'est pas une nouvelle version mais en réalité un autre produit ayant des similitudes avec ce qu'était Qt3) il parait effarant de faire un équivalent. Il y aurait bien-sûr un intérêt technique, par contre au niveau business plan ...

[koala01]

Bonjour,

le but est créer une une bibliothèque d'IHM et un framework associé juste pour éviter l'existence d'un super objet ? ca parait un peu non ?

Ce ne serait bien sur pas le seul objectif, même si c'est l'idée de base.

Cela pourrait être, tout simplement, l'occasion de "réinventer" ou de "révolutionner" la création d'IHM en C++ et de s'affranchir également de cette étape supplémentaire imposée par Qt qu'est moc.

Des raisons pour le faire, il peut y en avoir à l'appel

comme tu l'as dit il y a Qt, et la version 4 est open source, même si j'ai une dent contre la 'version' 4 (qui n'est pas une nouvelle version mais en réalité un autre produit ayant des similitudes avec ce qu'était Qt3) il parait effarant de faire un équivalent.

Et avant, il y avait MFC, WxWidget et *curse...

Pourquoi serait il plus effarant de faire quelque chose de nouveau maintenant qu'à l'époque, étant donné que les techniques de programmation d'une part et les capacités techniques des ordinateurs d'autre part ont énormément évolué depuis le moment où l'idée de départ de Qt a été lancée

[Invité]

Avoir ou ne pas avoir de SuperObjet, c'est une décision d'implémentation, refaire un truc énorme juste sur une modification de décision d'implémentation, ca me parait un peu démesuré.

Maintenant, un projet de librairie d'IHM portable est une bonne idée. Le problème de Qt et des autres, c'est qu'ils sont devenus, au fil des ans, des machins énormes, dans lesquels on rentre comme en religion, qui doublonnent partiellement avec des éléments devenus standard depuis (la STL), et, surtout, qui imposent au converti un apprentissage lourd...

Bâtir un framework minimaliste, permettant de construire des applications fenêtrées, avec une sémantique suffisamment simple pour que l'utilisateur n'ait pas besoin de passer 6 mois à se former avant de produire quelque chose de décent, réellement portable, ça me parait être un gros projet, mais quelque chose de réellement utile.

Quelques contraintes qu'un tel projet devrait respecter :

1- faire de l'IHM et du framework général d'application, et juste ça
2- être conçue dans une optique d'économie de ressources (les IHM qui dévorent la mémoire, il y a largement le choix sur le marché...), et avec l'idée que le poste typique sur lequel tourne une appli IHM, ce n'est pas un poste moderne
3- penser portabilité (en terme d'OS, de compilateur, et de versions d'OS) dès le départ (et pour moi, ca veut dire pas de C0x machin chose... et même pas tout boost, des lib expérimentales pour machines de demain, ça ne manque pas)
4- réinventer, s'il le faut, l'implémentation, mais autant que possible recycler du look existant (tout en permettant une customisation): l'IHM ca doit être joli et familier...
5- se dire que pour être utilisée, une lib doit être facile à apprendre...
6- penser RAD : pour l'IHM, l'IDE fait partie de la lib...
7- penser "bascule" : la principale raison pour laquelle on utilise un framework, c'est qu'on a déjà des applis qui l'utilisent. Une "nouvelle lib minimaliste" doit être interopérable (sinon, on remplace juste une religion par une autre)

Francois

[yan]

Tu voudrais faire un truc comme ultimate++?
mais avec plus de fonctionnalité(comme les metadata) et basé exclusivement sur la S(T)L et boost?

[koala01]

Tu voudrais faire un truc comme ultimate++?

Comme je l'ai dit, l'aspect RAD serait bien plus secondaire que l'aspect bibliothèque IHM + framework...

mais avec plus de fonctionnalité(comme les metadata) et basé exclusivement sur la S(T)L et boost?

Je ne peux pas vraiment me prononcer sur le "plus de fonctionnalités", car je ne connais pas ultimate, mais l'idée serait effectivement de se baser exclusivement sur la S(T)L et (éventuellement) sur boost (ou du moins, de reprendre leur approche) comme fondations.

[koala01]

Avoir ou ne pas avoir de SuperObjet, c'est une décision d'implémentation, refaire un truc énorme juste sur une modification de décision d'implémentation, ca me parait un peu présomptueux.

Comme je l'ai dit par la suite, ce ne serait, bien évidemment, pas le seul objectif, même si l'absence de super objet ferait partie intégrante des spécifications

Ce n'est pas parce que j'ai basé ma première argumentation sur ce point qu'il faut en déduire que c'est forcément la seule raison qui m'incite à envisager de lancer un tel projet

Maintenant, un projet de librairie d'IHM portable est une bonne idée. Le problème de Qt et des autres, c'est que ce sont devenu, au fil des ans, des machins énormes, dans lesquels on rentre comme en religion, qui refont parfois les éléments devenus standard depuis (la STL), et, surtout, qui imposent au converti un apprentissage lourd...

Bâtir un framework minimaliste, permettant de construire des applications fenêtrées, avec une sémantique suffisament simple pour que l'utilisateur n'ait pas besoin de passer 6 mois à se former avant de produire quelque chose de décent, réellement portable, ça me parait être un gros projet, mais quelque chose de réellement utile.

Je crois qu'il ne faut pas se leurrer non plus...

Même si on décide de "commencer simple" et "minimaliste", il y a de fortes chances pour que l'on finisse tôt ou tard par décider de rajouter des "goodies" permettant de simplifier la vie des gens:

Tôt ou tard, nous risquons d'être confrontés à l'idée que "avoir la possibilité de gérer une BDD", ce serait pas si mal, idem pour n'importe quel autre aspect régulièrement mis en oeuvre en parallèle à une IHM

Mais bon, avant d'en arriver là, il y a surement de la marge

Quelques contraintes qu'un tel projet devrait respecter :

1- faire de l'IHM et du framework général d'application, et juste ça
2- être conçue dans une optique d'économie de ressources (les IHM qui dévorent la mémoire, il y a largement le choix sur le marché...), et avec l'idée que le poste typique sur lequel tourne une appli IHM, ce n'est pas un poste moderne
3- penser portabilité (en terme d'OS, de compilateur, et de versions d'OS) dès le départ (et pour moi, ca veut dire pas de C0x machin chose... et même pas tout boost)
4- réinventer, s'il le faut, l'implémentation, mais autant que possible reprendre du look existant: les nouvelles idées en IHM, c'est souvent laid...
5- se dire que pour être utilisée, une lib doit être facile à apprendre...
6- penser RAD : pour l'IHM, l'IDE fait partie de la lib...

Francois

1- Dans un premier temps, en tout cas... Comme je viens de le dire, il est toujours à craindre que nous finissions tôt ou tard par être emporté par notre élan

2- De fait, mais sans pour autant revenir aux interfaces à la "win 3.11" ...

3- Je comprends ce que tu veux dire, mais, il me semble cohérent de dire qu'il faudra de toutes manière effectivement poser certaines limites à la compatibilité des compilateurs... Un support correct de C++03 et de TR1 me semble le minimum requis pour y arriver

4- La "beauté" est très suggestive, mais j'adhère cependant à l'argument... Même si on peut envisager la possibilité de personnaliser le "look'n feel"

5- Sur ce point, rien à redire

6- Je ne suis pas contre une approche RAD, loin de là, mais à condition que ce soit le RAD qui vienne s'articuler autour de la bibliothèque / le framework, et non la bibliothèque qui s'articulerait à ce point autour du RAD qu'elle en devienne inutilisable si, pour une raison ou une autre, nous venions à ne pas disposer du RAD

[Invité]

Même si on décide de "commencer simple" et "minimaliste", il y a de fortes chances pour que l'on finisse tôt ou tard par
décider de rajouter des "goodies" permettant de simplifier la vie des gens:

Oui... Ce que je remarque, dans pas mal de librairies, c'est qu'elles sont encombrées de "goodies permettant de flatter l'égo de leurs concepteurs". En bons informaticiens, ils n'ont pu s'empêcher d'ajouter "leurs" conteneurs, leurs chaines, leurs fonctions mathématiques et statistiques, leurs utilitaires qu'ils aiment bien...

L'autre idée, c'est que pas mal de librairies prèfèrent refaire que gérer l'interopérabilité.

Rien qu'en éliminant ca, je pense qu'on réduit beaucoup la taille du framework...

Tôt ou tard, nous risquons d'être confrontés à l'idée que "avoir la possibilité de gérer une BDD", ce serait pas si mal, idem pour n'importe quel autre aspect régulièrement mis en oeuvre en parallèle à une IHM

Il faut s'entendre sur ce que tu appelles un framework d'IHM. A mon avis, tu ne peux échapper à l'interfacage avec des BDD, tout comme il est légitime de fournir dans une IHM quelques composants non visuels comme les Timers, qui sont dans le champ de l'IHM.

C'est peut être le plus difficile, en fait (et la partie la plus intéressante du projet) : définir à l'avance ce qu'on entend par framework d'IHM, et s'y tenir.

3- Je comprends ce que tu veux dire, mais, il me semble cohérent de dire qu'il faudra de toutes manière effectivement poser certaines limites à la compatibilité des compilateurs... Un support correct de C++03 et de TR1 me semble le minimum requis pour y arriver

Je ne sais pas. Il me semble que le coeur d'une telle librairie n'a pas forcément besoin de grand chose, côté C++ moderne. Si ce n'est pas nécessaire, alors il ne sert à rien de l'y introduire. Pour le reste, l'avantage d'une librairie moins hiérarchique que les autres, c'est de pouvoir justement avoir des modules plus ou moins exigeants... Tu pourrais avoir un petit subset qui compile absolument n'importe où (y compris dans des environnements très exotiques), et des modules qui ont besoin de toute la panoplie.

Il faut juste regarder ce qu'est le "coeur", et ce dont il a besoin.

6- Je ne suis pas contre une approche RAD, loin de là, mais à condition que ce soit le RAD qui vienne s'articuler autour de la bibliothèque / le framework, et non la bibliothèque qui s'articulerait à ce point autour du RAD qu'elle en devienne inutilisable si, pour une raison ou une autre, nous venions à ne pas disposer du RAD

Oui. Je crois néanmoins que le RAD est ce qui attire l'utilisateur. Il faut bien voir que ces bibliothèques sont souvent développées par des gens qui ont du mal à s'imaginer programmer autrement qu'avec Vim, pour des utilisateurs qui sont fanatiques de l'IDE.

On est dans un de ces nombreux cas où ceux qui font ne sont pas ceux qui utilisent...

Francois

[Luc Hermitte]

(j'ai aussi lu en diagonale de retour de vacances)

1. Existe-t-il un framework d'IHM de ce style (adam et eve, peut être )
2. Si la réponse à (1) est "non", y aurait-il un intérêt quelconque à proposer un tel framework
3. Quels seraient difficultés majeurs rencontrées lors de la mise au point d'un tel projet
4. Trouveriez vous, par exemple, un intérêt quelconque à pouvoir créer un "data grid" basé sur des template, un peu comme n'importe quelle collection de la STL
5. Certains d'entre vous seraient-ils intéressés par le fait de collaborer à un tel projet s'il était lancé

Pour l'instant, je lance une idée en l'air, histoire de voir ce qui en ressortira avant de faire le tri. N'hésitez donc pas à donner votre avis, ni à justifier et commenter vos réponse, et encore moins à faire des propositions

1- En effet, Adobe.ASL me parait répondre à la question.

2,4- L'intérêt premier d'Adobe.ASL est le côté declarative UI. Après qu'ils aient pris une approche templatisée et DRY (ils s'appuient sur boost et sur Intel TBB) est un bonus.

3- Ne pas se décourager pour fournir un ensemble de widgets tout aussi riches. Cela fait bien un à deux ans qu'il n'y a plus rien eu sur Adobe.ASL
Autre difficulté: la portabilité. Je ne parle pas du support de plateformes de compilation antédiluviennes[*], mais de portabilité des éléments graphiques.

5- Je ne pense pas en avoir le temps. En revanche je ne peux que vous conseiller de jeter sérieusement un oeil à adobe.ASL. Pas en termes de code, mais d'abord en termes d'articles. Il me parait plus intéressant de contribuer à de l'existant que de repartir from scratch. Ce double framework répond à l'essentiel de vos besoins non-discutables. C'est juste qu'il n'y a personne pour travailler dessus et continuer de le faire vivre, ce qui est fort dommage je trouve.


EDIT:[*] J'estime qu'il faut viser C++03. Même s'il est vrai que les rvalue-references vont rendre complètement désuètes les approches COW de Qt, et une autre à la auto_ptr d'Ultimate++ (à moins que ce fut-ce un autre framework)

[koala01]

(j'ai aussi lu en diagonale de retour de vacances)

Etaient-elles bonnes (bon, évitons ce genre de digressions )

Ceci dit, ce que tu as écrit au sujet de ASL m'interpelle, dans le sens où je me pose plein de questions sur le sujet...

Par exemple, il semblerait (à lire les "release notes" que l'un des responsables du projet ait quitté adobe. Serait-ce une des raisons de la désertion du projet

Si le projet était si bien (et je ne met pas sa qualité en cause), qu'est-ce qui fait qu'il soit resté d'un usage "si confidentiel", et qu'il semble destiné à tomber dans l'oubli Pourrait-ce être à cause du désintérêt d'adobe pour le sujet

N'aurait il pas été mieux servi par une équipe croyant dans le projet ne se dispersant pas dans toutes les directions dans lesquelles adobe se lance (entre flash, flex, et toutes ses applications, il y a déjà tellement de boulot )

Serait il vraiment plus simple de "déterrer" un projet pour le faire revivre que de lancer quelque chose de neuf avec une équipe nouvelle

Nous pourrions en effet envisager de lancer une campagne rédactionnelle sur le projet (essayer de trouver plusieurs rédacteurs qui feraient des articles dessus), mais serait-ce suffisant pour en raviver l'intérêt

Peut être pourrions nous réfléchir à cette série de questions... Peut-être ne serait-ce qu'une "perte de temps".

Pour ta dernière remarque, je voudrais préciser que nous partirions carrément sur du C++11, quitte à voir jusqu'où il serait possible de faire remonter la compatibilité ascendante avec d'anciennes plateformes.

Pour l'instant, aucune décision ferme n'a encore été prise de lancer le projet dont nous parlons ici, il est donc tout à fait possible d'effectuer un virage à 180°.

Simplement, il me semble utile de prendre la décision maintenant, autrement, cette discussion s'éternisera et ne sera plus qu'une perte de temps pour tous les intervenants, au même titre que bon nombre de discussions stériles que l'on trouve sur le forum.

Comme je l'ai dit, je suis (et je reste) disposé à tenter l'aventure, mais j'ai trop bien conscience de l'ambition du projet pour ne serait-ce qu'espérer le mener à bien tout seul.

Il serait peut être temps de mettre un GO ou un NO GO, histoire de voir si on décide d'aller plus loin en commençant l'écriture des spécifications ou si on se sert la main en se promettant de s'écrire...

Même en gardant en tête le manque de temps flagrant de tous ceux qui se sont exprimés, si chacun peut, à son niveau, participer non pas régulièrement mais au moins ponctuellement, je vous répète ma conviction qu'il y a moyen d'y arriver... Simplement, je n'y arriverai pas tout seul.

Qui me suit qui passe "à autre chose"

[Luc Hermitte]

Par exemple, il semblerait (à lire les "release notes" que l'un des responsables du projet ait quitté adobe. Serait-ce une des raisons de la désertion du projet

J'ai l'impression qu'il s'agit au départ d'un projet interne qu'ils ont ouvert pour des raisons qui étaient les leurs.

Un petit lien sympa.
http://stackoverflow.com/questions/1...699225#1699225

Si le projet était si bien (et je ne met pas sa qualité en cause), qu'est-ce qui fait qu'il soit resté d'un usage "si confidentiel", et qu'il semble destiné à tomber dans l'oubli

Avec un responsable en moins et une forte concurrence, plus une utilisabilité suffisante pour leurs besoins, je ne suis pas étonné de l'état du projet. Contrairement à Trolltech, ce projet n'est pas leur coeur de métier. Juste une toolbox antibug (ma libre interprétation du tuto sur le site).
Le côté révolutionnaire n'a pas dû aider. De même que le côté pas prêt pour de la production hors de chez Adobe.

N'aurait il pas été mieux servi par une équipe croyant dans le projet ne se dispersant pas dans toutes les directions dans lesquelles adobe se lance (entre flash, flex, et toutes ses applications, il y a déjà tellement de boulot )

Adobe est je pense une grosse boite. Je ne considère pas qu'il s'agisse plus d'une question de se disperser que ce que l'on voit avec google : ils ont leur labo.

Serait il vraiment plus simple de "déterrer" un projet pour le faire revivre que de lancer quelque chose de neuf avec une équipe nouvelle

Nous ne partons pas des mêmes hyppothèses :
- ils ont des cadors qui ont bossé là dessus, et d'autres cadors dans les bureaux d'à côté (cf les noms attachés aux divers articles)
- ils sont parti de leur retour d'expérience en tant qu'utilisateurs de framework IHM pour leur applis gourmandes (photoshop)
- ils ont capitalisé une expérience (bonne ou mauvaise)
- ils ont documenté quantité de choses
- ils suivent les mêmes contraintes que ce que tu cherches à lancer (au détail sur C++11) -> DRY (SL/boost/Intel TBB), moderne, pas de super objet, les divers découplages mentionnés, portable, ...

Donc, quiconque se lance dans un même projet a tout à gagner à analyser leur choix avant de se lancer tête baissée dans une direction, quelle qu'elle soit.

J'aime bien commencer par un état de l'art chez les plus proches "concurrents".

Bref avant de le relancer, regardons juste ce qu'ils font et comment ils le font. Même si ASL n'est pas relancé au final, je pense qu'il s'agira d'une étude intéressante et pertinente pour tous les choix faits qui répondent aux même besoins que ceux exprimés ici.

@ lavock, Adam&Eve sont deux des sous-composant de Adobe.ASL. Adam est le moteur de contraintes (utilisé aussi pour résourdre des sudoku), et Eve un moteur de rendu. (IIRC).
Ils ont patchés certaines choses dans boost, et écrits diverses choses. Certaines devaient être soumises chez boost. Dans tous les cas, il n'y a rien eu de redondant -- ils ont eu besoin de chaines 0-copie, ou des COW, ils en ont écrites, sinon ils réutilisent (c'est une autre différence avec Qt, parfois il y a une multiplication des types chaines au lieu d'imposer une approche qui n'est pas bonne tout le temps)

[koala01]

Nous ne partons pas des mêmes hyppothèses :

J'étais volontairement provoquant...

Quoi de mieux pour provoquer des réactions

Donc, quiconque se lance dans un même projet a tout à gagner à analyser leur choix avant de se lancer tête baissée dans une direction, quelle qu'elle soit.

J'aime bien commencer par un état de l'art chez les plus proches "concurrents".

Bref avant de le relancer, regardons juste ce qu'ils font et comment ils le font. Même si ASL n'est pas relancé au final, je pense qu'il s'agira d'une étude intéressante et pertinente pour tous les choix faits qui répondent aux même besoins que ceux exprimés ici.

Tout à fait...

Il y a, très certainement, énormément à apprendre de ce qu'ils ont fait, tout comme il y a à apprendre de ce que Qt ou WxWidget a fait, des problèmes auxquels ils ont été confrontés et des solutions qu'ils ont apportées

Je dirais presque que leurs déboires sont plus importants que leur réussites, d'ailleurs

[Lavock]

Je suis pas bien renseigner dans le monde des IHMs, mais adam&eve n'aurai-il pas un très fort rapport avec adobe asl ?

Sinon, je vais de regarder vite fait adobe asl, il semble qu'il ne respecte pas un des principes de base de Koala's mushrooms (!?!) => ils utilisent boost d'un côté, mais semble re-écrire de ses parties de l'autre. Je peux me tromper, j'ai vraiment regarder rapidement.

Pour le côté ultra-séparatiste (déclaration/affichage/io) cela ne tendrait pas à carrément annihiler le principe même du widget ?

C'est une impression, mais les widget sont utiles car justement il borne, fonctionnellement et visuellement paralant, un élément qu'on va afficher. Or final, j'ai l'impression qu'on se retrouve avec :

• Je déclare une zone
• Qui à l'air de ça
• Dont les "données" sont là
• Sachant qu'il se passe ça sur mes données lors de tel event

Où sont les widgets ? Dans le "Je déclare une zone" ? J'ai pas l'impression. Dans les données ? pas vraiment non plus.

Si c'est juste pour les timelines, je dirais : Mais minces ! Et si j'ai envie qu'une de mes zones perdurent alors que la "contenante" meurt ?
Pire, dans la plus part des cas, j'ai besoin de garder toutes les info tel quel, mais de juste arrêter d'éxecuter l'affichage... Et parfois, j'ai besoin uniquement de quelque swap.
Au final, chaque timelines devrait pouvoir être gérait individuellement non ?


Donc du coup, je me demande quel est la place des "widgets" en considérant une tel architecture? Ai-je manqué quelque chose ? Vous l'avez peut-être "naturellement" pris en compte vu vos niveau par rapport au mien, mais j'avoue que ça me laisse perplexe.

En même temps, je suis peut-être juste à côté de la plaque :/

[edit] Honnêtement et humblement, j'ai envie de dire GO :p

[Invité]

Pour le côté ultra-séparatiste (déclaration/affichage/io) cela ne tendrait pas à carrément annihiler le principe même du widget ?

En fait, pas forcément... Tu peux imaginer l'approche de séparation en termes de drivers.

La séparation, c'est le fait qu'on communique avec le "matériel" (périphériques de saisie ou moteurs de rendu) au travers d'une API spécifique, que chaque matériel doit alors implémenter. On a alors un problème nouveau : quelle taille pour cette API, trop petite, elle ne permettra pas d'utiliser les nouvelles fonctionnalités des périphériques, trop grande, elle devient difficile à mettre en oeuvre. Cette approche par driver est une application du principe de Koenig (le niveau d'indirection supplémentaire)

Mais le fait qu'on sépare ne signifie pas la mort du widget : quelque part, ton interface, déclarative, arborescente, ou en forme de poire, sera constituée d'éléments "atomiques" (classes, templates, ou schmurtzs), qui seront chargés (au travers de callbacks, de données membres, de traits,...) d'appeler l'API de rendu (ou de saisie).

C'est ça, les widgets...

Francois
(qui trouve que la discussion est encore bien trop imprécise pour dire GO ou NO GO, mais peut être que ca veut juste dire GO sans lui)

[koala01]

(qui trouve que la discussion est encore bien trop imprécise pour dire GO ou NO GO, mais peut être que ca veut juste dire GO sans lui)

Ou peut être que je me suis mal exprimé...

Pour moi, le NO GO à l'heure actuelle serait plus proche de la décision de relancer ASL...

Si, déjà, il venait à y avoir plus de réactions proches de "voyons si on peut ressusciter ASL", le NO GO serait évident...

Si par contre, il reste un grand nombre de "je me laisserais bien tenter, mais...", le GO serait accepté sur le principe, et nous pourrions continuer à discuter sans que la décision de commencer ce nouveau projet ne soit remise en question dans dix pages de discussion

Soit, nous décidons que c'est un projet qui vaut la peine d'être lancé, et nous essayons réellement de préciser tout ce qui doit l'être (car il y a sans doute encore beaucoup de points à aborder ) et ceux qui ne sont pas intéressés s'engagent, en tout cas, à ne plus venir avec des "oui, mais bon, MachinChose n'est pas si mal... pourquoi vouloir faire mieux" (*), soit on se dit que je suis sans doute un peu fou de vouloir "révolutionner" la manière dont les IHM sont créées, et la discussion est close

J'ai l'impression que nous partons plutôt dans la première direction

(*) Maintenant, s'il viennent avec des "tel truc n'est pas si mal, ce serait sympa de le prévoir", leur proposition sera étudiée avec tout le sérieux nécessaire

[Lavock]

Mais le fait qu'on sépare ne signifie pas la mort du widget : quelque part, ton interface, déclarative, arborescente, ou en forme de poire, sera constituée d'éléments "atomiques" (classes, templates, ou schmurtzs), qui seront chargés (au travers de callbacks, de données membres, de traits,...) d'appeler l'API de rendu (ou de saisie).

C'est ça, les widgets...

Hum, en fait, ça m'a plus embrouillé qu'autre chose. Les éléments "atomiques" comme tu les appelles seront au final dispersé. Qui aura la charge de se faire appeler widget ? Le tout ? dans se cas, c'est plus une notion super-abstraite qu'une existence réel ?

@Luc : Merci pour les précisions

[Invité]

c'est plus une notion super-abstraite qu'une existence réel ?

C'est pourtant ce que tu vas présenter à l'utilisateur, non? Une interface formée de "composants" qui peuvent avoir des données, recevoir des sollicitations clavier ou souris (ou tout autre périphérique de saisie), et s'afficher.

Ces composants devront bien avoir une existence dans le système, des types paramétrés probablement (puisqu'on ne les fait pas descendre d'un superWidget). Mais l'implémentation de leurs données, de leur dessin, et de leur interaction saisie seront déléguées, en vertu de la séparation...

C'est peut être juste moi, mais j'ai beaucoup de mal à imaginer un modèle d'IHM qui n'utilise pas des widgets (quelqu'autre nom qu'on leur donne), ou alors on tombe dans l'interface "totalement dessinée" des jeux vidéos, qui s'apparente davantage à une vidéo calculée en runtime qu'à une IHM (et qu'on pourrait même considérer, dans un modèle à widget comme un widget unique).

Peut être est ce un point sur lequel on peut statuer assez vite, d'ailleurs.

Y a-t-il d'autres options? En veut on?

Francois