Mais je t'avoue que les sizer/panel m'on donner bcps de fil a retordre :/.
Mais cela permet un control absolue sur les tabulations interchamps par exemple :).
Une fenetre bien decrite, peut eviter de se faire a la mano les binds de tabulations pour des ensemble de widgets.
C'est a dire, si tu veux que le curseur fasse un parcours de widget bien definie lors de la tabulation, une bonne definition des sizers/panel peut automatisé cela sans rajouter une ligne de code pour definir le bind et la prochaine position du curseur.
C'est le seul interet pour l'instant que je vois des panel, les sizers eux autoadapte la position/taille des widget en fonction de la taille de la fenetre (agrandi,retreci,et maitriser les elements qui vont s'expand).
Pour ce qui est du TK je suis relativement mitigé, comme par le fait de pas avoir par defaut le moyen de binder l'evenement OnChange sur les PMW ComboBox.
Et surtout la position des widget n'est pas exactement la meme quand tu execute ton apllication en TK d'une plateforme a une autre (pour moi c'etait de linux à windows), j'avais les widget qui se chevaucher sur windows et pas sur linux, obliger de changer la position des widget pour compiler d'une plateforme a une autre.
Alors que apres j'ai decouvert le WXWindows et fini les surprises interplateforme (hormis quand je connaissais pas le fait de creer des nouveaux event lors d'un programme multithread, ce qui creer des figes ), mes description de fenetre pour l'instant ( je dis pas qu'il y est pas des exceptions) ont été _respectées_ d'une plateforme a une autre sans aucun probleme mais alors vraiment aucun ( a part sur win32 ou le PNG n'a pas de canal transparent ).
[^] # Re: re
Posté par Sylvain . En réponse au message PyGTK, taille et position des fenêtres. Évalué à 2.
Mais je t'avoue que les sizer/panel m'on donner bcps de fil a retordre :/.
Mais cela permet un control absolue sur les tabulations interchamps par exemple :).
Une fenetre bien decrite, peut eviter de se faire a la mano les binds de tabulations pour des ensemble de widgets.
C'est a dire, si tu veux que le curseur fasse un parcours de widget bien definie lors de la tabulation, une bonne definition des sizers/panel peut automatisé cela sans rajouter une ligne de code pour definir le bind et la prochaine position du curseur.
C'est le seul interet pour l'instant que je vois des panel, les sizers eux autoadapte la position/taille des widget en fonction de la taille de la fenetre (agrandi,retreci,et maitriser les elements qui vont s'expand).
Pour ce qui est du TK je suis relativement mitigé, comme par le fait de pas avoir par defaut le moyen de binder l'evenement OnChange sur les PMW ComboBox.
Et surtout la position des widget n'est pas exactement la meme quand tu execute ton apllication en TK d'une plateforme a une autre (pour moi c'etait de linux à windows), j'avais les widget qui se chevaucher sur windows et pas sur linux, obliger de changer la position des widget pour compiler d'une plateforme a une autre.
Alors que apres j'ai decouvert le WXWindows et fini les surprises interplateforme (hormis quand je connaissais pas le fait de creer des nouveaux event lors d'un programme multithread, ce qui creer des figes ), mes description de fenetre pour l'instant ( je dis pas qu'il y est pas des exceptions) ont été _respectées_ d'une plateforme a une autre sans aucun probleme mais alors vraiment aucun ( a part sur win32 ou le PNG n'a pas de canal transparent ).