Discussion :

[Lavock]

Bonjour tous !
Koala, ton poste est suffisamment intéressant pour que je grille la batterie de mon téléphone portable, à essayer d'y répondre depuis mon train de nuit >< !

Bon, globalement, j'aime pas trop comment nécessite de penser les framework actuel...

En règle général, soit on se retrouve à faire une classe pour chaque spécificité, ou alors a accumulé des saletés sémantiques/syntaxiques. Ou alors, lier de simple élément entre eux devient un vrai casse tête...

Sérieusement, un framework qui ne soit pas un pseudo-langage, déjà, ça serait bien >< !

J'aimerai participer activement a un tel projet, malheureusement, je fais déjà pas mal de truc, en plus, c'est pas franchement dans mon domaine de compétence -_-'.

[koala01]

Bonjour tous !
Koala, ton poste est suffisamment intéressant pour que je grille la batterie de mon téléphone portable, à essayer d'y répondre depuis mon train de nuit >< !

Crois tu que ca en vaille la peine on n'est pas à la piece non plus (d'ailleurs, je serai absent une bonne partie de la jourée )

Bon, globalement, j'aime pas trop comment nécessite de penser les framework actuel...

J'aimerai participer activement a un tel projet, malheureusement, je fais déjà pas mal de truc, en plus, c'est pas franchement dans mon domaine de compétence -_-'.

Je crois que, vu l'ampleur, c'est un projet qui demandera des compétences nombreuses et variées... Et surtout de bonnes idées.

Chacun pourrait donc apporter sa pierre à l'édifice, ne serait-ce que dans un domaine particulier ou en permettant d'ouvrir de nouveaux horizons grâce à son avis.

De plus, il semble parfaitement clair que, à moins d'engager une équipe rien que pour cela (ce pour quoi je n'ai pas les moyens actuellement ), il faudra bien envisager de mettre le framework au point de manière plus ou moins bénévole.

Il va donc de soi que, si je décide de lancer le projet, il le sera sous une licence open source, encore à déterminer

Je ne pourrai moi-même pas y consacrer des journées entières d'affilée

Mais, si tout le monde s'y met selon ses possibilités temporelles (une ou deux heures de temps en temps, ca peut aider énormément ) et ses capacités, je crois que nous pourrions déjà avoir un noyau assez rapidement

Et comme, pour l'instant nous n'avons même pas encore les spécifications réelles et aucun choix n'a encore été fait, il n'est même pas encore certain que je décide de le lancer réellement (même s'il faut avouer que le soutien dont tout le monde fait preuve ici serait de nature à m'inciter à le faire )

Je ferai un petit résumé des différents points abordés en rentrant ce soir, et on verra où l'on en est

N'hésitez pas à continuer à répondre, je lirai tout en rentrant

[Klaim]

Bonjour, je me permet d'ajouter mon avis de noob ^^;


D'abord, en lisant plusieurs discutions sur ces forums moi aussi (et plusieurs autres visiblement) je me disais que c'était dommage qu'on profite pas des tonnes de réflexions sur les retours d'utilisation des framework d'UI courants pour faire quelque chose de plus simple et plus efficace.

Surtout, moi ce qui m'interesserait serait une bibliothèque qui s'intègre bien avec la STL et boost parceque Qt a beau bien marcher avec les conteneurs de la STL, le fait d'avoir des équivalents chez Qt a tendance a faire douter.

Donc, une bibliothèque d'UI qui aurait pour but de se placer entre STL et Boost coté fonctionalités, ne nécessitant rien d'autre et ne remplaçant rien de ce qui existe (notamment les conteneurs, les string) serait interessant.

Il y a un point en particulier qui m'interesserait fortement : il faudrait que la bibliothèque en question soit séparée en deux.

A) Une bibliothèque qui permet de créer/manipuler une interface graphique mais qui ne la rends pas directement, qui fait appel à...
B) ..une bibliothèque qui implémente le "rendu", la gestion de l'aspect final perçu.

La bibliothèque fournirait un B) qui gérerait l'aspect tel que fourni par l'OS. En gros comme n'importe quelle bibliothèque d'interface.

La raison derrière cette séparation serait de permettre à l'utilisateur (ou a d'autres développeurs de libs graphique) d'implémenter leur propre gestion de l'aspect.
Cela permettrait par exemple aux bibliothèques de rendu 3D d'apporter leur propre "plugin" pour exploiter l'api de A) mais en ayant le rendu, l'aspect final dans leur moteurs.
Cela permettrait aussi de choisir l'aspect final de l'application sans être limité à une système de skins (dont les limites sont justement de ne pas permettre d'être rendu autre part qu'au niveau de l'API de l'OS).

Je ne sais pas si je suis clair dans ma description, mais je pense que ça serait vraiment utile de permettre aux développeurs d'implémenter la partie rendu si ils le souhaitent.
Je pense surtout au domaine du jeu vidéo où il y a des tas de solutions d'UI relatives a différents moteurs de rendu 3D... Avoir une seule interface(code) pour décrire l'UI de base (pas forcément le HUD, je parle bien du cas ou il y a besoin de boutons, de fenetres etc) et pouvoir éventuellement changer de moteur sans trop de dégats niveau code d'UI serait un gros bonus.

