Qu'attendriez vous d'une nouvelle bibliothèques IHM?
Participeriez vous à son développement?
Le 2010-04-02 02:39:40, par koala01, Expert éminent sénior
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 :
Merci d'avance
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 :
- Existe-t-il un framework d'IHM de ce style (adam et eve, peut être )
- Si la réponse à (1) est "non", y aurait-il un intérêt quelconque à proposer un tel framework
- Quels seraient difficultés majeures rencontrées lors de la mise au point d'un tel projet
- 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
- Certains d'entre vous seraient-ils intéressés par le fait de collaborer à un tel projet s'il était lancé
- Toutes les questions qui pourront s'imposer en cours de discussion
Merci d'avance
-
bruno_pagesModérateurBonjour,
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 peunon ?
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 ...le 02/04/2010 à 9:26 -
koala01Expert éminent séniorCe 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.
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éele 02/04/2010 à 10:03 -
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)
Francoisle 02/04/2010 à 11:46 -
yanRédacteurTu voudrais faire un truc comme ultimate++?
mais avec plus de fonctionnalité(comme les metadata) et basé exclusivement sur la S(T)L et boost?le 02/04/2010 à 12:02 -
koala01Expert éminent séniorComme 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.
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
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 RADle 02/04/2010 à 12:20 -
koala01Expert éminent séniorComme 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?le 02/04/2010 à 12:27 -
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...
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.
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.
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...
Francoisle 02/04/2010 à 13:08 -
koala01Expert éminent séniorLà dessus, nous sommes d'accord...
Je voulais attirer ton attention que sur le fait que, tôt ou tard, il faudra
- prévoir la possibilité d'afficher des images (quel qu'en soit le format) et d'agir sur celles-ci
- prévoir la possibilité d'afficher des animations (svg, openGL ou autre) et d'agir sur celles-ci
- prévoir la possibilité d'intégrer un (SG)BDR et de collaborer avec
- prévoir la gestion correcte de certains formats et protocoles normalisés
- ...
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...
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.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.
[EDIT]Et je crains que la gestion des threads, par exemple, ne soit vraiment rendue beaucoup plus complexe si on décide de se passer de boost thread ou des possibilités futures de C++11, ne serait-ce parce qu'il n'y a pas grand chose de compatible en dehors (même pthread est un projet plus ou moins zombie qui n'apporte pas forcément le support complet de l'ensemble des possibilités des threads *nix) ...
Par contre, si, pour assurer une certaine compatibilité avec les compilateurs les plus anciens, il s'agit de passer par une compilation conditionnelle, basée, par exemple, sur les numéros de versions, cela peut rester envisageable
[/EDIT]
Il faut juste regarder ce qu'est le "coeur", et ce dont il a besoin.
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
Mais je ne voudrais pas non plus que l'aspect RAD soit obligatoire, de manière à permettre à ceux qui restent "désespérément collés" à vim ou à emacs d'utiliser la bibliothèque comme bon leur semble.
Le RAD pourrait parfaitement utiliser une technologie donnée pour la génération des projets, mais il ne devrait, à l'extrême limite, pas être "plus compliqué" de décider d'utiliser les auto tools, make, bjam ou CMake, aussi bien pour générer la bibliothèque que... pour générer le projet.
Quand tu y regarde, la première chose qui est compilée pour Qt, c'est... qmake, et il est, oserais-je le dire, le "passage obligé" pour n'importe quel projet utilisant Qt.
Il va de soi que le fait de fournir un moyen "standard" de générer la bibliothèque et/ ou le RAD au départ des sources apportera une facilité certaine à tous, mais ce moyen ne devrait pas être considéré comme incontournable à l'utilisation (même si on peut envisager qu'il soit également utilisé "en interne" par le RAD).
Je ne sais pas trop si je me fais bien comprendre, alors, n'hésite pas à revenir là dessusle 02/04/2010 à 13:43 -
Oui, mais avec la STL, on s'appuie sur des choses déjà anciennes et stables. C'est à mon avis ce qui fait problème avec boost et les standards récents... Ils peuvent bouger, pour de bonnes raisons, mais ça demeure un risque.
Les threads sont un bon exemple... Un framework d'IHM doit être threasafe, et utiliser des threads pour certains de ses calculs, peut être, mais il n'a pas à fournir à l'utilisateur des outils de threading.
Comme de toutes façons, une telle librairie contiendra une certaine dose de code bas niveau, on peut se demander dans quelle mesure l'utilisation d'une solution toute faite, pour l'usage interne de la librairie, qui introduirait des contraintes de portabilité, est une bonne idée.
Je ne dis pas qu'il ne faut pas le faire, mais je me méfierais...
On est d'accord là dessus.
Francoisle 02/04/2010 à 15:11 -
koala01Expert éminent séniorOui, mais d'un autre coté, il pourrait être dommage de refaire certaines choses qui sont malgré tout relativement stables, même si on assiste à un véritable défilé de versions, qui n'est provoqué que par le fait que... ces choses stables font partie d'une ensemble en évolution constante
Encore une fois, l'idéal serait de pouvoir gérer cela "plus finement"
Les threads sont un bon exemple... Un framework d'IHM doit être threasafe, et utiliser des threads pour certains de ses calculs, peut être, mais il n'a pas à fournir à l'utilisateur des outils de threading.
éviter de donner l'impression que la seule manière d'utiliser les thread soit... celle mis en oeuvre en interne
faire en sorte que les outils existants (boost thread ou les threads C++11, par exemple) ne soient pas plus compliqués à utiliser avec la bibliothèque que sans...
Comme de toutes façons, une telle librairie contiendra une certaine dose de code bas niveau, on peut se demander dans quelle mesure l'utilisation d'une solution toute faite, pour l'usage interne de la librairie, qui introduirait des contraintes de portabilité, est une bonne idée.
Je ne dis pas qu'il ne faut pas le faire, mais je me méfierais...le 02/04/2010 à 15:46