Discussion :

[Invité]

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)

50 000, c'est un objectif ambitieux. L'idée générale c'est qu'il faudrait idéalement que chacun des concepteurs de cette librairie (ou quelqu'un y passant un peu temps) puisse avoir tout le code en tête... C'est à mon avis, la seul façon de conserver cohérence et simplicité dans un projet.

D'expérience, une tête peut contenir entre 50 et 100 000 lignes de code dense (je compte 40 signes par ligne, et j'ai tendance à nommer court).

Maintenant, ce n'est pas complètement utopique : la STL, c'est moins que ca.

Pour Qt, ou d'autres frameworks, il faut bien voir que la hierarchie globale, ca coûte beaucoup en terme de taille, tout comme la STL maison, l'approche résolument OO...

Francois

[Jean-Marc.Bourguet]

Jean marc

Jean-Marc il a trois gamins, un femme, un boulot, une maison et 1200 pages à lire et à commenter dans le copieux temps libre que lui laissent ces éléments.

En prime, c'est un aspect de l'informatique qui m'a toujours laissé assez indifférent.

J'aimerais une simple à utiliser, en C++ moderne (je me demande dans quelle mesure ne pas partir un supposant un support de C++0X ne serait pas un bon choix et technique -- le temps que vous ayez quelque chose d'utilisable pour autre chose que de l'expérimentation, j'espère que les compilateurs seront disponibles -- et politique -- vous ne battrez jamais Qt, Gtk++ ou wxWidget sur leur terrain, l'absence de contraintes historiques est un point dont il faut profiter) et une bibliothèque plutôt qu'un framework s'imposant dans tous les aspects de mon programme.

[koala01]

A vrai dire, si j'ai cité ton nom, ce n'est pas forcément pour t'enrôler de force, mais c'est parce que je (re)connais tes qualités et que j'avoue une forte propension à prendre tes remarques en compte.

Maintenant, il est vrai que, dans la situation dans laquelle tu te trouve, il risque d'être difficile de dégager du temps pour un projet de ce style

Mais donc, tu serais donc plutôt d'avis de jouer "à fond" la carte de la prochaine norme et de boost, quitte à effectivement laisser une bonne partie des compilateurs "anciens" sur le carreau

[epsilon68]

et pourquoi ne pas apprendre de l'histoire de Qt?
tous les projets commencent clean puis doivent gérer un historique.
(Stroustrup avait fait la meme remarque sur les nouveaux langages)

Je lis les blogs de Qt, et je pense que ca donne un avant-gout des problèmes rencontrés tous les jours dans ce domaine.

ils ont du faire un framework (QString etc) car il le fallait pour les alléger dans leur propre taches (en interne). Vous n'en ferez peut-etre pas pour les memes objets mais pour d'autre... (creant l'historique)

mais le plus important, vous n'aurez pas la base utilisateur pour tester le code. Des milliers d'heures sont a prevoir, je pense que c'est impossible à faire sur du temps personnel.

Moi aussi j'aimerais refaire, mais l'experience me dit qu'on finit par comprendre le design (qu'on remettait en cause) des autres framework.

moi je pense que si j'avais des heures libres, alors je me lancerais dans un projet balbutiant mais prometteur (LLVM java -> C ou etc)
ou alors je ferais un logiciel qui manque mais avec les outils actuels (Qt quick par exemple)

en fait l'experience me dit qu'il vaut mieux avancer plutot que de refaire. Je prefererais meme contribuer à Qt vu qu'il rallie tout le monde et qu'il pourrait permettre au C++ de redevenir attractif pour de nombreux projets (webkit, Qt quick, etc)

[yan]

yan

je trouve le projet super intéressant, mais de la à trouver le temps....
On est entrain de voir pour un lib simplifiant l'utilisation de Qt.
Si j'essaie de participer à tous les projets, je vais rien faire...

Je trouve aussi très intéressant de partir directement de la nouvelle norme.


