Widgets verrücken nicht
ich habe einen Frame mit 4 Widgets der Frame befindet sich mit grid(sticky="nw") ganz oben links.Die Widgets sind mit pack(side =LEFT)alle nebeneinander.Dies wollte ich dann so ändern das alle immer ein bisschen Abstand haben.Habe dann jedem grid(row=0) geben.Und Column=0 beim ersten und beim zweiten column=2 damit immer abstand ist beim dritten dann column=4 und beim vierten dann column=8.Nur bewegen tut sich da nicht egal was ich bei column schreibe.(row funktioniert aber)Was kann ich tun und was ist das Problem?(Ich bin tkinter Anfänger)
Vor allem kannst du deinen Code zeigen, denn mit einer solchen Paraphrasierung kann man nicht viel anfangen. Man weiss nicht, wer jetzt "jede" sind, und warum du mal pack und mal grid fuer die gleichen Dinge zu benutzen scheinst. Aber kann auch alles ganz anders sein. Darum bitte den Code zeigen.
- __blackjack__
- User
- Beiträge: 14087
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@SvKaGli: Man kann leere Zeilen und Spalten bei `grid()` nicht für Abstand verwenden weil die 0 Pixel hoch beziehungsweise breit sind, wenn sie leer sind. Das wäre auch ein Missbrauch, denn für Abstände haben sowohl `grid()` als auch `pack()` entsprechende Argumente.
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
__deets__ hat geschrieben: Samstag 16. Mai 2020, 13:29 Vor allem kannst du deinen Code zeigen, denn mit einer solchen Paraphrasierung kann man nicht viel anfangen. Man weiss nicht, wer jetzt "jede" sind, und warum du mal pack und mal grid fuer die gleichen Dinge zu benutzen scheinst. Aber kann auch alles ganz anders sein. Darum bitte den Code zeigen.
Code: Alles auswählen
from tkinter import *
haubtfenster=Tk()
haubtfenster.title("Multiquiz")
haubtfenster.configure(bg="#606060")
einstellungenicon=PhotoImage(file="Grafiken/Buttons/Einstellungen.png")
meinprofilicon=PhotoImage(file="Grafiken/Buttons/Meinprofil.png")
hilfeicon=PhotoImage(file="Grafiken/Buttons/Hilfe.png")
meinewebseiteicon=PhotoImage(file="Grafiken/Buttons/Meinewebseite.png")
geschichteicon=PhotoImage(file="Grafiken/Buttons/Geschichte.png")
filmeundserienicon=PhotoImage(file="Grafiken/Buttons/Filme und Serien.png")
gamesicon=PhotoImage(file="Grafiken/Buttons/Games.png")
leisteoben=Frame(haubtfenster)
leistelinks=Frame(haubtfenster)
einstellungen=Button(leisteoben,image=einstellungenicon,bg="#a3a0a0")
meinprofil=Button(leisteoben,image=meinprofilicon,bg="#a3a0a0")
hilfe=Button(leisteoben,image=hilfeicon,bg="#a3a0a0")
meinewebseite=Button(leisteoben,image=meinewebseiteicon,bg="#a3a0a0")
geschichte=Button(leistelinks,image=geschichteicon,bg="#a3a0a0")
filmeundserien=Button(leistelinks,image=filmeundserienicon,bg="#a3a0a0")
games=Button(leistelinks,image=gamesicon,bg="#a3a0a0")
kategorien=Label(leistelinks,text="Kategorien:",bg="#a3a0a0")
minigame=Label(leistelinks,text="Das Minispiel:",bg="#a3a0a0")
leisteoben.grid(stick="nw")
einstellungen.pack(side=LEFT)
meinprofil.pack(side=LEFT)
hilfe.pack(side=LEFT)
meinewebseite.pack(side=LEFT)
leistelinks.grid(row=1,column=0,sticky="w")
kategorien.pack()
geschichte.pack()
filmeundserien.pack()
games.pack()
minigame.pack()
haubtfenster.mainloop()
Kannst du mir diese nennen?__blackjack__ hat geschrieben: Samstag 16. Mai 2020, 14:39 @SvKaGli: Man kann leere Zeilen und Spalten bei `grid()` nicht für Abstand verwenden weil die 0 Pixel hoch beziehungsweise breit sind, wenn sie leer sind. Das wäre auch ein Missbrauch, denn für Abstände haben sowohl `grid()` als auch `pack()` entsprechende Argumente.
- __blackjack__
- User
- Beiträge: 14087
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@SvKaGli: Anmerkungen zum Quelltext:
Sternchen-Importe sind Böse™. Damit holt man sich gerade bei `tkinter` fast 200 Namen ins Modul von denen nur ein kleiner Bruchteil tatsächlich benötigt wird. Und nicht nur Namen die im `tkinter`-Modul selbst definiert werden, sondern auch alle Namen die das Modul seinerseits von woanders importiert.
Für die `sticky`-Argumente von der `grid()`-Methode gibt es auch Kontanten im `tkinter`-Modul.
`hauptfenster` schreibt man mit `p`. KeineLeerzeichenzwischenwortensindschwerlesbar. Das gilt auch für fehlende Unterstriche in Namen. Also beispielsweise`filme_und_serien_icon` statt `filmeundserienicon`.
Die Aufteilung des Codes macht es nicht einfach zu erkennen was wo platziert wird und macht es auch unnötig schwer die Funktion irgendwann einmal aufzuteilen. Einige der Namen braucht man auch gar nicht wenn man den Code nicht so verteilt. Von Labeln die nur zur Beschriftung dienen und nicht zur Ausgabe von sich ändernden Werten braucht man beispielsweise so gut wie nie einen Namen.
Code- und Datenwiederholungen sollte man vermeiden, weil das fehleranfällig und unflexibel ist. In dem Quelltext wiederholt sich beispielsweise der Pfad zu den Grafiken recht häufig. Wenn man den anpassen/ändern möchte, muss man das an vielen Stellen tun. So etwas definiert man in der Regel einmal am Anfang des Programms.
Code wird beim erstellen der Buttons wiederholt. Das ist bei jedem Button das gleiche Muster: Icon laden, `Button`-Objekt erstellen, und mit `pack()` anordnen. Der Unterschied ist jeweils im Grunde nur der Dateiname des Icons. Code-Wiederholungen kann man mit Schleifen und/oder Funktionen beseitigen. Zum Beispiel eine Funktion die alle drei Schritte für einen Button durchführt, und dann eine Schleife über die Icon-Dateinamen, die diese Funktion für jeden Namen aufruft.
Ungetestet:
Sternchen-Importe sind Böse™. Damit holt man sich gerade bei `tkinter` fast 200 Namen ins Modul von denen nur ein kleiner Bruchteil tatsächlich benötigt wird. Und nicht nur Namen die im `tkinter`-Modul selbst definiert werden, sondern auch alle Namen die das Modul seinerseits von woanders importiert.
Für die `sticky`-Argumente von der `grid()`-Methode gibt es auch Kontanten im `tkinter`-Modul.
`hauptfenster` schreibt man mit `p`. KeineLeerzeichenzwischenwortensindschwerlesbar. Das gilt auch für fehlende Unterstriche in Namen. Also beispielsweise`filme_und_serien_icon` statt `filmeundserienicon`.
Die Aufteilung des Codes macht es nicht einfach zu erkennen was wo platziert wird und macht es auch unnötig schwer die Funktion irgendwann einmal aufzuteilen. Einige der Namen braucht man auch gar nicht wenn man den Code nicht so verteilt. Von Labeln die nur zur Beschriftung dienen und nicht zur Ausgabe von sich ändernden Werten braucht man beispielsweise so gut wie nie einen Namen.
Code- und Datenwiederholungen sollte man vermeiden, weil das fehleranfällig und unflexibel ist. In dem Quelltext wiederholt sich beispielsweise der Pfad zu den Grafiken recht häufig. Wenn man den anpassen/ändern möchte, muss man das an vielen Stellen tun. So etwas definiert man in der Regel einmal am Anfang des Programms.
Code wird beim erstellen der Buttons wiederholt. Das ist bei jedem Button das gleiche Muster: Icon laden, `Button`-Objekt erstellen, und mit `pack()` anordnen. Der Unterschied ist jeweils im Grunde nur der Dateiname des Icons. Code-Wiederholungen kann man mit Schleifen und/oder Funktionen beseitigen. Zum Beispiel eine Funktion die alle drei Schritte für einen Button durchführt, und dann eine Schleife über die Icon-Dateinamen, die diese Funktion für jeden Namen aufruft.
Ungetestet:
Code: Alles auswählen
#!/usr/bin/env python3
import tkinter as tk
from pathlib import Path
GRAFIK_PFAD = Path("Grafiken", "Buttons")
def add_icon_button(master, dateipfad, button_options, pack_options):
icon = tk.PhotoImage(file=dateipfad)
button = tk.Button(master, image=icon, **button_options)
button.image = icon
button.pack(**pack_options)
return button
def main():
hauptfenster = tk.Tk()
hauptfenster.title("Multiquiz")
hauptfenster.configure(bg="#606060")
options = {"bg": "#a3a0a0"}
leiste_oben = tk.Frame(hauptfenster)
for dateiname in [
"Einstellungen.png",
"Meinprofil.png",
"Hilfe.png",
"Meine_webseite.png",
]:
add_icon_button(
leiste_oben, GRAFIK_PFAD / dateiname, options, {"side": tk.LEFT}
)
leiste_oben.grid(row=0, column=0, sticky=tk.NW)
leiste_links = tk.Frame(hauptfenster)
tk.Label(leiste_links, text="Kategorien:", **options).pack()
for dateiname in ["Geschichte.png", "Filme und Serien.png", "Games"]:
add_icon_button(leiste_links, GRAFIK_PFAD / dateiname, options, {})
tk.Label(leiste_links, text="Das Minispiel:", **options).pack()
leiste_links.grid(row=1, column=0, sticky=tk.W)
hauptfenster.mainloop()
if __name__ == "__main__":
main()
“Vir, intelligence has nothing to do with politics!” — Londo Mollari
@__blackjack__
1Ich weiss das Sternchen import bei konkurrierenden Modulen zu Problemen führt weshalb ich das auch nur bei Modulen mache wo von ich viel verwende
die wo von ich nur eins benutze importiere ich dann auch so from ... import... sollte ich zwei haben wo von ich vieles nutze importiere ich beide mit import.. as...In dem Buch Python let Cod wurde das so gemacht und es wurde natürlich gesagt das es Probleme geben kann weshalb bei so Modulen wie random wo von man dann meist eh nur randInt von benutze wurde dann mit from random import randInt importiert.Diese Sternchen import werde ich beim Multiquiz natürlich ändern und auch nicht mehr so machen.
2Ja b und p ist bei haupt manche mal ein Problem von mir
3ja Unterstriche sollte ich nehmen (tuh ich auch bei großen Namen) aber bei sowas wie film und serien was ja nur so 3 kurze Worte sind dachte ich das kann ich auch so zusammen schreiben.
4Ok merk ich mir aber ich dachte man schreibt immer ein Variablen Namen aber wirklich ein Problem ist es doch nicht oder?
5Ich achte ja drauf das cod sich nicht wiederholt aber ja ich wusste keine andere Lösung was die Bilder Pfads angeht
6 Das Modul Path kenne ich noch gar nicht
Gib mir aber noch einen Antwort auf meine Frage also falls du eine hast
1Ich weiss das Sternchen import bei konkurrierenden Modulen zu Problemen führt weshalb ich das auch nur bei Modulen mache wo von ich viel verwende
die wo von ich nur eins benutze importiere ich dann auch so from ... import... sollte ich zwei haben wo von ich vieles nutze importiere ich beide mit import.. as...In dem Buch Python let Cod wurde das so gemacht und es wurde natürlich gesagt das es Probleme geben kann weshalb bei so Modulen wie random wo von man dann meist eh nur randInt von benutze wurde dann mit from random import randInt importiert.Diese Sternchen import werde ich beim Multiquiz natürlich ändern und auch nicht mehr so machen.
2Ja b und p ist bei haupt manche mal ein Problem von mir
3ja Unterstriche sollte ich nehmen (tuh ich auch bei großen Namen) aber bei sowas wie film und serien was ja nur so 3 kurze Worte sind dachte ich das kann ich auch so zusammen schreiben.
4Ok merk ich mir aber ich dachte man schreibt immer ein Variablen Namen aber wirklich ein Problem ist es doch nicht oder?
5Ich achte ja drauf das cod sich nicht wiederholt aber ja ich wusste keine andere Lösung was die Bilder Pfads angeht
6 Das Modul Path kenne ich noch gar nicht
Gib mir aber noch einen Antwort auf meine Frage also falls du eine hast
- __blackjack__
- User
- Beiträge: 14087
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@SvKaGli: Ad 3: Das kann auch bei zwei Worten schon komisch werden, wenn beispielsweise die beiden Worte zusammen ein existierendes anderes Wort ergeben oder das da dann zumindest deutlich dein steht. Dann erkennt man beim Lesen vielleicht immer erst dieses andere Wort und muss einen Extraschritt in Gedanken machen um das an der richtigen Stelle zu trennen. Das kann auch noch einen Tick schwerer werden wenn die Namen nicht in der Muttersprache sind und man vielleicht sogar die zwei oder Einzelworte nicht kennt und dann vor/beim Übersetzen erst einmal raus finden muss wo man trennen muss/kann und welche Trennung/Übersetzung am Ende Sinn macht.
Ad 4: Namen sollten eigentlich immer gute Namen sein, und wenn man keinen Namen braucht, dann muss man sich auch keinen guten Namen überlegen. Und tatsächlich nicht notwendige Namen, also wenn der Name definiert aber dann *überhaupt* nicht verwendet wird, sehe ich in sofern als Problem, als das Fragen beim Leser aufwirft. Zum Beispiel ob das Absicht ist, oder ob der Code noch nicht fertig ist, oder ob man den Code der das nicht benutzte Objekt erzeugt, auch einfach löschen kann, oder ob der Seiteneffekte hat die wichtig sind. Wobei es da noch die Konvention gibt bei nicht verwendeten lokalen Namen einen Unterstrich vor den Namen zu setzen um zu kennzeichnen, dass der Name im folgenden Code absichtlich nicht verwendet wird, man den also nur zum besseren Verständnis dort hingeschrieben hat, oder weil Syntax oder API da unbedingt einen Namen haben wollen.
Zur Frage mit den Abständen: Für `pack()` steht das sogar in der Python-Dokumentation zum `tkinter`-Modul. Am Anfang sind in dieser Dokumentation eine ganze Menge Links zu anderen, ausführlicheren Dokumentationen. Zum Beispiel die Tkinter Reference der New Mexico Tech die beispielsweise das hier zur `grid()`-Methode hat: https://web.archive.org/web/20190420152 ... /grid.html
Und Effbot's Buch ist auch ein Klassiker. Die Seiten zu grid() http://effbot.org/tkinterbook/grid.htm und zu pack() http://effbot.org/tkinterbook/pack.htm
Last but not least ist natürlich die Tk-Dokumentation ein guter Anlaufpunkt, denn die `tkinter`-API ist ja letztlich nur ein ”Übersetzer” zwischen Python und Tk/Tcl.
Ad 4: Namen sollten eigentlich immer gute Namen sein, und wenn man keinen Namen braucht, dann muss man sich auch keinen guten Namen überlegen. Und tatsächlich nicht notwendige Namen, also wenn der Name definiert aber dann *überhaupt* nicht verwendet wird, sehe ich in sofern als Problem, als das Fragen beim Leser aufwirft. Zum Beispiel ob das Absicht ist, oder ob der Code noch nicht fertig ist, oder ob man den Code der das nicht benutzte Objekt erzeugt, auch einfach löschen kann, oder ob der Seiteneffekte hat die wichtig sind. Wobei es da noch die Konvention gibt bei nicht verwendeten lokalen Namen einen Unterstrich vor den Namen zu setzen um zu kennzeichnen, dass der Name im folgenden Code absichtlich nicht verwendet wird, man den also nur zum besseren Verständnis dort hingeschrieben hat, oder weil Syntax oder API da unbedingt einen Namen haben wollen.
Zur Frage mit den Abständen: Für `pack()` steht das sogar in der Python-Dokumentation zum `tkinter`-Modul. Am Anfang sind in dieser Dokumentation eine ganze Menge Links zu anderen, ausführlicheren Dokumentationen. Zum Beispiel die Tkinter Reference der New Mexico Tech die beispielsweise das hier zur `grid()`-Methode hat: https://web.archive.org/web/20190420152 ... /grid.html
Und Effbot's Buch ist auch ein Klassiker. Die Seiten zu grid() http://effbot.org/tkinterbook/grid.htm und zu pack() http://effbot.org/tkinterbook/pack.htm
Last but not least ist natürlich die Tk-Dokumentation ein guter Anlaufpunkt, denn die `tkinter`-API ist ja letztlich nur ein ”Übersetzer” zwischen Python und Tk/Tcl.
“Vir, intelligence has nothing to do with politics!” — Londo Mollari