Python + Qt - Page 1

Ça arrête pas de crasher !

Apparemment, c'est quand on détruit les objets C++, mais ça crashe de façon totalement aléatoire quand on quitte, donc dur de savoir quel objet exactement pose problème quand le seul message est « segmentation fault »…

A priori, c'est que je ne mets pas le bon objet parent quand je crée un widget, mais je n'en sais pas plus…
Au final, j'ai un peu l'impression que ça rend Python + Qt totalement inutilisable si on veut faire un projet un peu complexe Même si je comprends comment corriger correctement sur mon petit exemple, il y aura toujours le risque d'avoir ce genre de bugs, mais avec des bugs vraiment impossibles à reproduire et à débugguer :/

Du coup, je ne sais pas trop ce que je pourrais choisir comme techno d'interface graphique, je sens que ça va être du web (au moins, ça ne crashe pas sans raison)

flanker (./1) :
je sens que ça va être du web (au moins, ça ne crashe pas sans raison)

Ha bon ?
pourtant ça arrive d'avoir du crash/freeze/non chargement d'images/ralentissement de navigateur web alors que tout marche très bien en prenant un autre.

En tout cas, ça ne sera pas de ma faute

En Qt pur C++, il ne faut habituellement pas delete toi-même les objets que tu as attachés à un parent.

Même avec des frameworks qui ont des propriétés de couche d'abstraction, et même en n'utilisant que les browsers modernes, le développement Web a ses bizarreries et disparités entre browsers, ouais
Suivant ce que tu cherches à faire, QtWebkit, et le Qt Web Engine à venir, peuvent être envisageables. Ca permet de garder du C++ pour les calculs, et de lui donner un bon frontal Web, avec à peu près tous les frameworks JS que tu veux.

J'allais le dire. De toute façon, les bugs sont toujours entre la chaise et l'écran.

</utile>

Lionel Debroux (./4) :
En Qt pur C++, il ne faut habituellement pas delete toi-même les objets que tu as attachés à un parent.

Ouep, j'ai vu ça. Mais en Python, tu n'as normalement pas à t'en préoccuper… Du coup, la cohabitation se passe assez mal

Même avec des frameworks qui ont des propriétés de couche d'abstraction, et même en n'utilisant que les browsers modernes, le développement Web a ses bizarreries et disparités entre browsers, ouais

ouep, mais au final ça ne marche pas si mal quand on fait des trucs pas trop compliqués (et surtout quand on passe par des frameworks)

Suivant ce que tu cherches à faire, QtWebkit, et le Qt Web Engine à venir, peuvent être envisageables. Ca permet de garder du C++ pour les calculs, et de lui donner un bon frontal Web, avec à peu près tous les frameworks JS que tu veux.

Pour la partie calcul, ça ne sera ni C++, ni Python ^^

question con, as tu fais des essais avec des exemples, et est ce qu'ils plantent?

parce que certains collègues ont déja livré des applis avec pyqt et ils ont pas eu tous ces problèmes.

D'un rapport seulement lointain…
PyQT, l'idée me plait bien. Python est un langage pas mal pour faire des choses d'assez haut niveau, et un GUI est l'exemple parfait de truc où la souplesse et la concision priment sur les performances. Je me mets une note de jouer avec, le jour où je refais des applis desktop.

• spectras dans sa période Django.

squalyl (./7) :
question con, as tu fais des essais avec des exemples, et est ce qu'ils plantent?

parce que certains collègues ont déja livré des applis avec pyqt et ils ont pas eu tous ces problèmes.

En fait, j'ai pas mal d'expérience avec PyQt + Python 2 et très peu de crash (voire aucun avec les dernières versions de PyQt).

Par contre, j'ai trouvé assez pénible à utiliser (plein de code à écrire), donc j'ai commencé à écrire une lib de plus haut niveau avec PySide + Python 3 pour faciliter la vie. Et là, j'ai un peu plus de crash, ce qui rend la chose assez pénible.




Pour ma lib, si j'ai besoin d'une boîte de dialogue, j'écris simplement les champs que je veux et leurs types.
Si je veux une fenêtre avec une barre de menu et une toolbar, je mets un décorateur avant les fonctions à appeler.
Pour les préférences, j'écris une classe avec les valeurs demandées (genre derniers fichiers ouverts), avec des garanties sur l'existence et la validité de ces valeurs.
class SampleForm(Form): str_value = CharField(default='my_str', verbose_name='String value') int_value = IntegerField(default=42, required=True, verbose_name='Integer value') filename = FilepathField(verbose_name='A file path') class SampleBaseWindows(BaseMainWindow): @menu_item(menu='TestMenu', verbose_name='TestMenuItem') @toolbar_item(icon='qthelpers:resources/icons/ToolbarDocumentsFolderIcon.png') def test_menu_1(self): print('test_menu_1') def test_1(self): SampleFormDialog.get_values() # dictionnaire {'int_value': 42, 'filename': None, 'str_value': 'my_str'}

Oula, ça dépasse mon niveau de python

oué, mais rien qu'à ce que dit flanker, ça a l'air excitant ! Par contre, le boulot doit bien se cacher quelque part quand même, non, t'as dû pas mal bosser quand t'as fait ta lib, une fenêtre ça s'écrit quand même pas en 3 lignes ^^

Folco (./11) :
oué, mais rien qu'à ce que dit flanker, ça a l'air excitant ! Par contre, le boulot doit bien se cacher quelque part quand même, non, t'as dû pas mal bosser quand t'as fait ta lib, une fenêtre ça s'écrit quand même pas en 3 lignes ^^

Oui, mais justement, je mets tout le code un peu chiant et répétitif au même endroit. Tout le code Qt également, mais ça passe manifestement mal
Au final, il n'y a pas tant de code que ça, mais c'est du Python un peu taquin

Ze Python z'est fraiment une tuile!

Un féritaple Python-tuile!

elle est pas jeune celle là ^^

Au final, j'ai réussi à contourner le problème, j'assigne le même objet parent à tous mes widgets :/ c'est moche, mais au moins ça fonctionne.

Et rebelotte, j'ai perdu pas mal de temps parce que j'avais déclaré une méthode en statique, qui causait un segfault à la sortie (et le seul indice que j'avais, c'était qu'il était causé par ~QObject ). Reste à comprendre pourquoi…

Je pens que ton Qt a peur des serpents, c'est tout