Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Qu'attendriez vous d'une nouvelle bibliothèques IHM?
Participeriez vous à son développement?

Le , par koala01

0PARTAGES

0  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de bruno_pages
Modérateur https://www.developpez.com
Le 02/04/2010 à 9:26
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 ...
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 02/04/2010 à 10:03
Citation Envoyé par bruno_pages Voir le message
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
0  0 
Avatar de
https://www.developpez.com
Le 02/04/2010 à 11:46
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
0  0 
Avatar de yan
Rédacteur https://www.developpez.com
Le 02/04/2010 à 12:02
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?
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 02/04/2010 à 12:20
Citation Envoyé par fcharton Voir le message
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
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 02/04/2010 à 12:27
Citation Envoyé par yan Voir le message
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.
0  0 
Avatar de
https://www.developpez.com
Le 02/04/2010 à 13:08
Citation Envoyé par koala01 Voir le message
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...

Citation Envoyé par koala01 Voir le message
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.

Citation Envoyé par koala01 Voir le message

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.

Citation Envoyé par koala01 Voir le message
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
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 02/04/2010 à 13:43
Citation Envoyé par fcharton Voir le message
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à 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
  • ...
Ces différents aspects sont, très certainement, accessibles au travers de bibliothèques tierces déjà existantes, mais leur utilité dans le cadre d'une IHM, et la facilité avec laquelle les gens seront capables de les interfacer l'IHM sera sans doute déterminante au moment de faire son choix entre Qt, WxWidget ou... ce nouveau projet potentiel.

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...
Là dessus, on est bien d'accord aussi

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.
Tous comme les exemples que je viens de citer me semblent relativement légitimes également, même si cela peut ne pas faire partie de la "première salve" des possibilités

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.
Effectivement

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.
Je crains que la possibilité d'utiliser std::vector (ou tout autre type de collection), std:: (w) string, les locales et plein de "petites choses" qui nécessitent une gestion correcte des template impliquera, presque de facto, le fait de limiter la compatibilité des compilateur à ceux... post normalisation

[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.
Là dessus, par contre, on est d'accord

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
Je suis on ne peut plus d'accord avec toi... Et je dois avouer que j'apprécie énormément l'aspect RAD dans certaines circonstances

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à dessus
0  0 
Avatar de
https://www.developpez.com
Le 02/04/2010 à 15:11
Citation Envoyé par koala01 Voir le message

Je crains que la possibilité d'utiliser std::vector (ou tout autre type de collection), std:: (w) string, les locales et plein de "petites choses" qui nécessitent une gestion correcte des template impliquera, presque de facto, le fait de limiter la compatibilité des compilateur à ceux... post normalisation
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.

Citation Envoyé par koala01 Voir le message

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

Citation Envoyé par koala01 Voir le message

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).
On est d'accord là dessus.

Francois
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 02/04/2010 à 15:46
Citation Envoyé par fcharton Voir le message
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.
Oui, 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.
Peut être pas fournir des outils de threading, du moins, pas dans un premier temps, mais, à défaut:
é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...
Oui, mais, encore une fois, il serait peut être dommage de partir sur du très bas niveau si, "sous réserve d'une version suffisamment récente" (qu'il faudrait, il est vrai, veiller à ne pas rendre obligatoire), il y a moyen de s'éviter tout ce travail supplémentaire, ou du moins de rendre ce travail supplémentaire "non indispensable"
0  0