wxWidgets, avantages et inconvénients

Arnold McDonald

20/09/2007 à 15:44

> Arnold, évite de me répondre que rien ne vaut l'API pure et dure. C'est
plus de mon âge...

Ce n'est pas une question d'âge, mais une question de motivation et de vue à
loooong terme. Utiliser une librairie d'encapsulation procure des avantages
indéniables, certes, mais il y aura toujours les défauts suivants :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation. Cela peut s'avérer dommageable, notamment dans le cas où la
gestion mémoire (simple exemple) est un peu olé-olé. S'il y a des bugs, il
te faut attendre les correctifs.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que devant
couvrir un champ d'application assez large et être plutôt génériques, les
composants (simple exemple) de ces librairies sont truffés de détails
absolument inutiles. Lourdeur. C'est comme installer Oracle pour gérer une
liste d'abonnés à un forum...

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte des
nouvelles versions de Windows (ou simplement des patches !), ou, tout
simplement, la poursuite de l'existence de la librairie ! Parier sur la
pérennisation de quelque chose qui ne t'appartient pas est difficile...

- Il n'existe aucune libraire parfaite. Il te faudra donc, tôt ou tard,
l'hériter, la dériver, la modifier. C'est inéluctable dès lors que tu veux
de belles GUI, des composants légers, une gestion tip top de la mémoire,
suivre l'évolution de l'OS plus vite que les concepteurs de ces librairies
ne le font en général, etc.

Alors, amha, autant l'écrire directement. Rien ne vaut la précision et la
spécialisation. Oui, ça prend des années de tout s'écrire soi-même, mais il
y a des avantages inégalables. Le contrôle absolu du look, de la gestion
mémoire, du fonctionnement interne, des droits d'utilisation, du poids des
composants, la facilité d'extension, de modification, etc. J'ai des
composants qui font approcher 15 ans, et les seules modifications sont au
niveau du look de temps en temps pour suivre les modes. Une fois que c'est
bien écrit et au point hein, et bien c'est fait ! Il ne faut pas croire
qu'il faille tout réécrire sans cesse, lol. Demande à VB si ça ne vaut pas
le coup de tout se faire :-).

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7, 8,
10 ou 12 paramètres ! Mais bon, je n'ai pas cette philosophie de codage C++
apprise dans les écoles depuis quelques années. Moi, si je crée des
composants, je crée un objets/structure que je remplis/modifie et je m'en
sers pour chaque composant, c'est différent d'appeler une méthode avec 10
paramètres... Réutilisation, gain de temps, de mémoire, etc. Ces librairies
sont codées avec une philosophie qui n'est pas la mienne :-(.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait !
Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à wxWidget,
je ne sais pas.

--
Arnold McDonald (AMcD) - Help #9(71) /2007

http://arnold.mcdonald.free.fr/

> Arnold, évite de me répondre que rien ne vaut l'API pure et dure. C'est
plus de mon âge...

Ce n'est pas une question d'âge, mais une question de motivation et de vue à
loooong terme. Utiliser une librairie d'encapsulation procure des avantages
indéniables, certes, mais il y aura toujours les défauts suivants :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation. Cela peut s'avérer dommageable, notamment dans le cas où la
gestion mémoire (simple exemple) est un peu olé-olé. S'il y a des bugs, il
te faut attendre les correctifs.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que devant
couvrir un champ d'application assez large et être plutôt génériques, les
composants (simple exemple) de ces librairies sont truffés de détails
absolument inutiles. Lourdeur. C'est comme installer Oracle pour gérer une
liste d'abonnés à un forum...

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte des
nouvelles versions de Windows (ou simplement des patches !), ou, tout
simplement, la poursuite de l'existence de la librairie ! Parier sur la
pérennisation de quelque chose qui ne t'appartient pas est difficile...

