Héritant de Cadre ou non dans un Tkinter application

J'ai vu deux méthodes de base pour la configuration d'un tkinter programme. Est-il une raison de préférer l'un à l'autre?

from Tkinter import *

class Application():
    def __init__(self, root, title):
        self.root = root
        self.root.title(title) 

        self.label = Label(self.root, text='Hello')
        self.label.grid(row=0, column=0)  

root = Tk()
app = Application(root, 'Sample App')
root.mainloop()

from Tkinter import *

class Application(Frame):
    def __init__(self, title, master=None):
        Frame.__init__(self, master)
        self.grid()
        self.master.title(title) 

        self.label = Label(self, text='Hello')
        self.label.grid(row=0, column=0) 

app = Application('Sample App')
app.mainloop()

InformationsquelleAutor foosion | 2011-09-04

python tkinter

26

L'option que je préfère* est pour hériter de la classe des Savoirs traditionnels. Je pense qu'il est plus raisonnable de choix depuis la fenêtre n'est, en effet, votre application. Héritant de Frame ne pas faire plus de sens pour moi alors hériter de Button ou Canvas ou Label. Puisque vous ne pouvez avoir qu'une seule racine, il est logique que c'est ce que vous héritez de.

Je pense aussi que ça rend le code plus lisible si vous ne l'importation comme import Tkinter as tk plutôt que from Tkinter import *. Tous vos appels puis mentionner explicitement le tk module. Je ne le recommande pas pour tous les modules, mais pour moi, il fait sens avec Tkinter.

Par exemple:
```
import Tkinter as tk

class SampleApp(tk.Tk):
    def __init__(self, *args, **kwargs):
        tk.Tk.__init__(self, *args, **kwargs)
        self.label = tk.Label(text="Hello, world")
        self.label.pack(padx=10, pady=10)

app = SampleApp()
app.mainloop()
```
* Remarque: depuis l'origine de l'écriture de cette réponse, j'ai changé ma position. Maintenant, je préfère hériter de Frame plutôt que Tk. Il n'y a pas de réel avantage, d'une façon ou l'autre, c'est plus d'un choix philosophique qu'autre chose. Peu importe, je crois que si vous héritez de Frame ou Tk, je pense que quel que soit le choix est mieux que le premier exemple dans le code qui hérite de rien.

Un léger avantage héritant de Frame a plus de Tk est dans le cas où vous souhaitez que votre application pour prendre en charge plusieurs fenêtres identiques. Dans ce cas, héritant de Frame vous permet de créer la première fenêtre comme un enfant de la racine, et windows supplémentaires comme les enfants des instances de Toplevel. Cependant, j'ai vu très peu de programmes qui jamais ont besoin pour ce faire.