Pour l'ihm, au lieu de tous refaire, pourquoi pas faire une sur-couche à une lib existante?
Je ne connait pas assez, mais gtk ou fltk semble être de bon candidat pour cela.
Le but serait de cacher tous cela en interne et d'avoir une api propre à utiliser.
Faire un truc comme gtk# ou qyoto mais avec du C++ moderne et en faisant abstraction de sont implémentation.


Ou alors partir de chose comme sdl ou OpenGl, pourquoi pas?

[Jean-Marc.Bourguet]

Maintenant, il est vrai que, dans la situation dans laquelle tu te trouve, il risque d'être difficile de dégager du temps pour un projet de ce style

C'est quelque chose d'ambitieux. Très. Un facteur pour qu'il réussisse est de réussir à limiter l'ambition.

Mais donc, tu serais donc plutôt d'avis de jouer "à fond" la carte de la prochaine norme et de boost, quitte à effectivement laisser une bonne partie des compilateurs "anciens" sur le carreau

C'est ça -- et c'est un raisonnement plutôt marketting que technique.

Vous aurez assez vite des contraintes de compatibilité comme ça.

[koala01]

et pourquoi ne pas apprendre de l'histoire de Qt?
tous les projets commencent clean puis doivent gérer un historique.
(Stroustrup avait fait la meme remarque sur les nouveaux langages)

Peut être, de ce point de vue là, est-ce donc, justement, le meilleur moment pour partir d'une page blanche...

Si l'on admet l'idée de faire du C++ moderne supportant et utilisant boost ou les features de C++11, il devient tout à fait possible de partir sur des bases totalement différentes de n'importe quel bibliothèque ayant des buts similaires, et d'apporter de ce fait des solutions totalement innovantes et efficaces.

Je lis les blogs de Qt, et je pense que ca donne un avant-gout des problèmes rencontrés tous les jours dans ce domaine.

ils ont du faire un framework (QString etc) car il le fallait pour les alléger dans leur propre taches (en interne). Vous n'en ferez peut-etre pas pour les memes objets mais pour d'autre... (creant l'historique)

C'est comme toujours, oublier l'histoire est le meilleur moyen de reproduire des erreurs (et, inversement, se rappeler son histoire est le moyen par excellence pour éviter de les reproduire )

Il ne s'agit absolument pas de se dire que "rien n'a existé jusqu'à présent", mais bien d'identifier et de comprendre les différents travers et problèmes auxquels les autres ont été confronté afin de les éviter et, autant que faire se peut, de tenter de faire mieux

mais le plus important, vous n'aurez pas la base utilisateur pour tester le code.

Il faut te dire que tous les projets existants, tous les langages, toutes les applications ont trouvé leur point de départ dans une idée un peu folle proche de "et si on faisait..."

A te lire, on aurait presque l'impression que tu estimes que tout a été fait, qu'il "n'y a plus rien à inventer", et que la seule chose à laquelle on puisse s'attendre dans notre vie consiste à ... essayer de maintenir l'existant.

Je serais franchement vraiment triste de constater qu' il en va ainsi

Des milliers d'heures sont a prevoir, je pense que c'est impossible à faire sur du temps personnel.

Je n'ai jamais dit que, en commençant aujourd'hui, il serait possible d'avoir quelque chose pour la fin du mois

Je suis conscient qu'un tel projet représenterait plusieurs milliers d'heures/homme pour avoir une première version testable, mais, à coté de cela, 1000 heure / homme, ca peut faire seulement 50 heure /personne avec une équipe de vingt, soit deux mois à peine à raison d'une heure par jours...

Ce que je veux dire, c'est que, bien sur, il y a des périodes de "revue de code" ou d'analyse des besoins ou de "brain storming" pendant lesquelles "tout le monde" doit s'atteler au même problème, mais, en dehors de ces périodes, si l'on s'organise correctement (et que l'on a le monde pour ), il n'est pas interdit d'envisager que plusieurs équipes travaillent dans des domaines parfaitement parallèles (une équipe s'occupant d'un module ou d'une classe A, une autre d'un module ou d'une classe B, la troisième mettant au point le protocole de test de A, une quatrième s'occupant du protocole de teste de B, et ainsi de suite)...