- Il n'existe aucune libraire parfaite. Il te faudra donc, tôt ou tard,
l'hériter, la dériver, la modifier. C'est inéluctable dès lors que tu veux
de belles GUI, des composants légers, une gestion tip top de la mémoire,
suivre l'évolution de l'OS plus vite que les concepteurs de ces librairies
ne le font en général, etc.

Alors, amha, autant l'écrire directement. Rien ne vaut la précision et la
spécialisation. Oui, ça prend des années de tout s'écrire soi-même, mais il
y a des avantages inégalables. Le contrôle absolu du look, de la gestion
mémoire, du fonctionnement interne, des droits d'utilisation, du poids des
composants, la facilité d'extension, de modification, etc. J'ai des
composants qui font approcher 15 ans, et les seules modifications sont au
niveau du look de temps en temps pour suivre les modes. Une fois que c'est
bien écrit et au point hein, et bien c'est fait ! Il ne faut pas croire
qu'il faille tout réécrire sans cesse, lol. Demande à VB si ça ne vaut pas
le coup de tout se faire :-).

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7, 8,
10 ou 12 paramètres ! Mais bon, je n'ai pas cette philosophie de codage C++
apprise dans les écoles depuis quelques années. Moi, si je crée des
composants, je crée un objets/structure que je remplis/modifie et je m'en
sers pour chaque composant, c'est différent d'appeler une méthode avec 10
paramètres... Réutilisation, gain de temps, de mémoire, etc. Ces librairies
sont codées avec une philosophie qui n'est pas la mienne :-(.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait !
Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à wxWidget,
je ne sais pas.

--
Arnold McDonald (AMcD) - Help #9(71) /2007

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

> Arnold, évite de me répondre que rien ne vaut l'API pure et dure. C'est
plus de mon âge...

Ce n'est pas une question d'âge, mais une question de motivation et de vue à
loooong terme. Utiliser une librairie d'encapsulation procure des avantages
indéniables, certes, mais il y aura toujours les défauts suivants :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation. Cela peut s'avérer dommageable, notamment dans le cas où la
gestion mémoire (simple exemple) est un peu olé-olé. S'il y a des bugs, il
te faut attendre les correctifs.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que devant
couvrir un champ d'application assez large et être plutôt génériques, les
composants (simple exemple) de ces librairies sont truffés de détails
absolument inutiles. Lourdeur. C'est comme installer Oracle pour gérer une
liste d'abonnés à un forum...

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte des
nouvelles versions de Windows (ou simplement des patches !), ou, tout
simplement, la poursuite de l'existence de la librairie ! Parier sur la
pérennisation de quelque chose qui ne t'appartient pas est difficile...

- Il n'existe aucune libraire parfaite. Il te faudra donc, tôt ou tard,
l'hériter, la dériver, la modifier. C'est inéluctable dès lors que tu veux
de belles GUI, des composants légers, une gestion tip top de la mémoire,
suivre l'évolution de l'OS plus vite que les concepteurs de ces librairies
ne le font en général, etc.

Alors, amha, autant l'écrire directement. Rien ne vaut la précision et la
spécialisation. Oui, ça prend des années de tout s'écrire soi-même, mais il
y a des avantages inégalables. Le contrôle absolu du look, de la gestion
mémoire, du fonctionnement interne, des droits d'utilisation, du poids des
composants, la facilité d'extension, de modification, etc. J'ai des
composants qui font approcher 15 ans, et les seules modifications sont au
niveau du look de temps en temps pour suivre les modes. Une fois que c'est
bien écrit et au point hein, et bien c'est fait ! Il ne faut pas croire
qu'il faille tout réécrire sans cesse, lol. Demande à VB si ça ne vaut pas
le coup de tout se faire :-).

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7, 8,
10 ou 12 paramètres ! Mais bon, je n'ai pas cette philosophie de codage C++
apprise dans les écoles depuis quelques années. Moi, si je crée des
composants, je crée un objets/structure que je remplis/modifie et je m'en
sers pour chaque composant, c'est différent d'appeler une méthode avec 10
paramètres... Réutilisation, gain de temps, de mémoire, etc. Ces librairies
sont codées avec une philosophie qui n'est pas la mienne :-(.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait !
Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à wxWidget,
je ne sais pas.

