Discussion :

[MatRem]

Et gtkmm... qu'en pensez vous?
Personnelement je trouve son API agréablement objet.

[poukill]

Que voulez-vous dire au sujet de WxWidget? C'est moins "propre"?

Et Python, vraiment intéressant? On peut l'interfacer avec du C++?

[Alp]

Que voulez-vous dire au sujet de WxWidget? C'est moins "propre"?

Oui, et bien moins abouti, bien moins fourni que Qt. Pas de designer officiel, et j'en passe.

Et Python, vraiment intéressant? On peut l'interfacer avec du C++?

Python est vraiment sympa
Regarde du côté de Boost.Python

[Matthieu Brucher]

La pompe à message est par exemple entièrement crée sous forme de macro. Avec Qt, comme il s'agit des signaux et slots, c'est plu agréable à utiliser.
Sous Python, j'utilise en revanche wxPython à cause de la licence et du fait que pour le coup, la gestion des évènements est très bien faite. pyQt est bien la doc est trop vieille (et il n'est maintenu que par une seule personne qui s'occupe aussi de SIP, un concurrent de SWIG écrit pour Qt).

[poukill]

J'utilise depuis 6 mois WxWidget, je trouve ça pas aml... Je n'ai jamais utilisé Qt, donc je peux pas juger, je suis obligé de vous faire confiance !

Alp, je regarderai demain Boost.Python. Mais on peut sérieusement envisager de construire un logiciel entier (assez gros projet), en faisant l'interface IHM sous Python, avec la partie algo en C++?
Quelqu'un d'entre vous l'a t-il déjà fait?
J'ai entendu bcp de bien sur Python, il est temps que je m'y mette !

[Matthieu Brucher]

Le gros point négatif pour l'instant de Boost.Python et de SWIG, son collègue plus versatile et moins spécialisé, c'est qu'il n'y a pas de tuto sur le net vraiment complet. D'ailleurs, c'est compliqué de gérer les types natifs Python et C++ de concert, donc encore moins les types utilisateurs.

Mais ça se fait tout de même

[yan]

Le gros point négatif pour l'instant de Boost.Python et de SWIG, son collègue plus versatile et moins spécialisé, c'est qu'il n'y a pas de tuto sur le net vraiment complet. D'ailleurs, c'est compliqué de gérer les types natifs Python et C++ de concert, donc encore moins les types utilisateurs.

Mais ça se fait tout de même

J'ai regarder rapidement boost.python, et j'ai compris que c'était pour générer un code utilisable par python avec bjam...

