Envoyé par
fcharton
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 |
non ?