Moi aussi j'aimerais refaire, mais l'experience me dit qu'on finit par comprendre le design (qu'on remettait en cause) des autres framework.

Bien sur que l'on finit par comprendre et par s'habituer à n'importe quoi...

C'est sans doute pour cela que MFC est encore utilisé à l'heure actuelle, alors que, sauf erreur, même microsoft a fini par les délaisser...

Mais, si tout le monde avait suivi ce raisonnement, même Qt n'aurait sans doute jamais vu le jour

moi je pense que si j'avais des heures libres, alors je me lancerais dans un projet balbutiant mais prometteur (LLVM java -> C ou etc)
ou alors je ferais un logiciel qui manque mais avec les outils actuels (Qt quick par exemple)

Chacun voit midi à sa porte

Tu es donc tout à fait libre du choix des projets auxquels tu contribue

en fait l'experience me dit qu'il vaut mieux avancer plutot que de refaire. Je prefererais meme contribuer à Qt vu qu'il rallie tout le monde et qu'il pourrait permettre au C++ de redevenir attractif pour de nombreux projets (webkit, Qt quick, etc)

Si tu avais utilisé le terme "copier", j'aurais été entièrement d'accord avec toi...

Mais avancer, c'est aussi, parfois, se rendre compte des limitations subies et décider de changer de point de vue.

C'est parce que quelqu'un a fini par se rendre compte des limites de l'injection directe que le common rail a vu le jour, et est sur le point de se généraliser

Et, d'une certaine manière, y a-t-il meilleur moment pour changer de point de vue qu'un moment où, justement, des améliorations majeures sont sur le point d'être apportées au langage

[epsilon68]

Hello,

Je ne dis pas que tout a été déjà fait, mais sur le sujet des GUI, il y a eu beaucoup de tentative, et je ne retiens que Qt. S'il te plait, regarde bien qu'ils ne sont pas en train de maintenir mais d'innover.

D'autre part, Cx11 n'apporte pas à mon gout assez d'innovation pour contribuer significativement à une réécriture d'une GUI. En tous cas, rien qui ne pourrait etre implementé dans Qt, non?

MFC était vraiment ... pas bien conçu. Mais si tu regardes bien, Qt n'a pas simplement refait, ils sont parti avec une idée directrice, les signals/slots.

et toi que proposes tu comme idée innovante?
refaire pour du code plus clean? ça ce n'est pas innovant, tu n'apportes rien de plus que de longues heures de coding.

De plus la beauté du code en c++ est relative. Je trouve le code Qt tres clean, et le code C++ stl tres long tres verbeux et pas forcement clean.

en fait j'ai besoin d'autre chose qu'une lib graphique dans mon metier (parce que j'ai Qt) de tous les jours, donc ca serait plutot sur les besoins non couverts actuellement que je me concentrerais si j'étais toi.
(je pense LLVM et ses applications)

donc je pense qu'il te manque l'idée innovante, refaire pour du code propre n'est pas judicieux a mon gout (Qt est la et innove chaque jour)

[Invité]

Quelques commentaires sur la difficulté et l'utilité de la chose...

Qt et la plupart des frameworks du même style, ont été conçus à une époque où l'on considérait que l'approche "pur objet", avec ses hiérarchies de classes géantes était la solution au problème de l'interface.

Ces frameworks ont également été imaginés comme des solutions complètes, une sorte de librairie standard géante, qui était d'autant plus nécessaire qu'à cette époque, la STL était encore balbutiante. Ce type d'approche a donné naissance à toutes sortes de frameworks très larges, comme .NET ou les librairies Java.