--
Arnold McDonald (AMcD) - Help #9(71) /2007

http://arnold.mcdonald.free.fr/

Bertrand Lenoir-Welter

20/09/2007 à 18:48

Arnold :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation.

Argument rejeté. C'est de l'Open Source. Mais je ne connais pas non plus
tous les détails de Borland OWL que j'ai utilisée pendant des années, et
j'ai réussi à survivre.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que
devant couvrir un champ d'application assez large et être plutôt
génériques, les composants (simple exemple) de ces librairies sont
truffés de détails absolument inutiles. Lourdeur.

Argument retenu. Sauf que je peux me servir de l'encapsulation pour le
pain quotidien et rien ne m'empêche de descendre au fournil quand j'ai
envie d'une brioche, en l'occurence un traitement un peu custom.

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte
des nouvelles versions de Windows (ou simplement des patches !), ou,
tout simplement, la poursuite de l'existence de la librairie ! Parier
sur la pérennisation de quelque chose qui ne t'appartient pas est
difficile...

Bah, je continue encore parfois d'utiliser OWL qui a été abandonnée en
1997. Les projets Open Source me semblent moins soumis aux aléas de
stratégie marketing des éditeurs de compilos. La preuve : il existe
encore une communauté OWL plus ou moins vivante, alors que les gens de
Borland ne se souviennent même plus de ce que c'était.

- Il n'existe aucune libraire parfaite.

Certes, mais je cherche juste une librairie suffisante pour fournir
l'essentiel de l'appli - et très éventuellement permettre un portage
sous d'autres cieux. La question pour moi n'est pas entre wxWidgets et
tailler moi-même la piste à la machette, mais entre wxWidgets et MFC ou
autre équivalent. Je suis pas un fan des MFC et .NET n'apporte rien pour
ce que j'ai à faire, surtout que je tiens à rester en C++.

Alors, amha, autant l'écrire directement.

Non, j'ai vraiment passé l'âge de me bricoler des interfaces graphiques
maison, et de toute façon j'ai pas le temps. C'est le tableau qui compte
pour moi, pas son cadre ni son clou. Je veux dire que j'ai assez à faire
avec le codage applicatif pour pas passer en plus du temps à bidouiller
dans les DC.

Demande à VB si ça ne vaut pas le coup de tout se faire :-).

Ouais, j'ai un pote comme ça, qui a longtemps cru pouvoir faire mieux
qu'OpenGL. Je sais pas s'il a réussi, mais à mon avis il a dépensé
beaucoup d'énergie pour sa satisfaction personnelle. Et rien ne
m'empêche d'ajouter des classes maison avec des petits contrôles
rigolos. Je le faisais aussi sur base OWL.

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7,
8, 10 ou 12 paramètres !

Bah, questions listes d'arguments, tu préfères l'API directe ?

De toute façon, rien ne t'empêche de dériver quelques classes bien à toi
qui n'auront pas besoin de tous les paramètres. L'idée est de partir
d'un peu plus haut que les fondations.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait
! Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à
wxWidget, je ne sais pas.

Moui, ça parle encore aux vieux de la vieille comme nous, mais avouons
qu'aujourd'hui tout le monde s'en fout. Et sans doute avec raison. A
part quelques fondamentalistes, plus personne ne regarde la taille d'un
exécutable, même s'il faut le télécharger.

Bref, je pose la question autrement pour toi et Vincent : si vous deviez
prendre une encapsulation C++ de l'API sous peine de mort dans d'atroces
souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

Arnold :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation.