Voilà. Sinon j'ai beaucoup (trop!) de projets en cours pour participer au moins au début d'une telle bibliothèque (et puis niveau compétence je doute...) mais c'est avec plaisir que j'utiliserai une telle bibliothèque et tenterai d'apporter des patchs ou autre pour être utile.

edit> Je pense aussi que partir directement sur C++0x serait à la fois plus sain et plus "vendeur".

[Invité]

Donc, une bibliothèque d'UI qui aurait pour but de se placer entre STL et Boost coté fonctionalités, ne nécessitant rien d'autre et ne remplaçant rien de ce qui existe (notamment les conteneurs, les string) serait interessant.

C'est un des points sur lesquels les frameworks actuels pêchent... En fait, chaque widget d'interface contient ses données (il y a des exceptions, mais elle sont... exceptionnelles): les labels contiennent leur texte, les listview leurs lists, les datagrids leurs tableaux.

L'idée, ici, serait que le widget se contente de pointer sur un conteneur, qui lui fournit les données : on a dans la STL le concept d'itérateur, qui correspond assez bien à cette idée... Et le charme de la chose, c'est que ce conteneur peut être implémenté de différentes façons... Un listbox peut utiliser des données dans une list, un vector, une map: tant qu'on lui donne un iterateur, le widget s'en moque.

Ceci peut être généralisé : par exemple, aujourd'hui, les bibliothèques de widget distinguent généralement entre "widget données brutes", et "widgets base de donnée": ce sont les mêmes éléments d'interface, mais leur mode d'accès au données change.

A) Une bibliothèque qui permet de créer/manipuler une interface graphique mais qui ne la rends pas directement, qui fait appel à...
B) ..une bibliothèque qui implémente le "rendu", la gestion de l'aspect final perçu.

Effectivement, et comme on se propose également (c'est ce que j'ai compris de la discussion sur les SuperObjets) de sortir la gestion des messages des widgets, on se retrouve avec des "widgets maigres", qui délèguent

- à des conteneurs leurs demandes de données
- à une "machine à message" leurs évènements
- à un moteur de rendu leur dessin

Les widgets, dans une telle configuration, sont en fait des listes de "règles", qui associent des messages, des données et des actions de rendu.