La question posée ici est de savoir si les méthodes modernes (pas juste les avantages que la nouvelle norme offre, mais le regard différent qu'on porte aujourd'hui sur l'objet et les paradigmes de programmation), l'existence de librairies spécialisées de haut niveau dans pas mal de domaines, et (ce n'est pas un détail) la relative stabilisation de l'évolution des OS, permettent une approche différente, plus légère, des problème d'interface en C++.

Un autre aspect, également intéressant, est le fait qu'il y a pas mal de code de framework accessible. Ceci permet un certain recul, vis à vis des idées, de ce qui marche, de ce qui est compliqué.


Je ne sais pas si un tel projet a une chance, mais je suis convaincu que la réflexion qui va avec est en soi intéressante. Je crois également qu'il n'est pas certain que ce projet, s'il aboutit, produise un Qt++ ou quelque chose du genre. Il est tout à fait possible qu'une telle librairie occupe une niche spécifique, par exemple les interfaces légères, ou le jetable, ou, au contraire, les interfaces "dessinées", ou puisse venir en complément de frameworks lourds, en prototypage, ou pour des modules annexes...

Bref, on va peut être (sans doute) trouver d'excellentes raisons de ne pas le faire, mais l'idée que "ca existe déjà" ne me parait pas en être une.

Francois (4 enfants, un boulot, une traduction en cours, des hobbys, et pas trop de temps libre, mais quand même intéressé...)

[Goten]

C'est un topic ASV en fait hein ? :p.

Bon quelques réponses en vrac (fin de semaine il est tard tout ça tout ça) :

Avant tout, je pense qu'il y'a de la place, oui y'a des géants (Qt entre autres) qui sont déjà très bien installé, mais y'a de la place pour de la nouveauté. Il suffit de voir ce qu'on fait les gars de chez adobe avec adam&eve ... C'est assez monstrueux et ça *révolutionne* le monde de l'ihm.
D'un autre côté, l'idée d'avoir une bibliothèque d'ihm à la sauce boost me plairait beaucoup. (Comme asio ou spirit, sont venu sur un segment déjà bien fourni mais avec une autre approche, beaucoup plus moderne de la chose).
De là à dire si c'est réalisable comme ça, j'en sais rien, entre le temps que chacun à et même les connaissances (ni voir aucune attaque personnelle, je vise personne, et je me compte dedans :p).

Pour ma part, et comme JM Bourguet j'avoue que c'est un "secteur" du développement qui m'a jamais attiré (tout comme les jeux d'ailleurs).

My two cents...

[koala01]

Hello,

Je ne dis pas que tout a été déjà fait, mais sur le sujet des GUI, il y a eu beaucoup de tentative, et je ne retiens que Qt. S'il te plait, regarde bien qu'ils ne sont pas en train de maintenir mais d'innover.

Tu as, visiblement, très mal interprété ce que je voulais dire...

Je ne voulais absolument pas parler d'un quelconque projet en particulier, et surement pas de Qt, pour ne citer que lui.

Je te signale au passage que j'ai toujours salué la qualité de cette dernière

Seulement, quand je lis une réflexion comme

Avec l'expérience, on finit par s'habituer (...)

je ne peux m'empêcher d'assimiler ca à des phrases comme

Tout ce qui était à faire a été fait, maintenant, il n'y a plus qu'à améliorer / maintenir

Et comprenons nous sur les termes: il n'est pas impossible d'innover en ajoutant des fonctionnalités (ce que fait parfaitement Qt, soit dit en passant )... Mais cela reste dans la pure lignée des décisions prises au départ, et pourrait malgré tout s'assimiler à "du maintien".

D'autre part, Cx11 n'apporte pas à mon gout assez d'innovation pour contribuer significativement à une réécriture d'une GUI. En tous cas, rien qui ne pourrait etre implementé dans Qt, non?

C++11 apporte un certain nombre de nouveautés déjà par rapport à C++03 et au TR1.

Et toutes ces nouveautés pourraient, effectivement, être implémentées dans Qt.

Par contre, il faut se rappeler, comme l'a si bien fait remarquer François, que Qt (comme une bonne partie des frameworks ayant des objectifs similaires) a été lancé à une époque où le "courant de pensée" était totalement différent de ce qu'il peut être actuellement, et où le langage était à peine normalisé et, par voie de conséquence, où le support de la norme était lui-même très inégale.

Or, si on regarde les courants de pensées actuels, on se rend compte que les différents paradigmes utilisés par C++ sont abordé de manière totalement différente qu'à l'époque, ce qui peut parfaitement ouvrir de "nouveaux horizons" si nous décidions, aujourd'hui, de lancer le développement d'un tel framework.

Il est plus que vraisemblable qu'un langage "tout objet" ou qu'un Super Objet comme java ne serait plus considéré comme des alternatives valables, car ces méthodes ont fini par montrer leurs limites.

MFC était vraiment ... pas bien conçu. Mais si tu regardes bien, Qt n'a pas simplement refait, ils sont parti avec une idée directrice, les signals/slots.

Encore une fois, il ne faut pas confondre: je ne veux absolument pas lancer un troll ou un débat sur les qualités des différents framework existant...

Et je ne veux surement pas dénigrer Qt, pour lequel, je le rappelle encore, j'ai le plus grand respect

et toi que proposes tu comme idée innovante?

Déjà la possibilité d'adopter, pourquoi pas, un point de vue plus en rapport avec le courant de pensée actuel.

Peut être la possibilité de faire sauter certains verrous imposés par l'existant tels que les incompatibilités entre les chaines de caractères (STL Vs celle du framework), les collections (std::list Vs QList), etc...

Une simplification de la procédure permettant de compiler un projet a mano: Il faut avouer que, si tu pars d'un fichier *.ui et que quelques modules perso, la procédure (ou le script) à mettre en oeuvre demande un (trop)grand nombre d'étapes, entre qmake, moc et tuti quanti... Par chance, la création de scripts est possible

Si on arrive à ne pas rendre le passage par un système particulier (ou une procédure demandant de faire intervenir trop d'outils différents dans un ordre particulier) obligatoire, et donc de faire en sorte que l'utilisation "des autres possibilités" ( (C)make, autotools, bjam, compilation réellement manuelle) n'est pas plus compliquée que d'utiliser le "système dédié", il y a très certainement matière à "coaliser" un grand nombre d'utilisateurs

Il est tout à fait vrai que l'idée est encore très immature, mais dois-je rappeler ce que j'ai clairement précisé dans ma question originelle

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

Tu n'es peut être pas convaincu de l'utilité du projet, et j'admets parfaitement ton point de vue...

Est-ce une raison pour vouloir l'imposer Ai-je oublié de préciser que je ne mettrai le couteau sous la gorge de personne pour les obliger à être d'accord ou à participer

Et puis, même si je devais ne jamais lancer réellement le projet, y a-t-il le moindre mal à proposer aux gens de réfléchir à "ce qu'ils feraient" où à "ce qu'ils voudraient"

refaire pour du code plus clean? ça ce n'est pas innovant, tu n'apportes rien de plus que de longues heures de coding.

La propreté du code est très subjective, mais, ce n'est pas le seul objectif de la chose...

L'idée serait, réellement, de partir d'un point de vue totalement différent et de respecter un courant de pensée bien plus actuel, en faisant table rase des lourdeurs imposées par l'historique de l'existant (sans pour autant considérer l'expérience acquise par leur biais )

De plus la beauté du code en c++ est relative. Je trouve le code Qt tres clean, et le code C++ stl tres long tres verbeux et pas forcement clean.

Encore une fois, je ne remet absolument pas la qualité de Qt en cause...

J'admets que la STL a tendance à être verbeuse, mais il faut se rappeler qu'il y a une foule de possibilités, offertes par le langage, de diminuer cette verbosité... Et puis, je dois avouer que j'apprécie d'une certaine manière cette verbosité

en fait j'ai besoin d'autre chose qu'une lib graphique dans mon metier (parce que j'ai Qt) de tous les jours, donc ca serait plutot sur les besoins non couverts actuellement que je me concentrerais si j'étais toi.
(je pense LLVM et ses applications)

C'est un choix qui t'honore, mais qui n'engage que toi

donc je pense qu'il te manque l'idée innovante, refaire pour du code propre n'est pas judicieux a mon gout (Qt est la et innove chaque jour)

Comme je l'ai fait remarquer tout au long de ma réponse, et tout au long de la discussion, refaire quelque chose pour se contenter de copier n'a effectivement rien d'innovant, et ce n'est très certainement pas le but de l'exercice...

L'idée est réellement de partir d'un point de vue neuf... A partir de là, tout peut arriver

[koala01]

je trouve le projet super intéressant, mais de la à trouver le temps....

On est entrain de voir pour un lib simplifiant l'utilisation de Qt.
Si j'essaie de participer à tous les projets, je vais rien faire...

Tu trouves déjà le temps de donner ton avis... c'est déjà pas si mal

Je trouve aussi très intéressant de partir directement de la nouvelle norme.

Plus j'y réfléchi, plus je trouve qu'il serait normal de le faire, bien que cela place de sérieuses restrictions à la compatibilité vis à vis des compilateur

Pour l'ihm, au lieu de tous refaire, pourquoi pas faire une sur-couche à une lib existante?
Je ne connait pas assez, mais gtk ou fltk semble être de bon candidat pour cela.
Le but serait de cacher tous cela en interne et d'avoir une api propre à utiliser.

Le problème à mon sens serait, principalement, que, si on se contente d'une surcouche de l'existant, on reste malgré tout fort dépendant des restrictions qu'impose l'existant...

L'idée est -- vraiment -- de partir d'un point de vue totalement neuf, en mariant au mieux les différentes possibilités offertes par le courant de pensée actuel

[yan]

Le problème à mon sens serait, principalement, que, si on se contente d'une surcouche de l'existant, on reste malgré tout fort dépendant des restrictions qu'impose l'existant...

L'idée est -- vraiment -- de partir d'un point de vue totalement neuf, en mariant au mieux les différentes possibilités offertes par le courant de pensée actuel

Je ne suis pas sure que c'est totalement incompatible.
Va bien falloir utiliser a un moment ou un autre quelque chose la couche de l'OS. Et descendre jusqu'à la GDI+ ou x11 c'est assez violent...

[epsilon68]

et descendre jusqu'à la GDI+ ou x11 c'est assez violent...

carrement :-D

[Invité]

Va bien falloir utiliser a un moment ou un autre quelque chose la couche de l'OS. Et descendre jusqu'à la GDI+ ou x11 c'est assez violent...

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

Ce qui est nettement plus désagréable, c'est la gestion des messages dans l'OS... C'est à mon avis la partie crade du projet...

Francois

[yan]

Q travail pour simplifier son portage sur de nouvelle plateforme.
http://labs.trolltech.com/blogs/2009...rite-platform/
C'est peut être intéressant de regarder de plus prés ce qu'ils font.

[koala01]

Je ne suis pas sure que c'est totalement incompatible.
Va bien falloir utiliser a un moment ou un autre quelque chose la couche de l'OS. Et descendre jusqu'à la GDI+ ou x11 c'est assez violent...

carrement :-D

Pourquoi N'est-ce pas, quelque part, ce qui a été fait par l'ensemble des frameworks

D'une certaine manière, ne serait-ce pas, justement, l'aspect qui sera au final le plus simple à mettre en oeuvre, étant donné la "facilité" de comparaison avec l'existant que nous aurons

C'est, effectivement, la partie qui est susceptible d'être la plus crade / la plus éloignée des "coding styles standards" actuels, mais, si ca permet de partir sur de bonnes bases...

[metagoto]

Il y a quelques années, j'ai entrepris de créer mon propre framework GUI après avoir lu les bouquins de Alexandrescu et Template Metaprogramming. Accessoirement aussi parce que je détestais MFC et je ne comprenais pas tout de WTL (peu de doc) et je n'aimais pas wxWidgets. Etrangement, je n'avais pas vraiment connaissance ou d'intéret pour Qt.

Les idées de base:

- utiliser les templates pour générer l'équivalent de la "messages map" (MFC, WTL, wx..) de manière statique.
- utiliser les policies pour spécifier le comportement des widgets/windows
- utiliser les traits pour targeter Win32 (mon OS de prédilection à l'époque) mais également gtk

Mon truc, bien que gringalet, m'a permis d'écrire mon propre éditeur text (qui embarquait scintilla) et un logiciel pour visualiser des gammes et divers trucs tonal pour la guitare (un fretboard interactif). J'étais fier.

En fait je me suis rendu compte que l'idée de la message map statique avait déjà été implémentée/décrite ici:
http://p-stade.sourceforge.net/ketchup/index.html

Les traits ici:
http://notus.sourceforge.net/

Les policies:
http://smartwin.sourceforge.net/

Et pour le look and feel du c++ moderne auquel j'aspirais (en tant de néophyte), du genre RAII etc, ici:
http://www.radcpp.com/documentation/

C'était l'une des première fois où je restais focalisé sur un même "projet" plus de 2 semaines d'affilé. Là, vraiment, j'étais fier
J'ai surtout mesuré à quel point faire un tel framework qui puisse approcher les grands, ceux qui ont pignon sur rue, est une tache herculéenne et que jamais je n'aurais la patience, ni l'envie, d'aller jusqu'au bout .

[koala01]

Merci pour ton retour d'expérience, mais puis-je te poser quelques questions ?

Dans quelle mesure n'as tu pas été découragé par... le simple fait de travailler seul

Il y a de très (trop ) nombreux aspects à maitriser pour arriver à créer une telle bibliothèque... Ton découragement n'est-il pas, encore une fois, du au fait qu'il te semblait "herculéen" de devoir tous les maitriser, alors qu'il aurait pu être opportun de déléguer certaines parties à d'autres les maitrisant mieux que toi, ce qui t'aurait permis de t'atteler à ce que tu maitrisais mieux

Qu'attendrais tu à titre perso d'une "nouvelle" bibliothèque IHM Y a-t-il des aspects intéressants parmi celles que tu as essayées qui te sembleraient intéressants

Si c'était à refaire en équipe, serais tu disposé à participer, même si c'est de manière plus ou moins occasionnelle, ou as tu vraiment été dégouté "à vie" par ton aventure

[metagoto]

Merci pour ton retour d'expérience, mais puis-je te poser quelques questions ?

Dans quelle mesure n'as tu pas été découragé par... le simple fait de travailler seul

Il y a de très (trop ) nombreux aspects à maitriser pour arriver à créer une telle bibliothèque... Ton découragement n'est-il pas, encore une fois, du au fait qu'il te semblait "herculéen" de devoir tous les maitriser, alors qu'il aurait pu être opportun de déléguer certaines parties à d'autres les maitrisant mieux que toi, ce qui t'aurait permis de t'atteler à ce que tu maitrisais mieux

Qu'attendrais tu à titre perso d'une "nouvelle" bibliothèque IHM Y a-t-il des aspects intéressants parmi celles que tu as essayées qui te sembleraient intéressants

Si c'était à refaire en équipe, serais tu disposé à participer, même si c'est de manière plus ou moins occasionnelle, ou as tu vraiment été dégouté "à vie" par ton aventure

J'ai arrêté tout simplement parce que j'avais envie de passer à autre chose. Je n'étais aucunement dégouté

Mon "système" fonctionnait. En gros, il ne me restait plus qu'à dérouler des lignes de codes pour ajouter toujours plus de controls (widgets) du genre rebar, combo box avec icons etc ainsi que plus d'algo pour la gestion des layouts. Attention, en aucun cas mon truc ne constituait un embryon de framework "de qualité". Ca a juste été un bon exercice. Comme je développais mon éditeur text en parallèle, j'ai occulté des pans entiers dignes d'un vrai framework. J'en n'avais tout simplement pas besoins.

J'attendrai d'une nouvelle bibliothèque IHM qu'elle soit implémentée en c++11