Argument rejeté. C'est de l'Open Source. Mais je ne connais pas non plus
tous les détails de Borland OWL que j'ai utilisée pendant des années, et
j'ai réussi à survivre.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que
devant couvrir un champ d'application assez large et être plutôt
génériques, les composants (simple exemple) de ces librairies sont
truffés de détails absolument inutiles. Lourdeur.

Argument retenu. Sauf que je peux me servir de l'encapsulation pour le
pain quotidien et rien ne m'empêche de descendre au fournil quand j'ai
envie d'une brioche, en l'occurence un traitement un peu custom.

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte
des nouvelles versions de Windows (ou simplement des patches !), ou,
tout simplement, la poursuite de l'existence de la librairie ! Parier
sur la pérennisation de quelque chose qui ne t'appartient pas est
difficile...

Bah, je continue encore parfois d'utiliser OWL qui a été abandonnée en
1997. Les projets Open Source me semblent moins soumis aux aléas de
stratégie marketing des éditeurs de compilos. La preuve : il existe
encore une communauté OWL plus ou moins vivante, alors que les gens de
Borland ne se souviennent même plus de ce que c'était.

- Il n'existe aucune libraire parfaite.

Certes, mais je cherche juste une librairie suffisante pour fournir
l'essentiel de l'appli - et très éventuellement permettre un portage
sous d'autres cieux. La question pour moi n'est pas entre wxWidgets et
tailler moi-même la piste à la machette, mais entre wxWidgets et MFC ou
autre équivalent. Je suis pas un fan des MFC et .NET n'apporte rien pour
ce que j'ai à faire, surtout que je tiens à rester en C++.

Alors, amha, autant l'écrire directement.

Non, j'ai vraiment passé l'âge de me bricoler des interfaces graphiques
maison, et de toute façon j'ai pas le temps. C'est le tableau qui compte
pour moi, pas son cadre ni son clou. Je veux dire que j'ai assez à faire
avec le codage applicatif pour pas passer en plus du temps à bidouiller
dans les DC.

Demande à VB si ça ne vaut pas le coup de tout se faire :-).

Ouais, j'ai un pote comme ça, qui a longtemps cru pouvoir faire mieux
qu'OpenGL. Je sais pas s'il a réussi, mais à mon avis il a dépensé
beaucoup d'énergie pour sa satisfaction personnelle. Et rien ne
m'empêche d'ajouter des classes maison avec des petits contrôles
rigolos. Je le faisais aussi sur base OWL.

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7,
8, 10 ou 12 paramètres !

Bah, questions listes d'arguments, tu préfères l'API directe ?

De toute façon, rien ne t'empêche de dériver quelques classes bien à toi
qui n'auront pas besoin de tous les paramètres. L'idée est de partir
d'un peu plus haut que les fondations.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait
! Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à
wxWidget, je ne sais pas.

Moui, ça parle encore aux vieux de la vieille comme nous, mais avouons
qu'aujourd'hui tout le monde s'en fout. Et sans doute avec raison. A
part quelques fondamentalistes, plus personne ne regarde la taille d'un
exécutable, même s'il faut le télécharger.

Bref, je pose la question autrement pour toi et Vincent : si vous deviez
prendre une encapsulation C++ de l'API sous peine de mort dans d'atroces
souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

Vous avez filtré cet utilisateur ! Consultez son message

Arnold :

- Tu ne l'as pas codée toi-même, donc, si ce n'est pas fourni avec le
source, tu ne connais pas les détails internes, l'architecture de
programmation.

Argument rejeté. C'est de l'Open Source. Mais je ne connais pas non plus
tous les détails de Borland OWL que j'ai utilisée pendant des années, et
j'ai réussi à survivre.

- Ces librairies d'encapsulation, MFC, etc. sont parfois codées avec
lourdeur. Il est très difficile de s'y plonger dedans pour modifier un
comportement, rajouter une gestion de message, etc. Sans compter que
devant couvrir un champ d'application assez large et être plutôt
génériques, les composants (simple exemple) de ces librairies sont
truffés de détails absolument inutiles. Lourdeur.

