[Debat] C++ et IHM

**MatRem** · 22/08/2007, 22h52

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

**poukill** · 22/08/2007, 23h01

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** · 22/08/2007, 23h04

Envoyé par poukill

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.

Envoyé par poukill

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** · 22/08/2007, 23h04

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** · 22/08/2007, 23h13

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** · 22/08/2007, 23h18

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** · 23/08/2007, 10h15

Envoyé par Miles

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** · 23/08/2007, 10h20

Envoyé par Miles

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.

Envoyé par Alp

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

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

Envoyé par Alp

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** · 23/08/2007, 10h20

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** · 23/08/2007, 10h28

Envoyé par Miles

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** · 23/08/2007, 10h32

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** · 23/08/2007, 10h51

Envoyé par Miles

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** · 23/08/2007, 10h58

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** · 23/08/2007, 11h05

Envoyé par Miles

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** · 23/08/2007, 11h11

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** · 23/08/2007, 11h33

Envoyé par Davidbrcz

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

Oui, j'ai vu ça.

Envoyé par Davidbrcz

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

C'est de la mauvaise foi ...

Envoyé par Davidbrcz

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** · 23/08/2007, 12h00

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** · 23/08/2007, 12h06

( 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** · 23/08/2007, 12h11

Envoyé par Davidbrcz

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)

Envoyé par Alp

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** · 23/08/2007, 12h15

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

[Debat] C++ et IHM

C++

Discussions similaires

Partager

Partager