Discussion :

[koala01]

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

[bruno_pages]

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

[koala01]

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

[Invité]

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

[yan]

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?

[koala01]

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

[koala01]

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.

[Invité]

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

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.

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.

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

[koala01]

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

[Invité]

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.

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

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

[koala01]

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"

[Invité]

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"

Ca me parait assez sage.

Dans le cas de boost, il y a, mine de rien, pas mal de chose qui fonctionnent sans problème même sur des configurations anciennes. Ce qui est plus hasardeux, ce sont généralement ces bibliothèques qui justement sont encore en pleine évolution.

Pour ce qui est du bas niveau, ou plus précisément des appels systèmes, je doute qu'une telle librairie y échappe. Un framework d'IHM a justement pour fonction d'encapsuler l'interface avec l'OS dans une structure portable... Il y a sans doute des cas pour lesquels ce travail peut être délégué, mais un tel projet nécessite des gens qui connaissent très bien les OS cibles.

Ca reste un projet très ambitieux, qui s'adresse, idéalement, à des gens ayant déjà une expérience un peu longue de l'IHM "bas niveau". En terme de code, je ne crois pas que ce soit très gros, mais conceptuellement, ce n'est pas facile.

Francois

[koala01]

Ah, je n'ai jamais dit que ce n'était pas un projet ambitieux, ni que le premier clampin ayant lu deux (mauvais) tutos sur C++ serait capable de participer à sa mise en oeuvre... (ce qui ne doit absolument pas empêcher ce même clampin de l'utliser ).

Mais, si je venais effectivement à lancer un tel projet (en plus, il est envisageable de faire héberger des projets sur DVP), serais tu tenté par l'aventure

Et vous autres, là, qui avez lu la discussion sans intervenir... Qu'en pensez vous

Allez, que diable, exprimez vous...

Je suis convaincu que, si on décidait de lancer un tel projet, sa qualité serait proportionnelle à celle du débat que je vous propose ici, or, pour l'instant, si on fait exception des interventions de yan et de bruno, on croirait assister à un dialogue entre François et moi

Et pourtant, je suis persuadé que certains pourraient émettre des idées ou des jugements intéressants...

Jean marc 3D Yan Luc Laurent ... Tous les autres (qui m'excuseront de ne pas les citer nommément) Que demanderiez vous à une telle bibliothèque Quel "trait de génie" auriez vous pour la rendre conviviale Comment vous y prendriez vous pour ménager les différents aspects

Croyez vous seulement que ce soit réalisable / intéressant

[bruno_pages]

En terme de code, je ne crois pas que ce soit très gros

saperlipopette, gros c'est à partir de qu'elle taille ?

comment comptez-vous gérer le multi plateforme Linux et Windows coté graphique, vous voulez implémenter la chose ... avec QT ? (blague)

Jean marc 3D Yan Luc Laurent

ouf, je ne suis pas dans la liste, koala01 doit faire parti des gens qui pense que Bouml c'est moche

[koala01]

ouf, je ne suis pas dans la liste, koala01 doit faire parti des gens qui pense que Bouml c'est moche

Absolument pas... Au contraire: j'ai le plus grand respect pour ton outil que j'utilise régulièrement

Non, tu es dans la liste de "tous ceux que je ne cite pas nommément" (et puis, je t'avais déjà cité plus haut)

Mais, quand on y regarde, cette discussion a été lue, en moyenne, douze fois pour chaque réponse qui a été apportée (enfin, c'était la moyenne après écriture de ma réponse précédente )... Cela fait autant de personnes qui auraient pu intervenir et donner leur avis...

Au lieu de ca... Rien, Nada, Nothing... Ou peu s'en faut...

N'allez surtout pas croire (je m'adresse à ceux qui ont déjà répondu ) que je considère vos interventions comme négligeables, loin de là...

J'aurais simplement espérer obtenir une plus grosse brochette d'avis

[bruno_pages]

J'aurais simplement espérer obtenir une plus grosse brochette d'avis

cela va peut être venir, et puis la chose n'est pas mince il est normal que cela demande réflexion, en plus on est quand même vendredi avant 3 jours de WE

Perso je ne peut pas dire que je connais l'implémentation bas niveau d'IHM, même si j'ai participé à http://xcoral.free.fr (écrit en X pur), il y a bien bien longtemps de cela.

[koala01]

cela va peut être venir, et puis la chose n'est pas mince il est normal que cela demande réflexion, en plus on est quand même vendredi avant 3 jours de WE

Ne t'en fais pas, je fais un peu dans la provoc là

Je sais bien que certains se déchaineront (peut être) un peu plus tard

[Invité]

saperlipopette, gros c'est à partir de qu'elle taille ?

Difficile à dire précisément, mais je pense qu'on peut avoir un framework très complet en moins de 100 000 lignes de code C++ un peu dense (au jugé, je dirais 50 000). Ca devrait être un objectif du projet, d'ailleurs, le nombre de lignes...

Ce n'est pas un petit truc, bien sur, mais ca tient dans la tête d'un developpeur unique, pour donner une idée...

comment comptez-vous gérer le multi plateforme Linux et Windows coté graphique, vous voulez implémenter la chose ... avec QT ? (blague)

Non, le truc qui semble uniformément suivi, c'est d'encapsuler les appels systèmes dans un jeu de primitives de base. C'est rendu facile par le fait que la gestion du graphisme n'est pas profondément différente d'un OS à l'autre (grosso modo, les grands concepts sont les mêmes)

On se retrouve avec un fichier primitive par OS, qui traduit les appels de base en "langage framework", et après, tout est écrit en "framework pur". Idéalement, il faudrait avoir dans le système une méthode permettant de modifier ce qu'on confie au fichier primitive, et au framework, ce qui permettrait de mieux optimiser pour des systèmes exotiques.

Le problème n'est pas dans le portage. La vraie difficulté, c'est de concevoir le "langage framework".

@koala : je suis intéressé pour en causer (c'est déjà çà), au delà, je suis une vraie planche pourrie, moi, aucune suite dans les idées... mais je ne parlerais pas du sujet s'il ne m'intéressait pas.

Francois

[bruno_pages]

50000 me parait très optimiste, si regarde le vieux et à priori 'petit' Qt2.3 qui ne doit pas être loin du but à atteindre, les .cpp seuls font 310000 lignes (j'ai fais un wc -l, cela compte tout y compris lignes vides et commentaires, mais bien-sûr je ne compte pas les exemples donnés avec Qt)

[koala01]

@koala : je suis intéressé pour en causer (c'est déjà çà), au delà, je suis une vraie planche pourrie, moi, aucune suite dans les idées... mais je ne parlerais pas du sujet s'il ne m'intéressait pas.
Francois

Il ne faut pas te galvauder de la sorte...

Toute personne vaut, entre autres, par son expérience personnelle, et j'ai le sentiment que tu pourrais apporter un point de vue très enrichissant pour certaines choses...

Au pire, nous pourrions considérer que tes lacunes seront comblées par les points forts d'autres personnes, et que tu comblera sans doute fort bien les lacune de certaines d'entre elles (dont moi en premier )

50000 me parait très optimiste, si regarde le vieux et à priori 'petit' Qt2.3 qui ne doit pas être loin du but à atteindre, les .cpp seuls font 310000 lignes (j'ai fais un wc -l, cela compte tout y compris lignes vides et commentaires, mais bien-sûr je ne compte pas les exemples donnés avec Qt)

Je crois que le tout tient dans la position du curseur que l'on donne pour le terme "petit" (ou plutôt "pas trop grand") et pour les possibilités de base...

Plus nous donnerons de possibilités de base, plus nous risquons de dépasser le sens de "pas trop grand"