Argument retenu. Sauf que je peux me servir de l'encapsulation pour le
pain quotidien et rien ne m'empêche de descendre au fournil quand j'ai
envie d'une brioche, en l'occurence un traitement un peu custom.

- Tu es dépendant du bon vouloir des concepteurs de la librairie
encapsulatrice. Pour les bugs, les mises à jours, les prises en compte
des nouvelles versions de Windows (ou simplement des patches !), ou,
tout simplement, la poursuite de l'existence de la librairie ! Parier
sur la pérennisation de quelque chose qui ne t'appartient pas est
difficile...

Bah, je continue encore parfois d'utiliser OWL qui a été abandonnée en
1997. Les projets Open Source me semblent moins soumis aux aléas de
stratégie marketing des éditeurs de compilos. La preuve : il existe
encore une communauté OWL plus ou moins vivante, alors que les gens de
Borland ne se souviennent même plus de ce que c'était.

- Il n'existe aucune libraire parfaite.

Certes, mais je cherche juste une librairie suffisante pour fournir
l'essentiel de l'appli - et très éventuellement permettre un portage
sous d'autres cieux. La question pour moi n'est pas entre wxWidgets et
tailler moi-même la piste à la machette, mais entre wxWidgets et MFC ou
autre équivalent. Je suis pas un fan des MFC et .NET n'apporte rien pour
ce que j'ai à faire, surtout que je tiens à rester en C++.

Alors, amha, autant l'écrire directement.

Non, j'ai vraiment passé l'âge de me bricoler des interfaces graphiques
maison, et de toute façon j'ai pas le temps. C'est le tableau qui compte
pour moi, pas son cadre ni son clou. Je veux dire que j'ai assez à faire
avec le codage applicatif pour pas passer en plus du temps à bidouiller
dans les DC.

Demande à VB si ça ne vaut pas le coup de tout se faire :-).

Ouais, j'ai un pote comme ça, qui a longtemps cru pouvoir faire mieux
qu'OpenGL. Je sais pas s'il a réussi, mais à mon avis il a dépensé
beaucoup d'énergie pour sa satisfaction personnelle. Et rien ne
m'empêche d'ajouter des classes maison avec des petits contrôles
rigolos. Je le faisais aussi sur base OWL.

J'ai utilisé wxWidgets deux ou trois fois, ça ne m'a pas trop plus. Je
n'aime pas ces classes imbriquées à perte de vue et les méthodes avec 7,
8, 10 ou 12 paramètres !

Bah, questions listes d'arguments, tu préfères l'API directe ?

De toute façon, rien ne t'empêche de dériver quelques classes bien à toi
qui n'auront pas besoin de tous les paramètres. L'idée est de partir
d'un peu plus haut que les fondations.

J'utilise des softs codés avec wxWidgets, comme audacity par exemple. Je
trouve que des exécutables de 8 Mo, ça fait beaucoup pour ce que ça fait
! Pareil pour d'autres softs. Mais est-ce du aux programmeurs ou à
wxWidget, je ne sais pas.

Moui, ça parle encore aux vieux de la vieille comme nous, mais avouons
qu'aujourd'hui tout le monde s'en fout. Et sans doute avec raison. A
part quelques fondamentalistes, plus personne ne regarde la taille d'un
exécutable, même s'il faut le télécharger.

Bref, je pose la question autrement pour toi et Vincent : si vous deviez
prendre une encapsulation C++ de l'API sous peine de mort dans d'atroces
souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

Vincent Burel

20/09/2007 à 21:17

"Bertrand Lenoir-Welter" <bertrand-dot-2007-at-galaad-dot-net> wrote in
message news:46f2a43d$0$27375$

Arnold :
>
> Demande à VB si ça ne vaut pas le coup de tout se faire :-).