Un truc marrant avec le moteur de rendu, c'est que pas mal de widgets "classiques" deviennent alors identiques : un radiogroup, un combobox, une listbox, ce sont trois rendus différents d'un même widget. En la poussant suffisament, une telle idée permettrait peut être de sortir des catalogues de widgets que sont devenues certaines librairies (où on a 500 composants d'interface, tous presque pareils)

Pour le moteur de rendu, ca rejoint un autre aspect d'un framework d'IHM: la notion d'application. Quelque part, il faut que le framework permette de produire une application complète et donc gère pour l'utilisateur le winmain et la boucle de messages de base (ou l'équivalent dans d'autres systèmes), mais il faut également pouvoir "débrayer" cette partie, pour pouvoir intégrer un élément du framework dans un autre système.

Un autre avantage que j'y vois, c'est que cela pourrait permettre à ce framework d'être utilisé dans d'autres frameworks, pour des modules "indépendants du reste".

Cela peut aider à sa diffusion : aujourdh'ui, changer de framework c'est du tout ou rien...

edit> Je pense aussi que partir directement sur C++0x serait à la fois plus sain et plus "vendeur".

Vendeur pour qui? A mon avis, c'est vendeur lors de la constitution d'une équipe projet (tout le monde aime bosser sur des trucs d'avant garde), pour le client final, je crois qu'il s'en moque un peu.

Francois

[yan]

Pas tant que cela... L'idée, c'est juste de les emballer dans des primitives du framework. De toutes façons, si tu veux offrir à l'utilisateur "avancé" une possibilité de customiser les éléments d'interface, tu vas bien être obligé d'exposer des primitives de dessin, qui correspondent à ces "emballages GDI+". Et une fois les emballages faits, tout se passe en "langage framework".

Les primitives de dessin, ce n'est pas terriiblement compliqué (et en fait, ca se ressemble d'un OS à l'autre).

Si on part du principe que c'est juste du dessin, pourquoi ne pas directement utiliser une api/moteur un moteur 2D (voir 3D)?
C'est à dire de l'opengl, openvg, antigrain, ...

La lib serait de base bien plus multi-plateforme pour l'affichage. Le top c'est ce qu'as proposé Klaim. Pouvoir developper sont propre backend (ps :Qt fait déjà quelque chose comme cela :p)

Vendeur pour qui? A mon avis, c'est vendeur lors de la constitution d'une équipe projet (tout le monde aime bosser sur des trucs d'avant garde), pour le client final, je crois qu'il s'en moque un peu.

C'est qui permet d'avoir des volontaire. De plus, vue la quantité de choses proposées dans la nouvelle norme, ca faut carrément le coup de commencer par la. Par exemple, c++0x propose du thread et de meilleur string qui supporte l'unicode.


Y as autre choses qui faut prendre en compte :

• coder une ihm c'est trés chiant. Faut l'avouer c'est que du copie de copie de code. C'est lourd et pas intéressant.Contrairement à sa conception. Y as moyen de partir sur un api plus attirante. C'est ce que je vais essayer de faire avec la lib pour Qt.
• La mentalité à beaucoup évolué et la notion de widget est à l'agonie. Quitte à partir sur une nouvelle lib, autant partir sur les nouvelles philosophie. Les ihm, deviennent tactile et animé. Les composante ne sont plus de simple rectangle. Suffit de regarder wpf ou Qt quick pour voir que la notion d'ihm prend un nouveau cap. http://www.developpez.net/forums/d81...eclarative-ui/
• les application deviennent hybrid. Et exploite le web de différente manière.

je vous conseil de regarder(même rapidement) cette vidéo :
http://blip.tv/file/2561463/

c'est trés révélateur. l'architecture widget meure
C'est qui n'est pas pour me déplaire
Avec ces nouvelles philosophie, je pense qu'il y as moyen de faire quelque chose de vraiment intéressant.

[Invité]

Si on part du principe que c'est juste du dessin, pourquoi ne pas directement utiliser une api/moteur un moteur 2D (voir 3D)?
C'est à dire de l'opengl, openvg, antigrain, ...

Parce que dans ce cas tu déplaces le problème... Au lieu d'encapsuler des fonctions OS qui font des trucs assez proches de ce dont tu as besoin (des rectangles, des lignes, des fontes, des ellipses...), et qui le font vite et à bas niveau (donc en mangeant peu de ressources), tu dois écrire le code qui transforme ton IHM en primitives de la lib que tu utilises...

On peut faire de l'openGL, c'est sûr, mais quel est l'intérêt? Dans 99% des cas, on réutilise dans les IHM des composants existants (en les modifiant légèrement), parce que cela permet à l'utilisateur de retrouver ses marques (c'est ce qui fait, le plus souvent, l'impression d'ergonomie).

L'intérêt de rester près des primitives système, c'est le gain de vitesse et d'empreinte mémoire. Sachant qu'on peut faire pas mal de dessin sans quitter les primitives systèmes (je ne sais pas si tu as déjà programmé en GDI+, c'est réellement puissant)

Maintenant, rien n'empêche non plus de fournir un "portage OpenGL" des primitives de base, cela reviendrait à dire que tel ou tel moteur de rendu est considéré par le framework comme un portage particulier...

C'est qui permet d'avoir des volontaire. De plus, vue la quantité de choses proposées dans la nouvelle norme, ca faut carrément le coup de commencer par la. Par exemple, c++0x propose du thread et de meilleur string qui supporte l'unicode.

Je ne sais pas, j'ai l'impression que les normes portent plus sur l'implémentation qu'autre chose...

Sur le moderne, mon problème, c'est qu'il y a souvent pas mal de casse, des trucs qu'on met dans le standard, et qu'on abandonne 5 ans après, ou des choses qu'on commence par utiliser de travers, avant que quelqu'un comprenne à quoi ca sert.

Ensuite, si on arrive correctement à découpler données et éléments d'interface, les string, on en a moins besoin, je crois: ils sont dans les conteneurs...

[*]coder une ihm c'est trés chiant. Faut l'avouer c'est que du copie de copie de code. C'est lourd et pas intéressant.Contrairement à sa conception. Y as moyen de partir sur un api plus attirante. C'est ce que je vais essayer de faire avec la lib pour Qt.

Ca doit dépendre des gens alors... Moi l'IHM, c'est un truc qui m'amuse, parce qu'on est en prise directe avec la réalité de l'utilisateur. Mais je connais plein de gens qui n'aiment pas ca...

La mentalité à beaucoup évolué et la notion de widget est à l'agonie. Quitte à partir sur une nouvelle lib, autant partir sur les nouvelles philosophie.

Mouais, suffit de voir les applis actuelles, y'a pas de boutons, pas de listes, pas de combobox...

Sérieusement, c'est pas parce que les composants d'interface ont des coins ronds que les widgets sont morts... Quant à l'écran tactile, il faudra un jour qu'on m'explique en quoi c'est une révolution par rapport à la souris... (ca se gère exactement pareil, non?)

Des interfaces dessinées, ce fait un bout de temps qu'on en voit (ne serait ce que dans les jeux). Mon impression c'est qu'elles sont invariablement lourdes, consommatrices en mémoire (l'exemple caricatural, c'est flex: sublime pour faire un datagrid de 23 éléments, inutilisable au delà...), et aboutissent souvent à des choses assez moches (sauf à embaucher une armée de graphistes)

Quant à la notion d'UI déclarative (qui ne me parait pas bien novatrice non plus, j'ai des souvenirs de lecture très anciens du Foley Van Dam, qui racontaient à peu près ca...), elle est orthogonale à l'idée de widgets.

J'ai regardé la vidéo, honnêtement, je trouve la description plus marketing qu'autre chose...

Francois

[yan]

Ca doit dépendre des gens alors... Moi l'IHM, c'est un truc qui m'amuse, parce qu'on est en prise directe avec la réalité de l'utilisateur. Mais je connais plein de gens qui n'aiment pas ca...

Il parait qu'il y en as même qui aime la validation...
Moi ca m'amusais au début. Maintenant c'est la conception. La developper, j'ai l'impression de faire toujours la même chose... Je fait une layout, je mmet un label, je mes une lineEdit,... Et je recommence. C'est très répétitive.
Dernièrement je me suis amusé à créé des classe qui créé des layout et les interface comme un stream. Je trouve assez simpa comme résultat :

Code :

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

1
2
3
4
5
6
7
8
9
 
FlowLayout<QVBoxLayout>(w) << Spacing(10)
                                          << QMarging(4,4,4,4)
                                          << widget
                                          << widget2
                                          << widget3
                                          << FlowLayout<QHBoxLayout>() << widget4
                                                                       << widget5
                                                                       << widget6;

Sérieusement, c'est pas parce que les composants d'interface ont des coins ronds que les widgets sont morts...

c'est les animation qui cela casse le principe.

Quant à l'écran tactile, il faudra un jour qu'on m'explique en quoi c'est une révolution par rapport à la souris... (ca se gère exactement pareil, non?)

C'est pas une révolution en soit même. C'est une nouvelle façon d'interagir qui est entré dans les moeurs. Le plus connue c'est le zoom à deux doigt.
C'est con mais c'est vers quoi on va. En particulier sur les mobile et netbook.

Quant à la notion d'UI déclarative (qui ne me parait pas bien novatrice non plus, j'ai des souvenirs de lecture très anciens du Foley Van Dam, qui racontaient à peu près ca...), elle est orthogonale à l'idée de widgets.

L'idée n'est pas nouvelle mais elle as de plus en plus tendance à remplacer celle de widget.

J'ai regardé la vidéo, honnêtement, je trouve la description plus marketing qu'autre chose...

Marketing oui mais loin de la réalité je ne pense pas.

Ce que je constate c'est que l'iphone et le web 2.0 ont donnés de nouvelle envie et habitude au utilisateur. Et que maintenant c'est ce que les client demande. Après comme tu le dit c'est orthogonale (quoi que l'on peut faire du widget avec du déclarative). Mais est il préférable de s'investir sur ce qui existe déjà et de refaire comme tous le monde fait(widget) ou vers ce que l'on aura surement dans le future et proposer quelque chose de plus innovant?

[Invité]

Il parait qu'il y en as même qui aime la validation...

Si par validation, tu entends le controle des données, oui ca j'aime bien aussi... Mon problème avec la conception "pure", c'est que c'est parfaitement gratuit: toutes les conceptions sont géniales, ou stupides, tant qu'elles ne se sont pas confrontées au réel, c'est à dire à l'implémentation et a l'utilisation.

Le côté répétitif, c'est vrai, mais le RAD aide, et puis, moi, j'ai besoin de quelque chose qui m'occupe les mains pendant que je réfléchis : aligner des composants, c'est une occupation comme une autre...

c'est les animation qui cela casse le principe.

Comment? Une animation, c'est juste un bout du rendu, non?

C'est pas une révolution en soit même. C'est une nouvelle façon d'interagir qui est entré dans les moeurs. Le plus connue c'est le zoom à deux doigt.
C'est con mais c'est vers quoi on va. En particulier sur les mobile et netbook.

Oui, mais en quoi est ce différent? On a toujours un dispositif de pointage, qui permet de selectionner un point (ou une zone) de l'écran, et de "cliquer"...

Ce que je constate c'est que l'iphone et le web 2.0 ont donnés de nouvelle envie et habitude au utilisateur. Et que maintenant c'est ce que les client demande.

Oui, mais je ne vois toujours pas en quoi cela tue le concept de widget... Ca va faire évoluer certains widgets auxquels nous sommes habitués, mais le principe même d'avoir sur l'écran des zones dessinées avec lesquels on interagit, ou qui réagissent aux actions de l'utilisateur, qui est le concept meme du widget, je ne comprends pas en quoi il est remis en cause...

Enfin, peut être est ce simplement qu'on ne met pas la même chose derrière le mot "widget"...

Francois

[bruno_pages]

Mon problème avec la conception "pure", c'est que c'est parfaitement gratuit: toutes les conceptions sont géniales, ou stupides, tant qu'elles ne se sont pas confrontées au réel, c'est à dire à l'implémentation et a l'utilisation.

+1

malheureusement cela échappe complètement à nos décideurs qui pensent que spécifier chez nous et demander envoyer la réalisation loin d'ici comem par exemple en Inde peut donner de bons résultats, ce malgré les innombrables exemples prouvant le contraire

Le plus connue c'est le zoom à deux doigt

Oui, mais en quoi est ce différent? On a toujours un dispositif de pointage, qui permet de selectionner un point (ou une zone) de l'écran, et de "cliquer"...

et non justement, en dehors du coté ludique et aisément compréhensible , ca c'est vraiment novateur, d'ailleurs il suffit de voir que cela ne colle pas avec un slot du style contentsMouseMoveEvent(QMouseEvent * e) car là il y a deux déplacements

[yan]

Enfin, peut être est ce simplement qu'on ne met pas la même chose derrière le mot "widget"...

Ce que j'entend par widget c'est

• la notion d'arbre parent/enfant.
• Une widget est composé de widget qui sont eux même composé de widget
• Un widget est supposé rectangulaire. Ce qui est utilisé par les Layout pour le positionnement
• ....

Ce système est utilisé pour optimiser le rendu. Un widget enfant ne se dessine que dans la zone du widget parent. L'ihm est structuré de manière assez statique.

Or si tu veut ajouter de l'animation. Ta widget devra sortir de la widget parent. Pouvoir se redimensionner (bouton qui clignote par exemple) sans spécialement correspondre à modifier la place qu'il occupe.
En quoi un bouton rond doit prendre une place rectangle?

on arrive de plus en plus vers une notion de composantes qui sont positionnées au travers de règles. Par exemple les ancre dans le html, les div,...le coin haut de composante est collé à l'autre composante,...

C'est ce que fait Qt avec sont QGraphic* et Qt Quick. Il casse la structure widget.

C'est une autre façon de penser.

De plus, la séparation entre le traitement et l'ihm commence à être de plus en plus grande. Le but est de faire faire l'ihm pas des designer et le fonctionnel par des développeur.
Suffit de voir microsoft expression. C'est vraiment impressionnant.

Peut être que je me trompe, mais c'est mon ressentie.

[Invité]

et non justement, en dehors du coté ludique et aisément compréhensible , ca c'est vraiment novateur, d'ailleurs il suffit de voir que cela ne colle pas avec un slot du style contentsMouseMoveEvent(QMouseEvent * e) car là il y a deux déplacements

Tu sais, je crois qu'on a aussi dit cela le jour ou quelqu'un a sorti une souris à trois boutons...

Cela demande une adaptation du QMouse, et de tout ce qui va avec, c'est certain, mais il n'y a pas de révolution...

Des dispositifs de saisie/pointage, depuis 20 ans, on en a vu un paquet, ce n'est pas cela qui remet en cause le modèle d'UI par widget...

Ce qui pourrait le faire, c'est si on abandonnait complètement les outils de pointage, car à ce moment, la notion même de "composant actif", qui est à la base du widget : quand on interagit, on le fait avec "un composant", et pas "tout l'écran" risquerait de disparaitre... Mais ce que je vois des applis IPhone ne me parait pas l'indiquer...

Francois

[Florian Goo]

Bonjour à tous,

À partir de la moitié du sujet, je me suis mis à lire en diagonal, donc désolé si je fais doublon.

J'aime beaucoup l'idée de Yan consistant à faire une surcouche d'une lib existante.
Comme Jean-Marc l'a dit, une modeste mesure des ambitions peut contribuer à la réussite d'un projet.
Puisque tu as l'air d'être plus préoccupé par l'API que par le design interne, pourquoi ne pas te placer au même niveau que wxWidgets et te contenter (au moins dans un premier temps) d'écrire un wrapper pour une lib existante (mettons GTK+, une API C me paraissant plus « malléable » et donc bonne cliente pour cette exercice) qui présenterait l'API de tes rêves ?
Cela te permettrait de ne pas te préoccuper du bas niveau pour te concentrer sur ce qui t'intéresse réellement.

Ensuite, si tu le souhaites, tu pourras remplacer GTK+ par un back-end de ta conception. Ou bien, tu pourras écrire d'autres « drivers » pour les autres bibliothèques d'IHM (et donc rester au niveau « wrapping »).

[Invité]

Ce système est utilisé pour optimiser le rendu. Un widget enfant ne se dessine que dans la zone du widget parent. L'ihm est structuré de manière assez statique.

Ca sert au rendu, mais surtout à l'interaction... A un instant donné, tu as un widget actif, avec lequel tu interagis, via la souris ou la clavier... Tu cliques sur "un bouton", tu déroules "un menu", tu écris dans "un champ d'une grille"...

Le fait de "clipper" le dessin par rapport au parent, c'est plus une convention qu'autre chose. Et ce n'est pas systématique (regarde les listes des combobox).

En fait, il y a généralement plusieurs arbres... Un qui décrit qui possède quoi (en terme de gestion mémoire, notion d'Owner si Qt a gardé le jargon Borland); un autre qui dit comment ca s'organise en terme de visibilité (Parent), et qui sert souvent au dessin... mais on en a un troisième qu'on ne voit pas, qui est celui du moteur de rendu (via le zOrder des fenêtres, chez Windows).

En jouant sur ces trois tableaux, rien n'empêche de dessiner un Widget en dehors de son parent, ou de modifier les parentés en dynamique. C'est par exemple le principe des composants dockables, que les systèmes de widget gèrent très bien.

En quoi un bouton rond doit prendre une place rectangle?

Pour le rendu, il n'en a pas besoin, et d'ailleurs les OS gèrent la transparence pour cela... Pour le pointage, on peut parfaitement permettre des "transmissions" d'évènements d'un widget "en surface" vers des widgets plus profonds (là encore les OS le permettent). Il se trouve que ce n'est pas toujours implémenté dans les frameworks usuels, mais ce n'est pas la faute aux widgets...

Ceci dit, il y a aussi l'utilisateur, qui considère qu'une appli n'est pas un jeu d'adresse, et que s'il clique assez près du bouton, il faut que "ca compte".

Ensuite, il faut se méfier de cette idée que "tout peut avoir la forme qu'on veut". Dès qu'on quitte les rectangles, les notions d'alignement deviennent atrocement compliquées... Et de jolis composants mal alignés, ca tue un peu...

on arrive de plus en plus vers une notion de composantes qui sont positionnées au travers de règles. Par exemple les ancre dans le html, les div,...le coin haut de composante est collé à l'autre composante,...

Oui, je fais ca sous borland depuis des années. Je crois que c'est plus un truc qui était mal géré dans les frameworks qu'une limitation inhérente aux widgets.

De plus, la séparation entre le traitement et l'ihm commence à être de plus en plus grande. Le but est de faire faire l'ihm pas des designer et le fonctionnel par des développeur.

Ca, ca varie au fil du temps... J'ai connu une époque où l'on séparait le moteur de l'interface, puis une autre (celle du RAD) où on les a rapprochés, on en revient maintenant...

Personnellement, et pour avoir essayé les deux, sur une longue période, je me méfie de plus en plus de cette séparation, qui nous vient de l'architecture document vue de nos amis de MS, puis de l'obsession des MVC qu'on rencontre aujourd'hui. Je m'en méfie, parce que j'observe que bien souvent, la séparation entre données et vues, c'est presque aussi arbitraire et inefficace que la séparation données-traitements...

Je me rends compte que si je critique ta définition des widgets, je ne te donne pas la mienne... la voila.

Pour moi, les widgets sont des "briques de base", toujours les mêmes, qui entrent dans la composition d'une IHM. On va avoir des grilles, des boutons, des panneaux, des listes, des combobox, etc... L'interface d'une application se définit pas un découpage, généralement arborescent, en widgets.

Les widgets servent à la fois à l'affichage et à l'interaction, et tout le fonctionnement de l'application peut se décrire comme une série de messages échangés par ses widgets.

L'idée de base, derrière les widgets, c'est cette notion que toute application peut être décomposée en un petit nombre de briques de bases...

Ce n'est pas toujours le cas: par exemple, pour certains jeux vidéos (les shoot'em up, par exemple), mais ca s'applique à pas mal d'applis...

Francois

[yan]

Oui, je fais ca sous borland depuis des années. Je crois que c'est plus un truc qui était mal géré dans les frameworks qu'une limitation inhérente aux widgets.

C'est pas que ce n'est pas faisable mais que c'est pas forcement prévue pour.
L'architecture widget se base sur une arborescence de widget. Ce qui la rend assez "statique". En particulier dans l'esprit du développeur. Si tu commence à vouloir rendre l'ihm "dynamique "(animation,..),Y as toujours des moyen de faire avec, mais souvent il faut connaitre comment fonctionne en interne le rendu de la lib, faire des pseudo hack pas propre. Et ce n'est pas forcement toujours pareil pour chaque lib. Pour un développeur lambda, il as pas forcement envie ou possible d'aller jusque là.

Si de base tu propose une API qui casse cette vision, tu supprime les bornes apportées par l'architecture widget dans l'esprit du développeur.
C'est un peu comme lui donner plus de liberté et de lui permet de concevoir son ihm comme .... un "jeux vidéo".

Dernièrement je réfléchissais si l'on pouvais pas exploiter un moteur physique (2D box) pour faire de ihm
Par exemple pour positionner les éléments. Ou des animations.
Mais j'ai encore aucune idée si c'est intéressant et si ça peut ajouter quelque chose à l'expérience utilisateur...

Y aura toujours la notion "je me positionne par rapport à quelqu'un" et donc parent/enfant, mais de son point de vue, le composant (concrètement une widget actuelle ) peut aller n'importe ou dans la scène.

[Invité]

En y repensant, je me dis que finalement, le modèle d'interface par widgets se justifie davantage par l'interaction de l'utilisateur que par l'affichage. C'est peut être là que se trouve la frontière en fait...

Si on a beaucoup a dessiner, mais par grand chose à saisir, avec des interactions de type jeu video (la souris et les flèches pour se déplacer, le clic et qq raccourci clavier pour agir, tirer, et des commandes qui se limitent généralement à une palette d'icones...), alors les widgets servent peu, et une interface dessinée ira bien.

Si on a au contraire pas mal de saisie/interaction, et des choses à montrer qui consistent surtout en du texte dans des cases, alors, le widget marche mieux, parce qu'il décrit l'interface dans un langage proche de ce que l'on doit afficher. En gros, on gagne du temps en exploitant la mécanique "standard" des widgets (les listes et les menus qui se déroulent, les boutons qui s'enfoncent)

Francois

[yan]

Si on a beaucoup a dessiner, mais par grand chose à saisir, avec des interactions de type jeu video (la souris et les flèches pour se déplacer, le clic et qq raccourci clavier pour agir, tirer, et des commandes qui se limitent généralement à une palette d'icones...), alors les widgets servent peu, et une interface dessinée ira bien.

Si on a au contraire pas mal de saisie/interaction, et des choses à montrer qui consistent surtout en du texte dans des cases, alors, le widget marche mieux, parce qu'il décrit l'interface dans un langage proche de ce que l'on doit afficher. En gros, on gagne du temps en exploitant la mécanique "standard" des widgets (les listes et les menus qui se déroulent, les boutons qui s'enfoncent)

Trés bonne remarque. J'y avais pas trop réfléchie mais ca me semble une bonne analyse.
Et regardant les vidéo de cette discutions
http://www.developpez.net/forums/d81...eclarative-ui/
c'est très proche de ta remarque.
C'est n'est plus vraiment les même IHM.

[koala01]

Me voila enfin rentré...

Bonjour, je me permet d'ajouter mon avis de noob ^^;

Ce sont peut être les avis les plus intéressants, car ils permettent de pointer du doigt les problèmes auxquels ceux "qui débarquent" sont confrontés

Surtout, moi ce qui m'interesserait serait une bibliothèque qui s'intègre bien avec la STL et boost parceque Qt a beau bien marcher avec les conteneurs de la STL, le fait d'avoir des équivalents chez Qt a tendance a faire douter.

Donc, une bibliothèque d'UI qui aurait pour but de se placer entre STL et Boost coté fonctionalités, ne nécessitant rien d'autre et ne remplaçant rien de ce qui existe (notamment les conteneurs, les string) serait interessant.

C'est, effectivement, l'idée de base

Il y a un point en particulier qui m'interesserait fortement : il faudrait que la bibliothèque en question soit séparée en deux.

A) Une bibliothèque qui permet de créer/manipuler une interface graphique mais qui ne la rends pas directement, qui fait appel à...
B) ..une bibliothèque qui implémente le "rendu", la gestion de l'aspect final perçu.

La bibliothèque fournirait un B) qui gérerait l'aspect tel que fourni par l'OS. En gros comme n'importe quelle bibliothèque d'interface.

La raison derrière cette séparation serait de permettre à l'utilisateur (ou a d'autres développeurs de libs graphique) d'implémenter leur propre gestion de l'aspect.
Cela permettrait par exemple aux bibliothèques de rendu 3D d'apporter leur propre "plugin" pour exploiter l'api de A) mais en ayant le rendu, l'aspect final dans leur moteurs.
Cela permettrait aussi de choisir l'aspect final de l'application sans être limité à une système de skins (dont les limites sont justement de ne pas permettre d'être rendu autre part qu'au niveau de l'API de l'OS).

