2009-05-27 5 views
1

Les tutoriels que j'ai trouvés sur WxPython utilisent tous des exemples de Linux, mais il semble y avoir des différences dans certains détails. Par exemple, dans Windows, un panneau derrière les widgets est obligatoire pour afficher correctement l'arrière-plan. En outre, certains exemples qui semblent bien dans les didacticiels ne fonctionnent pas dans mon ordinateur. Alors, savez-vous quelles sont les différences importantes, ou peut-être un bon tutoriel qui se concentre sur Windows?Différences WxPython entre Windows et Linux

EDIT: Je viens de me rappeler ceci: Quelqu'un sait-il pourquoi quand wx.App une méthode sous-classement OnInit() est nécessaire, plutôt que plus logique __init__()?

Répondre

2

J'ai remarqué des particularités bizarres dans une petite interface graphique que j'ai écrite il y a quelque temps, mais cela fait longtemps que je n'ai pas essayé les spécificités sont un souvenir plutôt lointain. Avez-vous des exemples spécifiques qui échouent? Peut-être que nous pouvons les améliorer et réparer les bugs? Avez-vous essayé the official wxPython tutorials? ... ou étiez-vous après quelque chose de plus spécifique?

r.e. votre modification - Vous devez utiliser OnInit() car vous sous-classes wx.App (c'est-à-dire une exigence pour wxWidgets plutôt que Python) et l'implémentation de wxPython est dans la mesure du possible, juste un wrapper pour wxWidgets.

[Éditer] Zetcode a a fairly lengthy tutorial on wxPython. Je n'ai pas parcouru tout ça moi-même, mais ça pourrait être utile?

La documentation wxWidgets::wxApp::OnInit() est assez claire:

doit être fourni par l'application, et créera généralement la fenêtre principale de l'application, le cas échéant appeler wxApp :: SetTopWindow. Vous pouvez utiliser OnExit pour nettoyer tout élément initialisé ici, à condition que la fonction renvoie true.

Si wxWidgets n'a pas fourni une interface commune, vous auriez alors à faire des choses différentes en C++ (en utilisant un constructeur) par rapport à Python __init__(self,...). L'utilisation d'une initialisation indépendante du langage permet aux ports wxWidgets de se ressembler, ce qui devrait être une bonne chose. :-)

+0

Je comprends cela, mais puisque chaque langage orienté objet a des constructeurs, pourquoi exiger un OnInit()? – Javier

+0

BTW, ce tutoriel est très court. – Javier

+0

C'est l'un des tutoriels dont je parlais, mais merci quand même. C'est toujours utile. – Javier

0

EDIT: Je viens de me rappeler ceci: Quelqu'un sait-il pourquoi quand wx.App une méthode sous-classement OnInit() est nécessaire, plutôt que plus logique __init__()?

J'utilise OnInit() pour la symétrie: il y a aussi une méthode OnExit(). Editer: Je peux me tromper, mais je ne pense pas que l'utilisation de OnInit() est requise.

+1

Les docs suggèrent que c'est _is_ requis ... –

0

Je trouve un certain nombre de petites différences, mais je ne me souviens pas de toutes. Voici deux:

1) La mise en page peut être légèrement différente, par exemple, provoquant des choses à ne pas tenir complètement dans la fenêtre dans un système d'exploitation lorsque le faire dans l'autre.Je n'ai pas étudié les raisons de cela, mais cela arrive le plus souvent lorsque j'utilise des positions plutôt que des caleurs pour arranger les choses.

2) Je dois explicitement appeler Refresh plus dans Windows. Par exemple, si vous placez un panneau par-dessus un autre, vous ne le verrez pas dans le panneau supérieur de Windows tant que vous n'aurez pas appelé Actualiser. En général, j'écris des applications sous Linux et je les exécute sous Windows, et les choses fonctionnent assez bien, donc c'est une approche raisonnable, mais il est rare pour moi que quelque chose fonctionne parfaitement après un changement de système d'exploitation.

+0

La documentation indique explicitement qu'un cadre ne contiendra qu'un seul widget. Pour en ajouter d'autres, vous devez ajouter un panneau. En ce qui concerne la mise en page, il semble que la plupart des API de fenêtrage «récentes» recommandent d'utiliser des calibreurs pour mettre en forme de manière quasi automatique vos formulaires. Une fois que vous vous êtes habitué à l'idée, c'est en fait très pratique. Cela signifie moins de travail pour prendre en charge la vaste gamme de tailles d'écran que les utilisateurs sont susceptibles d'avoir. Quelle que soit la taille pour laquelle vous effectuez l'optimisation, la plupart des utilisateurs utilisent des tailles de police différentes et dimensionnent leurs fenêtres différemment, de sorte que votre travail soigné finit par être gaspillé. – CyberFonic