Pour plus d'informations sur la façon dont je pense que Tkinter programmes doivent être structurés, voir ma réponse à la question Python Tkinter, la structure du programme.
- Quel est l'avantage de l'héritage de Savoirs traditionnels plutôt que de simplement racine = tk() comme dans mon premier exemple ci-dessus? N'héritant de Savoirs traditionnels vous donner le même "embellissement" de la flexibilité comme héritant de Cadre?
- dans le module import * me font toujours nerveux, mais il est si commun pour Tkinter, que j'ai eu sur elle. Est-il un risque réel? Je ne suis pas tellement inquiet à propos de la lisibilité comme certains conflits de nom.
- Il n'y a aucun avantage ni inconvénient. Vous avez toujours exactement le même "embellissement" de la flexibilité. Vous avez toujours l'option de l'incorporation d'une image, si vous voulez obtenir un particulier l'effet frontière. Je ne comprends pas le raisonnement d'avoir votre application principale objet d'être un enfant d'un autre objet. À partir d'un point de vue logique, l'objet d'application devrait être la partie la plus haute de l'objet dans une hiérarchie.
- le risque de "from tkinter import *" est le même que pour n'importe quel autre module. Étant donné que tkinter, les classes ont très des noms génériques (Bouton, Label, etc), il serait facile de accidentellement créer des classes de même nom et de provoquer des collisions de noms.
- Changer import Tkinter pour importer des Tix semble fonctionner sans autres modifications lors de l'utilisation de Tix widgets (par exemple, ScrolledListBox) et l'héritage de Savoirs traditionnels (ou root = Tk()), mais pas lorsque vous héritez de l'Image. Si oui, ce serait un avantage, à l'héritage de Savoirs traditionnels
- Si vous héritez de Savoirs traditionnels, vous pouvez la redimensionner avec soi-même.redimensionnable(Vrai,Faux). Cela ne fonctionne pas si hérite de Frame.
- mais vous pouvez toujours définir la redimensionnable peu sur la fenêtre, il vous suffit d'utiliser root (ou ce que vous appelez) au lieu de self. Cependant, il n'y a presque jamais une bonne raison de faire une fenêtre de taille fixe. Si un utilisateur veut une fenêtre à être plus grandes ou plus petites, qui sommes-nous (comme l'app designer) pour leur dire le contraire? C'est beaucoup mieux (et tout aussi facile) pour la conception de votre application à avoir un bon comportement de redimensionnement.
- vous avez raison, je devrais avoir dit que je l'ai trouvé plus simple lorsque l'héritage de Savoirs traditionnels, parce que j'ai juste l'utilisation de l'auto. Pourquoi est - @Bryan disparaître quand je tape au début d'un commentaire?
- Juste curieux de savoir sur quelle planète de la conception d'un bon comportement de redimensionnement est aussi facile que l'écriture de soi.redimensionnable(False, False). Juste pour le plaisir de l'argument ;p
- Franchement, si vous prenez une approche méthodique pour faire de votre widget de mise en page, le bon comportement de redimensionnement est vraiment facile. Rappelez-vous, le but est d'écrire des logiciels qui répondent aux besoins de la utilisateur, plutôt que de répondre à vos besoins en tant que développeur.
- Bien à mes besoins en tant que développeur pour répondre aux besoins de l'utilisateur, donc je ne pas vraiment comprendre. Comme pour la facilité, c'est comme dire "Aller à la cave pour acheter une bonne bouteille de vin pour votre date est tout aussi facile que d'obtenir une bouteille de Mad Dog 20/20 à partir du magasin du coin - parce que, après tout, c'est votre date de besoins, pas à vos besoins". Ce dernier, bien que de qualité inférieure, semble définitivement plus facile.
- ce n'est que spéculation sans connaître les besoins de l'utilisateur. Le plus souvent, ils sont mieux servis en leur permettant de redimensionner la fenêtre pour répondre à leurs besoins. Ce n'est pas vrai à 100% du temps, mais il est proche. Vous ne pouvez pas toujours contrôler les polices, l'éclairage, la vue, le minimum de l'écran-tous les problèmes qui peuvent potentiellement être contourné en donnant à l'utilisateur un peu de contrôle. Comme pour le vin analogie, c'est assez loin hors de la base. Une meilleure analogie est que vous voulez forcer l'utilisateur à boire à partir d'une très spécifiques de verre, même si elles ont peut pas l'utiliser facilement en raison d'une limitation physique.
- C'est un bon argument et je suppose que je suis vraiment juste accroché sur la sémantique du mot "facile" - pour moi, qui signifie simplement le temps. Il est exact que chaque situation est différente, mais dans un cas où l'utilisateur insiste pour avoir la fenêtre des méthodes finalisé en 30 secondes, et tout ce que vous avez à ce jour est une maquette pour le prototypage, il est beaucoup plus facile de verrouiller les choses à l'endroit où ils sont déjà. Si vous mesurez plus facile par LOC puis, c'est très quantifiables. De façon réaliste, je pense que la LDC est presque vide de sens et je suis d'accord avec tous vos points 😉
- Si vous préférez héritant de Frame, vous devez déplacer cette recommandation vers le haut de votre réponse.
InformationsquelleAutor Bryan Oakley
12

Un Cadre est généralement utilisé comme un la géométrie de maître pour les autres widgets.
Depuis que la demande a généralement de nombreux widgets, vous aurez souvent envie de les contenir dans un Cadre, ou au moins utiliser le Cadre pour ajouter un peu de borderwidth, rembourrage, ou d'autres finesse.

De nombreux exemples extraits que vous pourriez trouver sur le web ne pas utiliser un Cadre parce que
ils veulent juste faire preuve d'une certaine fonction dans le plus court laps de code.

Ainsi, l'utilisation d'une Image si vous en avez besoin, sinon, ne le font pas.

Modifier: je pense que la meilleure façon d'organiser une interface graphique est donnée dans ce Tkinter tutoriel:

simpleApp.py:
```
import Tkinter as tk

class SimpleApp(object):
    def __init__(self, master, **kwargs):
        title=kwargs.pop('title')
        frame=tk.Frame(master, **kwargs)
        frame.pack()
        self.label = tk.Label(frame, text=title)
        self.label.pack(padx=10,pady=10)

if __name__=='__main__':
    root = tk.Tk()
    app = SimpleApp(root,title='Hello, world')
    root.mainloop()
```
C'est principalement comme votre première exemple SimpleApp hérite de object, pas Frame. Je pense que c'est mieux que de sous-classement Frame puisque nous ne sommes pas en remplaçant toute Frame méthodes. Je préfère penser que SimpleApp comme ayant un Frame plutôt que d'être un Frame.

Avoir SimpleApp sous-classe object a un avantage significatif sur les sous-classement tk.Tk, cependant: il le rend facile à intégrer SimpleApp dans un grand app:
```
import simpleApp
import Tkinter as tk

class BigApp(object):
    def __init__(self, master, **kwargs):
        title=kwargs.pop('title')
        frame=tk.Frame(master, **kwargs)
        frame.pack()
        self.simple = simpleApp.SimpleApp(frame,title=title)
        frame.pack(padx=10, pady=10)
        self.simple2 = simpleApp.SimpleApp(frame,title=title)    
        frame.pack()

if __name__=='__main__':
    root = tk.Tk()
    app = BigApp(root,title='Hello, world')
    root.mainloop()
```
Ainsi, simpleApp.py peut être un script autonome ainsi qu'une importables module.
Si vous essayez cela avec SimpleApp héritant de tk.Tk, vous vous retrouvez avec des extra indésirable windows.
- Je peux utiliser la grille pour des mises en page complexes dans les deux versions. Est la différence que je peux faire un joli frontière avec le Cadre?
- Le Cadre docs montrer un peu d'options de configuration (oui, la plupart portant sur les frontières) cette Image qui ne peut être fait avec la grille. L'utilisation de l'Image si vous avez besoin d'un de ceux qui, autrement, ne le font pas.
- c'est la conclusion que l'on pourrait aussi bien utiliser un Cadre général, car il n'y a pas de coût supplémentaire, il offre un peu plus d'options et il n'est pas utile de réfléchir à la voie à suivre pour chaque programme?
- Je pense que c'est raisonnable.
- borderwidth=10, relief=SUNKEN est plutôt laid, de l'OMI
- Hey, c'était mon meilleur design de la journée 🙂
- Il n'y a pas de mal à hériter de Frame, mais ne sont pas beaucoup de sens. Toutes les images doivent avoir un parent, alors pourquoi ne pas mettre votre application à hériter de la mère de tous les widgets (ie: la fenêtre racine)?
- Voir mon commentaire ci-dessous sur Tix
- Aussi, mon commentaire à propos de redimensionnable. Il ne semble y avoir certaines choses que le travail lorsque vous héritez de Savoirs traditionnels qui ne fonctionnent pas lorsque vous héritez de l'Image
- il n'y a rien qui fonctionne ou ne fonctionne pas, tout ce que vous pouvez faire en héritant de l'Image vous pouvez le faire en héritant de Savoirs traditionnels. La seule différence est dans la façon dont vous faites référence à la fenêtre principale (par exemple, self contre root ou master ou ce que vous choisissez).
- J'ai essayé l'exemple et changé l'héritage tk.Tk et sans supplément de windows ne s'affiche.
InformationsquelleAutor unutbu

Il y a peut être un avantage pour le réglage de votre haut niveau objet d'hériter de Tk au lieu de Frame. L'avantage survient lorsque vous avez élément dynamique à votre interface graphique, par exemple un Label dont le contenu que vous souhaitez définir un textvariable=foo au lieu de text= 'Label text'.

Dans ce cas, il est très utile d'utiliser le Tkinter.DoubleVar, Tkinter.IntVar, et Tkinter.StringVar objets pour stocker les données, depuis l'interface graphique se met à jour automatiquement à chaque fois que ces objets sont définis. Toutefois, pour utiliser ces objets, vous devez spécifier leur maître comme la racine Tkinter.Tk() instance en cours d'exécution. C'est plus facile si vous l'avez explicitement faire de votre objet principal d'être une sous-classe de Tkinter.Tk, alors que de générer des images et des widgets, de sorte que vous pouvez passer le long de la Tk instance et de définir vos variables correctement.

Voici un petit programme d'exemple pour illustrer l'idée.

import Tkinter as tk       
class Tkclass(tk.Tk):
def __init__(self):
tk.Tk.__init__(self)
app=Application(self)
app.master.title("Animal to Meat")
app.mainloop()
class Application(tk.Frame):    
def __init__(self, parent):
tk.Frame.__init__(self, parent)
self.grid(sticky=tk.N+tk.S+tk.E+tk.W)
self.meatvar = tk.StringVar(master=parent)
self.meatvar.set("Meat?")
self.createWidgets()
def createWidgets(self):
top=self.winfo_toplevel()                
top.rowconfigure(0, weight=1)            
top.columnconfigure(0, weight=1)         
self.rowconfigure(0, weight=1)           
self.columnconfigure(0, weight=1) 
self.columnconfigure(1, weight=1)  
self.columnconfigure(2, weight=1)  
self.columnconfigure(3, weight=1)  
self.cowButton = tk.Button(self, text='Cow', command=self.setBeef)
self.cowButton.grid(row=0,column=0)
self.pigButton = tk.Button(self, text='Pig',command=self.setPork)
self.pigButton.grid(row=0,column=1)
self.meatLabel = tk.Label(self)
self.meatLabel.configure(textvariable=self.meatvar)
self.meatLabel.grid(row=0,column=2)
self.quit = tk.Button(self, text='Quit',command=self.QuitApp)
self.quit.grid(row=0, column=3)           
def setBeef(self):
self.meatvar.set("Beef")
def setPork(self):
self.meatvar.set("Pork")
def QuitApp(self):
top=self.winfo_toplevel()
top.quit()
main = Tkclass()

Votre réponse n'est pas tout à fait correct. Vous pouvez spécifier aucun widget en tant que maître, vous n'avez pas besoin de donner la fenêtre racine. Vous pouvez utiliser le tkinter variables amende lorsque vous héritez de l'Image.

InformationsquelleAutor user3061910

Vous devez vous connecter pour publier un commentaire.