Je ne sais pas si je suis clair dans ma description, mais je pense que ça serait vraiment utile de permettre aux développeurs d'implémenter la partie rendu si ils le souhaitent.
Je pense surtout au domaine du jeu vidéo où il y a des tas de solutions d'UI relatives a différents moteurs de rendu 3D... Avoir une seule interface(code) pour décrire l'UI de base (pas forcément le HUD, je parle bien du cas ou il y a besoin de boutons, de fenetres etc) et pouvoir éventuellement changer de moteur sans trop de dégats niveau code d'UI serait un gros bonus.

Voilà une idée qu'elle est bonne

Voilà. Sinon j'ai beaucoup (trop!) de projets en cours pour participer au moins au début d'une telle bibliothèque

Que crois tu faire actuellement, même si c'est sans en avoir l'air

(et puis niveau compétence je doute...)

Que cela ne t'empêche pas d'intervenir... Un tel projet fera surement évoluer énormément les différents participants

mais c'est avec plaisir que j'utiliserai une telle bibliothèque et tenterai d'apporter des patchs ou autre pour être utile.

Toute participation aussi minime soit-elle sera la bienvenue

Et les corrections risquent d'être nombreuses... Ta participation pourrait donc très bien être plus importante que tu ne l'imagine

Bonjour à tous,