Donc si j'ai bien compris, c'est pour utiliser du C++ dans du python (et non l'inverse), et faut donc utiliser un intermédiaire (bjam) comme Qt (ui / moc).
es que je me trompe?

[Davidbrcz]

La pompe à message est par exemple entièrement crée sous forme de macro. Avec Qt, comme il s'agit des signaux et slots, c'est plu agréable à utiliser.

La Doc recomande les macros , mais on peut utiliser Connect si on le souhaite.

Oui, et bien moins abouti, bien moins fourni que Qt.

Je ne vois pas où wx est moins abouti que Qt.

Pas de designer officiel, et j'en passe.

Pas de designer officiel , pas un mais plusieurs :
http://www.wxwidgets.org/wiki/index....on_Development
C'est ca la possibilité du choix. Avec Qt , c'est Qt designer ou rien.

[Matthieu Brucher]

Oui, tu te trompes

On peut faire les deux, C++ dans Python et Python dans C++. Et bjam, c'est un cmake/Scons/automake -like, rien d'autre. Il n'y a pas vraiment de préprocessing ni rien (contrairement à SWIG qui génère un wrapper qui devra être compilé après)

[yan]

Oui, tu te trompes

On peut faire les deux, C++ dans Python et Python dans C++. Et bjam, c'est un cmake/Scons/automake -like, rien d'autre. Il n'y a pas vraiment de préprocessing ni rien (contrairement à SWIG qui génère un wrapper qui devra être compilé après)

Ok merci (j'ai vu aprés que python vers C++ est possible).

Du coup une question, es compliqué de scripter un code C++ en utilisant python avec boost.python?

Par contre dans le hello word il utilise bjam pour gener un hello.pyd... Ce n'est pas une sorte de préprocessing?

[Matthieu Brucher]

Non, en fait il faut créer une DLL, pour python 2.5 avec Windows, elle doit avoir pyd comme extension.
Scripter un code C++ depuis Python est très simple à faire à partir du moment où les données C++ (autres qu'entier, flottant) ne remontent pas vers Python. Avec SWIG et Boost.Python, un module Python sera créé (il faut tout de même écrire à un moment ce qui sera wrappé et ce qui ne le sera pas) dans lequel il y aura les fonctions qu'il sera facile d'appeler. C'est quelque chose du style que Civilization 4 fait.

[yan]

Scripter un code C++ depuis Python est très simple à faire à partir du moment où les données C++ (autres qu'entier, flottant) ne remontent pas vers Python.

ca limite pas mal les possibilités non?
Du coup faut une sorte de class interface qui contiens tout ce que python pourra faire avec le code fournie?
Par exemple si python fait une interface qui va comparer deux images. Le code de chargement et de comparaison sont dans une lib C++, faudra créer une class qui va interfacer ce que va faire l'ihm?

[Matthieu Brucher]

Je n'ai pas dit que c'était impossible, j'ai dit que ce n'était pas aussi simple que simplement dire que la fonction serait accessible depuis Python. Par exemple, si on prend les tableaux de Numpy, il faut dire en C++ qu'on va utiliser le pointeur du tableau et là, soit il n'est valable que pendant le temps de l'appel de la fonction, soit on enregistre le fait qu'on ait une référence supplémentaire, mais il faut aussi interfacer le code C++ pour qu'il accepte un tel tableau.
C'est là où ce n'est pas aussi simple.

Mais par exemple, si tout est en C++, y compris la lecture d'une image, on lit deux images et on récupère 2 objets images et on les réinjectes dans un filtre par exemple, et ça se fera très bien. On ne pourra juste rien modifier directement en Python.

[yan]

Je n'ai pas dit que c'était impossible, j'ai dit que ce n'était pas aussi simple que simplement dire que la fonction serait accessible depuis Python. Par exemple, si on prend les tableaux de Numpy, il faut dire en C++ qu'on va utiliser le pointeur du tableau et là, soit il n'est valable que pendant le temps de l'appel de la fonction, soit on enregistre le fait qu'on ait une référence supplémentaire, mais il faut aussi interfacer le code C++ pour qu'il accepte un tel tableau.
C'est là où ce n'est pas aussi simple.

Mais par exemple, si tout est en C++, y compris la lecture d'une image, on lit deux images et on récupère 2 objets images et on les réinjectes dans un filtre par exemple, et ça se fera très bien. On ne pourra juste rien modifier directement en Python.

Cool merci pour les précisions.
Donc faire une ihm en python avec un code C++ pose les même problème... Faut concevoir une interface qui sera utilisé par python la plus indépendante que possible

[Matthieu Brucher]

Comme dit, pas forcément. tout dépend ce que tu veux mettre dans ton IHM. Si tu as des widgets d'affichage, tu peux très bien les laisser en C++ et y accéder de manière transparente en Python sans savoir si ce sont des patates ou des carottes.

[Alp]

La Doc recomande les macros , mais on peut utiliser Connect si on le souhaite.

Oui, j'ai vu ça.

Je ne vois pas où wx est moins abouti que Qt.

C'est de la mauvaise foi ...

Pas de designer officiel , pas un mais plusieurs :
http://www.wxwidgets.org/wiki/index....on_Development
C'est ca la possibilité du choix. Avec Qt , c'est Qt designer ou rien.

Oui mais Qt Designer est quand même totalement suffisant...
Choisir c'est bien beau, mais bon ... Je trouve Qt un cran au-dessus de wx.
Pourtant j'ai beaucoup utilisé wx, mais je préfère Qt, vraiment.

[Davidbrcz]

C'est de la mauvaise foi ...

Non ,je le pense sincérement.
Pour ce que j'ai utilsé de Qt ('petite' application 'normale') j'ai toujours trouvé un équivalent chez wx.
Après il est vrai que je n'ai ni exploré la doc de Qt en profondeur ni celle de wx pour trouver leurs composants 'exotique'.

Oui mais Qt Designer est quand même totalement suffisant...
Choisir c'est bien beau, mais bon ... Je trouve Qt un cran au-dessus de wx.
Pourtant j'ai beaucoup utilisé wx, mais je préfère Qt, vraiment.

Question de gout.

[Alp]

( Il y a une faute de frappe dans ta "Localisation" David, oublié un r à France )

Oui bien sûr c'est une question de goût.

Mais Qt a un aspect bien plus professionnel, non ?

[Matthieu Brucher]

Pour ce que j'ai utilsé de Qt ('petite' application 'normale') j'ai toujours trouvé un équivalent chez wx.
Après il est vrai que je n'ai ni exploré la doc de Qt en profondeur ni celle de wx.

Et inversement
Mais Qt propose tout de même plus de versatilité, rien que pour les styles par exemple, que wx (qui reste cantonné à GTK+ et au feeling Windows sous... Windows)

Mais Qt a un aspect bien plus professionnel, non ?

Je ne dirais pas plus professionnel mais plus architecturé (séparation des bibliothèques, meilleure orientation objet, ...)
Mais oui, c'est une histoire de goût et d'approche du C++ (si on vient du C, on appréciera sans doute plus wxWidgets et si on est plus C++ dur, peut-être qu'ons era plus Qt).

[Alp]

Oui, je pense qu'il y a du vrai dans ce que tu dis.