Discussion :

[koala01]

(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

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.

Je plussoie avec Loïc, car tu semble avoir "zappé" le mot le plus important : éventuellement...

Lorsque je crées une IHM, j'ai tendance à être affreusement conventionnel sur la présentation que je lui donne, tout comme, lorsque je code un site web, il est techniquement très au point, mais il reste très (trop ) conventionnel, mais je le dis sans honte: mon dada, c'est la technique.

Par contre, dans certaines conditions, il *peut* être intéressant de s'adjoindre les services d'un designer.

Il n'a pas besoin de s'attaquer au coté technique de la chose (ca, c'est mon domaine), mais son rôle est "de faire du joli".

Le risque, si il vient à s'occuper de modifier le code pour atteindre son objectif, c'est qu'il bousille purement et simplement "le reste".

Dans le meilleur des cas, il me demandera de modifier le code pour refléter ses décisions... Alors que je suis occupé à essayer d'apporter une solution à un problème bien plus grave que le simple fait de "faire joli".

Si nous pouvons séparer l'apparence des éléments affichables de la manière dont ils réagissent, un gars plutôt conventionnel pourra parfaitement faire son interface conventionnelle, mais une boite disposant d'un "IHM designer" pourra parfaitement faire appel à ses talents, sans que cela n'intervienne sur la partie métier de la chose.

S'il est possible de dire qu'un bouton doit être rose bonbon, rond, avec une police de caractères Ghotic au lieu d'être un bête bouton carré, sur une nuance de gris avec la police de caractères par défaut sans que cela n'implique que celui qui décide de changer l'apparence du bouton ne doive venir mettre "ses sales pattes pleines de doigts" dans mon code, cela ne pourra être considéré que comme un avantage

[ElPedro]

Comme l'a justement vu fcharton, j'ai fait exprès de mettre des exemples bien tordus qui :
1/ ne reposent que sur le moteur de rendu (et pas de methode paint heritee) (j'avais lu le poste de Klaim sur la separation du moteur rendu)
2/ ne reposent que sur l'interface d'entree. (vrpn anyone ?)

En fait les 2 exemples ne remettent pas en cause la notion de widget.

C'était juste pour dire, qu'il est souvent préférable de donner des idées en l'air pour ensuite se poser la question : est-ce que tel resultat est faisable ? est-ce que cela remet en cause mon framework? Est-ce que je considère que tel effet ou effet ne m'intéressent pas (pour borner le projet)?

koala, tu as raison, il n'y a pas que FLTK dans la vie .

[koala01]

Comme l'a justement vu fcharton, j'ai fait exprès de mettre des exemples bien tordus qui :
1/ ne reposent que sur le moteur de rendu (et pas de methode paint heritee) (j'avais lu le poste de Klaim sur la separation du moteur rendu)
2/ ne reposent que sur l'interface d'entree. (vrpn anyone ?)

En fait les 2 exemples ne remettent pas en cause la notion de widget.

C'était juste pour dire, qu'il est souvent préférable de donner des idées en l'air pour ensuite se poser la question : est-ce que tel resultat est faisable ? est-ce que cela remet en cause mon framework? Est-ce que je considère que tel effet ou effet ne m'intéressent pas (pour borner le projet)?

Ca semble plaider en faveur d'une séparation nette entre les différents aspects que sont le rendu, la gestion des périphériques et la déclaration des éléments...

Car, dans l'absolu, si les trois sont clairement séparés, il devient parfaitement possible d'utiliser "quelque chose de similaire", par exemple, faisant appel à "un autre système de pointage" que la souris ou à un affichage 3D.

Au pire, la seule contrainte que nous aurons sera... d'assurer la présence d'une interface commune pour les différents aspects

[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"

[Invité]

Je plussoie avec Loïc, car tu semble avoir "zappé" le mot le plus important : éventuellement...

Je ne suis pas très futé, mais je l'avais quand même lu...

Tous les frameworks actuels, quels qu'ils soient, permettent des skins (sous différentes formes), qui font que, si on a un graphiste, on peut facilement améliorer l'interface (enfin, si le développeur est au courant de cette possibilité et l'a déjà prise en compte).

Un nouveau framework doit permettre cela, mais ce n'est pas innovant. Ce qui le serait davantage, ce serait de permettre au développeur de faire joli (à partir de modeles prédéfinis et facilement modifiables et réutilisables) à partir d'une bête charte graphique, et sans graphiste.

Parce qu'à mon avis, il y a bien plus de projets qui n'ont pas de graphistes que de projets qui en ont...


Plus généralement, le problème que je vois à cette approche, c'est l'idée qu'on peut joliment séparer données et traitements (cf la discussion sur les callbacks), que du moment qu'on a une approche déclarative, alors tout devient paramétrable (ben voyons), et que la "vue d'artiste" peut s'intégrer sans douleur dans un framework, sans qu'il y ait de trade offs avec la "développabilité" de celui ci, ou ses performances.

L'idée que tout est séparable ne survit jamais longtemps à la réalité,

- soit parce certaines choses, veut veut pas, sont malgré tout liées (eg le moteur de rendu agnostique... tôt ou tard on bute sur les primitives de l'OS, ou le système d'entrée qui a "tout prévu"),
- soit parce que le cout de cette séparation, en terme d'accroissement de la complexité du framework, est prohibitif,
- soit parce que même si "ce serait bien" de pouvoir tout séparer, on veut surtout que les choses restent liées par défaut (c'est ma principale objection à pas mal d'UI déclaratives : la quantité de code qu'il faut taper pour produire un truc moche reste assez impressionnante, et comme le code n'est pas destiné aux programmeurs eux mêmes, ceux ci ont un peu tendance à ne pas le rendre très amical)

Je suis probablement déformé par mon expérience de FLEX, mais le peu que j'ai vu de l'approche d'ADOBE dans ce domaine me suggère que c'est plus un anti-modèle qu'un modèle...

Francois

[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]

Je ne suis pas très futé, mais je l'avais quand même lu...

Je ne voulais absolument pas sous entendre que tu n'étais pas futé...

Si telle est l'impression que j'ai donnée, je t'en fais toutes mes excuses les plus sincères

Tous les frameworks actuels, quels qu'ils soient, permettent des skins (sous différentes formes), qui font que, si on a un graphiste, on peut facilement améliorer l'interface (enfin, si le développeur est au courant de cette possibilité et l'a déjà prise en compte).

Peut-être ne vais-je raler que sur la manière dont c'est abordé par l'existant, mais, quand on voit les RAD existant, on se rend compte que tout est systématiquement accessibles à tous:

Les propriétés propres à la seule apparence d'un élément visuelles côtoient allègrement les attributs purement fonctionnels (comme la possibilité de changer ou non la valeur d'un champs), quand il n'est pas possible (eg comme sous borland) d'aller "titiller" directement les événement auxquels l'élément doit réagir.

Et, bien souvent, la création d'un widget personnalisé passe par... la programmation pure et simple: si on veut créer une data grille perso, il faut... se taper du code C++ pour tout (ou peu s'en faut).

Un nouveau framework doit permettre cela, mais ce n'est pas innovant. Ce qui le serait davantage, ce serait de permettre au développeur de faire joli (à partir de modeles prédéfinis et facilement modifiables et réutilisables) à partir d'une bête charte graphique, et sans graphiste.

d'accord, mais qu'est-ce qui empêcherait, justement, que ce soit un graphiste (ou n'importe qui "pas trop maladroit en dessin") qui propose ces modèles prédéfinis

Si "n'importe qui" peut sauvegarder l'apparence d'un objet visuel, dans un format donné éventuellement généré par ailleurs), son utilisation peut être aussi simple que d'utiliser un menu "nouveau->selon modèle"...

Plus généralement, le problème que je vois à cette approche, c'est l'idée qu'on peut joliment séparer données et traitements (cf la discussion sur les callbacks), que du moment qu'on a une approche déclarative, alors tout devient paramétrable (ben voyons), et que la "vue d'artiste" peut s'intégrer sans douleur dans un framework, sans qu'il y ait de trade offs avec la "développabilité" de celui ci, ou ses performances.

Le fait de croire que la séparation des différents aspects permet de tout résoudre et de lever toutes les limites s'apparente très certainement à une utopie, je te l'accorde.

Par contre, si l'on arrive à appliquer une séparation claire et maximale entre les différents éléments, nous pouvons arriver à lever un nombre important de restrictions.

La plupart du temps, les restrictions qui ne sont pas dues au matériel utilisées sont beaucoup plus dues aux dépendances dont souffre un aspect donné qu'à l'aspect lui-même.

Limitons les dépendances entre les trois aspects, nous lèverons de facto une bonne partie des restrictions dans chacun d'eux

L'idée que tout est séparable ne survit jamais longtemps à la réalité,

C'est pourtant l'un des principes récurrent de la programmation, quel que soit le côté d'où l'on regarde, c'est toujours du "diviser pour mieux régner"

- soit parce certaines choses, veut veut pas, sont malgré tout liées (eg le moteur de rendu agnostique... tôt ou tard on bute sur les primitives de l'OS, ou le système d'entrée qui a "tout prévu"),

Il y a, effectivement, certaines limites insurmontables: vouloir créer un élément affichable en 3D alors que le moteur de rendu ne fonctionne qu'en 2D parrait... irréalisable

C'est la raison pour laquelle il me semble important de prévoir, à terme, la possibilité de la mise au point d'autres moteurs de rendus ou d'autres système d'entrées...

Tu auras, fatalement, des modèles qui ne pourront pas fonctionner avec un moteur donné, mais il "suffira" de brancher l'autre.

Cela pourrait simplement passer par l'utilisation d'une bibliothèque partagée différente

- soit parce que le cout de cette séparation, en terme d'accroissement de la complexité du framework, est prohibitif,

Ce sera peut être le cas... ou pas...

Tant que nous ne serons pas en période de conception, il sera difficile de répondre à cette question

- soit parce que même si "ce serait bien" de pouvoir tout séparer, on veut surtout que les choses restent liées par défaut (c'est ma principale objection à pas mal d'UI déclaratives : la quantité de code qu'il faut taper pour produire un truc moche reste assez impressionnante, et comme le code n'est pas destiné aux programmeurs eux mêmes, ceux ci ont un peu tendance à ne pas le rendre très amical)

C'est à nous, développeurs, de veiller à ce que ce qui ne nous est pas "directement destiné" reste malgré tout amical...

Je me sens totalement capable de faire respecter ce point

(dois-je avouer que je risque d'être chiant en supprimant à vue toute version qui ne respecte pas les règles qui seront imposées par les specs, une fois qu'elles seront écrites )

[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

[epsilon68]

on voit malgré tout l'orientation XAML ou XUL d'une UI.
moi meme j'ai vu l'HTML prendre le pas sur toutes les applis dans mon domaine (appli de gestion)

d'ailleurs j'en suis venu a ne faire que de l'HTML / Javascript, meme pour des appli desktop. (flash pour quelques trucs plus waoo effects)

j'adore le javascript, c'est dynamique et facile à faire plein de workaround pour des quick fixes.
J'aime l'html car ca peut se redesigner en peu de temps et paraitre vraiment super sexy.

maintenant pour faire des super transitions comme XAML, alors il faut utiliser des libs comme JQuery / JQuery-UI mais il faudra un peu plus de code.

Sinon j'aime aussi bien Flash, on peut tout faire tres design et super animé,
mais j'aime pas flex, je n'aime pas en general l'XML pour decrire ma scene.

D'apres mon experience et les designers qui travaillent avec moi,
ils designent tres bien (et uniquement) l'html (avec css etc) et le flash.

Donc l'interface du futur ne serait-il pas un mixe de l'html / flash (timeline) et socle commun comme le javascript avec C++ (ou C#) backend
(en vue du tout internet)

ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)

[metagoto]

Revenons aux fondamentaux:

Le truc qui me chagrine (OK, j'exagere) c'est qu'il me parait bien vain de partir dans toutes les directions à propos de serialisation, de langage déclaratif, de stylesheets, de présence ou non de designer (qui ne va jurer que par l'iPhone et l'iPad), AVANT d'avoir étudier sérieusement les sub systems de windowing des OS dont on peut raisonnablement penser qu'ils doivent être supportés.

Qui est expert en win32, gtk, cocoa, opengl etc ?
Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?

Sans une parfaite compréhension des particularités intrinsèques de ces sub systems (api, messages pumps, gdi, threading, etc etc), on ne va pas aller bien loin

[yan]

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.

moi aussi

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.

Ce n'est pas aussi automatique qu'avec visual qui fait tout le travail. (qui permet d'exploiter les composante de xaml directement avec le code).

Avec Qt Quick, c'est le développeur qui fournie les instances à l'engine. En simple qml est du script qui peut exploiter tes classes grâce au metadata.
En soit, qml ne sait pas ce qu'il manipule juste qu'il veut utiliser quelque chose qui s'appel maClasse, qui as une propriété foo et une fonction bar().

[koala01]

on voit malgré tout l'orientation XAML ou XUL d'une UI.
moi meme j'ai vu l'HTML prendre le pas sur toutes les applis dans mon domaine (appli de gestion)

d'ailleurs j'en suis venu a ne faire que de l'HTML / Javascript, meme pour des appli desktop. (flash pour quelques trucs plus waoo effects)

j'adore le javascript, c'est dynamique et facile à faire plein de workaround pour des quick fixes.
J'aime l'html car ca peut se redesigner en peu de temps et paraitre vraiment super sexy.

maintenant pour faire des super transitions comme XAML, alors il faut utiliser des libs comme JQuery / JQuery-UI mais il faudra un peu plus de code.

Sinon j'aime aussi bien Flash, on peut tout faire tres design et super animé,
mais j'aime pas flex, je n'aime pas en general l'XML pour decrire ma scene.

D'apres mon experience et les designers qui travaillent avec moi,
ils designent tres bien (et uniquement) l'html (avec css etc) et le flash.

Donc l'interface du futur ne serait-il pas un mixe de l'html / flash (timeline) et socle commun comme le javascript avec C++ (ou C#) backend
(en vue du tout internet)

Peut être parce que cette solution est... dépendante de la présence d'un navigateur web graphique

Or, l'idée de base est, malgré tout, de permettre aux gens de... créer un navigateur web graphique s'ils le souhaitent (des fois qu'ils voudraient faire concurrence à IE et à firefox )

ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)

Ce point pourrait effectivement être beaucoup plus facile à mettre en oeuvre avec une approche d'IHM déclarative...

Par exemple, en HTML, il est possible d'utiliser une partie de dessin pour représenter un bouton sans que la souris ne soit dessus et une autre partie du même dessin pour représenter le même bouton lorsqu'il est survolé par la souris, ou lorsque l'on clique dessus.

L'IHM déclarative faciliterait ce genre de mise en oeuvre, même s'il ne faut pas se leurrer: il y aura très certainement nécessité de "convertir" les codes HTML et/ou CSS pour pouvoir les utiliser

[koala01]

Revenons aux fondamentaux:

Le truc qui me chagrine (OK, j'exagere) c'est qu'il me parait bien vain de partir dans toutes les directions à propos de serialisation, de langage déclaratif, de stylesheets, de présence ou non de designer (qui ne va jurer que par l'iPhone et l'iPad), AVANT d'avoir étudier sérieusement les sub systems de windowing des OS dont on peut raisonnablement penser qu'ils doivent être supportés.

Qui est expert en win32, gtk, cocoa, opengl etc ?
Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?

Tu sembles avoir loupé la partie de la discussion dans laquelle je disais qu'il n'était pas question de faire une surcouche de l'existant (enfin, en ce qui concerne gtk et cocoa)...

Même en ce qui concerne openGL, ce sera quelque chose qui ne viendra que "plus tard" (lorsque le reste fonctionnera avec les primitives OS).

Ce qui serait bien plus intéressant, c'est de savoir qui maitrise suffisemment Xorg ou GD+

Et encore, avant d'en arriver au codage, il semble important:

• d'écrire les spécifications fonctionnelles
• d'écrire les spécifications techniques
• d'effectuer la conception de base

Or, nous n'en sommes même pas encore tout à fait la (nous sommes encore au stade où l'on réfléchit à ce qui devra se trouver dans les spécifications [EDIT]voir même de savoir, simplement, s'il vaut la peine de commencer à écrire les spécifications...[/EDIT])

[Invité]

ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)

En terme de look, oui, mais en terme de logique applicative, surement pas... En gros, ce qui fait la qualité d'une appli desktop (on a le moteur de calcul sous la main, on peut faire plein de petits calculs vite fait), est complètement différent de ce qui fait l'intéret d'une appli web (données décentralisées et uniques, sécurité des accès, mais contrainte sur la bande passante des échanges).

Pour une appli un tant soi peu compliquée (en termes de volumes de calculs ou de données), une même appli web et desktop, c'est la garantie d'un truc inefficace dans les deux domaines. (C'est un peu ce qui condamne AIR, chez Adobe)

A mon avis, un framework d'IHM est ici un framework desktop. On peut lui donner un "look web", mais c'est tout ce qu'il aura de web.

Francois

[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)

[Invité]

Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?

L'API Win32 fonctionne encore sous 7 (heureusement!), il y a des trucs en plus, comme dans toute nouvelle version. Globalement, j'aurais tendance à dire qu'il faut partir de 2 ou 3 systèmes cibles (pas plus), windows, forcément (ca je connais un peu, toi aussi manifestement), linux sans doute (je ne sais pas mais je pense qu'on peut trouver quelqu'un).

Maintenant, il n'y a pas besoin d'être un expert, juste de bien connaitre. Le but, c'est d'en savoir suffisamment sur les principes de fonctionnement pour éviter de prendre des décisions qui rendraient l'implémentation trop difficile dans tel ou tel système.

Francois

[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]

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