À partir de la moitié du sujet, je me suis mis à lire en diagonal, donc désolé si je fais doublon.

J'aime beaucoup l'idée de Yan consistant à faire une surcouche d'une lib existante.
Comme Jean-Marc l'a dit, une modeste mesure des ambitions peut contribuer à la réussite d'un projet.
Puisque tu as l'air d'être plus préoccupé par l'API que par le design interne, pourquoi ne pas te placer au même niveau que wxWidgets et te contenter (au moins dans un premier temps) d'écrire un wrapper pour une lib existante (mettons GTK+, une API C me paraissant plus « malléable » et donc bonne cliente pour cette exercice) qui présenterait l'API de tes rêves ?
Cela te permettrait de ne pas te préoccuper du bas niveau pour te concentrer sur ce qui t'intéresse réellement.

Dans mon esprit, il ne s'agit absolument pas de casser l'API, du moins, à la base, mais:

• De fournir une bilbiothèque IHM beaucoup plus proche de ce que fournissent le langage et (dans une certaine mesure, encore à déterminer) boost
• D'en finir "une bonne fois pour toutes" avec le super objet au profit d'une approche plus multi paradigme, afin de profiter de toute la puissance du langage
• De simplifier l'utilisation, par exemple, au niveau de la procédure de compilation (il y a là réellement de quoi faire, si on regarde Qt)