Ouais, j'ai un pote comme ça, qui a longtemps cru pouvoir faire mieux
qu'OpenGL. Je sais pas s'il a réussi, mais à mon avis il a dépensé
beaucoup d'énergie pour sa satisfaction personnelle. Et rien ne
m'empêche d'ajouter des classes maison avec des petits contrôles
rigolos. Je le faisais aussi sur base OWL.

Sympa ! :-)
Pour info je ne fais pas de 3D.

VB

Bertrand Lenoir-Welter

20/09/2007 à 22:27

Vincent Burel :

Sympa ! :-)
Pour info je ne fais pas de 3D.

Argh ! Désolé Vincent, je me suis mal exprimé. Très très loin de moi
l'idée que ta motivation serait une question d'orgueil. Je visais l'idée
générale de systématiquement réinventer la roue chacun de son côté en
pensant faire mieux que le voisin. Je suppose que beaucoup en ont eu
dans leur entourage professionnel. D'après le peu que j'ai vu de tes
contrôles sur ton site, ton job est beaucoup plus spécialisé et n'est
pas trop concerné par une concurrence alignant de l'artillerie lourde.
Ce n'est pas exactement le cas du collègue qui prétendait faire la nique
à OpenGL.

Bref, ma comparaison ne te visait en rien et je te dois des excuses pour
cette boulette.

A tout hasard, t'aurais pas un avis ou un retour d'expérience sur
wxWidgets ?

Vincent Burel

20/09/2007 à 23:19

"Bertrand Lenoir-Welter" <bertrand-dot-2007-at-galaad-dot-net> wrote in
message news:46f2d789$0$25937$

Vincent Burel :
>
> Sympa ! :-)
> Pour info je ne fais pas de 3D.

Argh ! Désolé Vincent, je me suis mal exprimé.

no-problemo, j'ai bien compris ce que tu voulais dire et je suis assez
d'accord.
mais bon, y'a tellement peu de discussion sur ce forum... que je me suis
dit, "tiens je vais répondre" :-)

A tout hasard, t'aurais pas un avis ou un retour d'expérience sur
wxWidgets ?

et non, j'ai pas essayé, j'ai même pas eu le temps de me pencher sur QT...
alors wxWidgets... Il faut dire qu'avec un un CreateWindow je fais ce que je
veux donc ca m'encourage pas ...

VB

Cyrille Szymanski

21/09/2007 à 00:31

Bertrand Lenoir-Welter <bertrand-dot-2007-at-galaad-dot-net> wrote in
news:46f2a43d$0$27375$:

Certes, mais je cherche juste une librairie suffisante pour fournir
l'essentiel de l'appli - et très éventuellement permettre un portage
sous d'autres cieux. La question pour moi n'est pas entre wxWidgets et
tailler moi-même la piste à la machette, mais entre wxWidgets et MFC
ou autre équivalent. Je suis pas un fan des MFC et .NET n'apporte rien
pour ce que j'ai à faire, surtout que je tiens à rester en C++.

Ce que j'aime le plus c'est que c'est un des rares frameworks qui prévoit
que tu puisses détourner les structures internes. Sous Windows tu peux
par exemple récupérer les HWND des fenêtres pour les manipuler
directement. Bien sûr, utiliser du "platform-specific code" te fait
perdre en portabilité mais au moins c'est supporté sans devoir faire
d'acrobaties.

Par contre côté performance comme l'a dit AMcD c'est pas tout à fait ça,
la gestion des RTTI et des exceptions est pas géniale non plus. Ce dont
je ne suis pas fan c'est de devoir sous classer les objets pour
implémenter le comportement. Ensuite il souffre de toutes les limitations
du C++ (des versions .net apparaîssent, ça va peut-être changer) et il
lui manque des petites choses qui simplifient la vie comme un éditeur de
boîte de dialogue.

Mais dans son genre ce toolkit est plutôt bien foutu et relativement
complet.

Je m'en sers depuis quelques années déjà. Ça m'intéresse que tu fasses un
retour d'expérience si tu décides de le tester. Tu peux aussi regarder QT
ou Win32GUI.

