ton appli est une appli native Windows sous Windows, une appli native GTK2 sous Linux, une appli native MacOSX sous MacOSX
Je ne l'ai pas du tout raté : c'est justement ce que je lui repproche ! Avec ce principe, tu dois tester ton interface graphique avec tous les toolkits et tous les systèmes supportés si tu veux être sûr que ça marche. Encore une fois, Java 1.1 avait fait la même chose et ils en sont (heureusement) revenu.
Le gros problème des IHM (Interfaces Homme Machines) est qu'elles sont très sensibles au détail. Du coup je préfère 100x développer une IHM avec Qt et avoir le même look'n'feel sous linux et sous windows qu'avoir une IHM qui tourne bien avec Linux/Qt parce que je l'ai développé comme ça et me rendre compte qu'avec Gtk ça marche pas du tout parce que les zones d'éditions de textes ne sont pas gérées pareil par exemple, et les différences seront encore plus grandes sous Windows et Mac OS X.
Enfin, vouloir faire ça c'est s'imposer un surcroit de travail important puisqu'il s'agit non plus d'utiliser des primitives assez simples du système dans un noyaux graphique le plus petit possible et ne porter que ça (le reste reposant sur ce noyaux) mais tout redévelopper pour chaque toolkit pour que ça ait le "look'n'feel" du toolkit en question ! Et qui dit surcroit de travail, dis aussi surcroit de bugs (puisque dans ce cas il y a aussi surcroit de lignes de code).
[^] # Re: Mouai ...
Posté par harbort1 . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 4.
Je ne l'ai pas du tout raté : c'est justement ce que je lui repproche ! Avec ce principe, tu dois tester ton interface graphique avec tous les toolkits et tous les systèmes supportés si tu veux être sûr que ça marche. Encore une fois, Java 1.1 avait fait la même chose et ils en sont (heureusement) revenu.
Le gros problème des IHM (Interfaces Homme Machines) est qu'elles sont très sensibles au détail. Du coup je préfère 100x développer une IHM avec Qt et avoir le même look'n'feel sous linux et sous windows qu'avoir une IHM qui tourne bien avec Linux/Qt parce que je l'ai développé comme ça et me rendre compte qu'avec Gtk ça marche pas du tout parce que les zones d'éditions de textes ne sont pas gérées pareil par exemple, et les différences seront encore plus grandes sous Windows et Mac OS X.
Enfin, vouloir faire ça c'est s'imposer un surcroit de travail important puisqu'il s'agit non plus d'utiliser des primitives assez simples du système dans un noyaux graphique le plus petit possible et ne porter que ça (le reste reposant sur ce noyaux) mais tout redévelopper pour chaque toolkit pour que ça ait le "look'n'feel" du toolkit en question ! Et qui dit surcroit de travail, dis aussi surcroit de bugs (puisque dans ce cas il y a aussi surcroit de lignes de code).
Non, vraiment c'est une mauvaise idée !