Certains aspects (dont le premier) sont, me semble-t-il incompatible avec la création d'une surcouche de l'existant.

Je suis d'accord sur le fait qu'il faut arriver à placer une limite aux ambitions pour le début, mais, dans un premier temps, nous pouvons malgré tout laisser libre cours à notre imagination, quitte à classer certaines idées dans la catégorie des "évolutions potentielles" au moment de lancer réellement le projet

Si on part du principe que c'est juste du dessin, pourquoi ne pas directement utiliser une api/moteur un moteur 2D (voir 3D)?
C'est à dire de l'opengl, openvg, antigrain, ...

Si on arrive, effectivement, à séparer clairement les différents aspects (la "déclaration" des éléments d'une part et le rendu d'autre part), il sera très certainement facile d'adapter le moteur de rendu pour l'utiliser en 3D ou autre...

Cependant, je rejoins François sur le fait qu'il me semble primordial de rester aussi près des primitives de l'OS que possible, quitte à proposer par la suite d'autres moteurs de rendus plus "haut niveau" et / ou plus gourmands en ressources.

L'aspect que tu propose mérite cependant clairement sa place dans la catégorie des "évolutions potentielles"

Par contre, chers Yan et François, pour intéressant que puisse être votre débat sur les widgets, il semble s'écarter un peu trop de l'objectif de cette discussion.