--
Cyrille Szymanski

Sylvain

21/09/2007 à 02:24

Bertrand Lenoir-Welter wrote on 20/09/2007 18:48:

Bref, je pose la question autrement pour toi et Vincent

seulement ?

si vous deviez
prendre une encapsulation C++ de l'API sous peine de mort dans d'atroces
souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

non, ni MFC, et encore moins de truc (pas) .net

à l'époque pré-windows de Borland j'utilisais bcp BP + TV, plus que je
n'ai utilisé ensuite BC & OWL dont j'ai détesté l'architecture globale.

à cette époque donc, Turbo Vision m'était très adapté car j'avais
construit un éditeur visuel de ressources (dialog et menu); les outils
permettant la conception même de l'IU me paraissent encore aujourd'hui
plus importante que telle finesse interne (nb de param ou facilité de
surcharge) simplement parce que si ce "dessin" de l'UI est déjà pénible,
le reste risque de ne pas le contrebalancer - or tu ne donnes pas tes
contraintes sur ce point, si tes composants (voire UI globale) sont
suffisamment métiers pour être de toute façon 100% en code, le point
n'est pas pertinent, mais si une partie de cette UI reste classique ...

so ? pour ma part, j'ai également une lib. perso d'encapsulation C++ de
l'API graphique Win32, je n'ai jamais eu le temps de me réécrire un
'resedit' associé mais un simple petit générateur de code que je relis
très bien étant en terrain connu.

Sylvain.

Arnold McDonald

21/09/2007 à 04:16

> Bref, je pose la question autrement pour toi et Vincent : si vous deviez
prendre une encapsulation C++ de l'API sous peine de mort dans d'atroces
souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

À choisir je prendrais wxWidgets. Cyrille a bien résumé le truc. Bon, Qt,
quand je l'avais testé, c'était sympa aussi, meilleure doc il me semble,
mais franchement entre les deux c'était kif-kif ! De mémoire il y avait des
restrictions de licence avec Qt, sans doute disparues aujourd'hui. Par
contre un peu plus de doc et de communauté en français pour Qt peut être...
De toutes ces librairies testées, Qt et wx étaient les meilleures toutefois.
Mais je pense que choisir entre l'une et l'autre est vraiment affaire de
goût perso.

Et puis bon, vu que je suis revenu à la prog SDK-like :-).

PS : je disparais quelques semaines trollez pas sans moi !

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Bertrand Lenoir-Welter

21/09/2007 à 10:11

Vincent Burel :

mais bon, y'a tellement peu de discussion sur ce forum... que je me suis
dit, "tiens je vais répondre" :-)

Salopiot !

J'me disais déjà que j'avais une fois de plus débordé. J'en ai pas dormi
de la nuit !

et non, j'ai pas essayé, j'ai même pas eu le temps de me pencher sur QT...
alors wxWidgets... Il faut dire qu'avec un un CreateWindow je fais ce que je
veux donc ca m'encourage pas ...

11 arguments ! Ca va pas vraiment dans le sens de la plaidoirie
d'Arnold, ça...

Sylvain

21/09/2007 à 11:27

Arnold McDonald wrote on 21/09/2007 04:16:

Bref, je pose la question autrement pour toi et Vincent : si vous
deviez prendre une encapsulation C++ de l'API sous peine de mort dans
d'atroces souffrances, prendriez-vous wxWidgets ou non, et pourquoi ?

À choisir je prendrais wxWidgets. [...]

Bertrand n'a pas indiqué si le projet tournait sous Windows uniquement
ou s'il devait être porté sous X11, etc.

wx est un grand beau projet mais se fader des libs multi-languages,
multi-OS pour dessiner un bouton ou 2 sous Win32 seul est peut être un
investissement couteux, non ?...

à choisir j'opterais pour la WTL.

Sylvain.

wxWidgets, avantages et inconvénients

10 réponses

Veuillez sélectionner un problème