Il pourrait en ressortir de très bonnes idées, mais je vous conseillerais volontiers de le continuer dans une discussion parallèle, et de reporter ici les idées qui pourraient émerger.

Cela nous permettra à tous de mieux appréhender les différents aspects, sans risque de s'embrouiller

Merci d'avance

[yan]

Par contre, chers Yan et François, pour intéressant que puisse être votre débat sur les widgets, il semble s'écarter un peu trop de l'objectif de cette discussion.

Bien au contraire. Tu veut proposer quelque chose d'innovant, éviter les erreur/contrainte du passé. Proposer une nouvelle architecture plus adapté.
Faut commencer par comprendre ce qui existe et ce qui semble être le future. Ce qu'est une widget, ect ect
Et c'est exactement ce dont il s'agis.

[Invité]

Salut Koala,

Les widgets sont au coeur du débat, parce que ce sont (s'il y en a, bien sur) les briques de base de description de l'interface... Si tu as des widgets, ce seront probablement les types de base de la librairie. Si tu n'en as pas, il faut imaginer le concept unitaire qui les remplace...

Par ailleurs, la discussion avec Yan fait ressortir un point: il faut probablement imaginer plusieurs stratégies de rendu, qui vont de l'appel OS bas niveau, à l'appel de moteurs de rendu plus complexes, voire la traduction en un langage de rendu différent.

Quelque part, les widgets (ou leur contrepartie dans la future lib) sont comme la représentation intermédiaire d'un programme compilé, que le "compilateur" qu'est le moteur de rendu, traduit en du graphisme "machine", ou des instructions JIT...

Francois

[koala01]

Bien au contraire. Tu veut proposer quelque chose d'innovant, éviter les erreur/contrainte du passé. Proposer une nouvelle architecture plus adapté.
Faut commencer par comprendre ce qui existe et ce qui semble être le future. Ce qu'est une widget, ect ect
Et c'est exactement ce dont il s'agis.

Tu n'as pas tort, mais je *crains* que, pour l'instant, vous ne soyez occupé à essayer de vous convaincre l'un l'autre, sans essayer *réellement* de réfléchir à une alternative.

Si votre débat prend ce chemin, vous pourrez vous disputer pendant cent sept ans sans que rien de concret n'en ressorte

Mon intervention n'avait donc pas pour objectif d'empêcher votre débat, mais plutôt d'essayer de le recentrer de manière à vous inciter à trouver des alternatives, sans vous bloquer sur des détails aussi insignifiants que "écran tactile Vs souris"...

Il faudra, effectivement, prendre en compte le fait que l'écran tactile est très certainement appelé à se généraliser, mais, pour l'instant, je fais encore partie de ces pauvres bougres qui utilisent une souris avec molette... Et qui risque d'y rester accroché un temps certain