[英]Tkinter GUI Layout Python
我需要编写一个函数来制作一个frame
因为它是唯一的参数
和
在如下所示的布局中添加了四个按钮。
( Button1
和Button2
在红色框中,另外两个在黄色框中)
+---------------------------------------+
| |
| [Button1] |
| [Button3] [Button4] |
| [Button2] |
| |
+---------------------------------------+
这只是家庭作业。 谢谢你。
import tkinter as tk
def pressed():
print("Button Pressed!")
def create_layout(frame):
frame1 = frame(frame, bg = "red")
frame1.pack(side = RIGHT, fill = tk.BOTH)
b = Button(frame, text='Button1', padx = 20, command=pressed)
b.pack(pady = 20, padx = 20)
c = Button(frame, text='Button2', padx = 20, command=pressed)
c.pack(pady = 20, padx = 20)
frame2 = frame(frame, bg = "yellow")
frame2.pack(side = RIGHT, fill = tk.BOTH)
button3 = tk.Button(frame, text="Button3", command=pressed)
button3.pack(pady = 20, padx = 20)
button4 = tk.Button(frame, text="Button4", command=pressed)
button4.pack(pady = 20, padx = 20)
您的代码走在正确的轨道上。 做小部件布局的关键是要有条不紊,不要试图一次解决所有问题。
我的建议是首先专注于让您的红色和黄色框架正常工作,而不是别的。 编写足够的代码让它们出现在你想要的地方,并在你调整窗口大小时有适当的行为。 您使用pack
做出了不错的选择,因为它非常适合从左到右或从上到下排列小部件的工作。
一旦你开始工作,那么你就可以专注于按钮。 选择一帧或另一帧,并专注于让按钮在一个帧中工作。 确保该框架内的小部件使用该框架作为其父级。
最后,处理剩余的帧,再次做完全相同的事情。 在所有情况下,我的建议是始终明确并使用side
属性。 虽然依赖默认值是可以的,但在学习时最好是明确的。
Tkinter 有许多构建块(小部件、框架、画布)和几个所谓的几何管理器{ .pack() | .grid() | .place() }
{ .pack() | .grid() | .place() }
{ .pack() | .grid() | .place() }
以“将部分放在一起”,进入更大的图景,背后有一些基本原理。
这些命名几何管理器中的每一个都有助于实现 Tkinter 的通用行为 - 整个 GUI 组合的自动缩放(如果需要)。 每一个都适合某种特定类型的布局组合。 没有万能的万能大师或“万事通”,但每个人都有适合特定布局模型的长处。
GUI 布局需求非常不同,Tkinter 方法可帮助人们实现所需的外观模型,并允许(几乎)忘记单个合成元素的结果位置、边缘、大小和缩放之间的许多内部关系和交叉依赖性。
Where .pack() or .grid() may help:
+--<Frame>-frame-----------------------------------------------------+
| |
| +-<Frame>-aYelFrame----------+ +-<Frame>-aRedFrame----------+ |
| | side = tk.LEFT | | side = tk.RIGHT | |
| | fill = tk.BOTH | | fill = tk.BOTH | |
| | +----------------------+ | | +----------++----------+ | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | +-<Button>-------------+ | | [ ][ ] | |
| | +----------------------+ | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | [ ] | | [ ][ ] | |
| | +-<Button>-------------+ | | +-<Button>-++-<Button>-+ | |
| | | | | |
| +----------------------------+ +----------------------------+ |
| |
+--------------------------------------------------------------------+
布局策略决定了哪些可用方法或多或少方便。
您可以使用另一个 Tkinter 几何管理器方法,而不是.pack()
,例如.place()
:
aSampleButton = tk.Button( aRedFrame, text = "aSampleButton", ... )
aSampleButton.place( x = 0, # in pixels - a Widget x position,
y = 0, # in pixels - a Widget y position,
width = 100, # in pixels - a Widget absolute width,
height = 15, # in pixels - a Widget absolute height
)
通过这种方式,您可以完全控制在Frame
设计 UI 的自由。
Where .place() may help to design a UI,
where arranging
widgets left-to right / top-to-bottom is not the case,
with a complete down-to-pixel layout control
that is warmly welcome in cases,
where a bitmap layer has to be met pixel-by-pixel,
like if you need to place controls ( buttons et al )
onto a bitmap picture of an instrument ( an Oscilloscope, Sonar )
and mediate interactions between GUI and device / process
+--<Frame>-frame-----------------------------------------------------+
| +-<Frame>-aRedFrame----------+ |
| | | |
| | | |
| +-<Frame>-aYelFrame----------+ | | |
| | +-------------+ | | | |
| | [ ] | | | |
| | [ ] | | | |
| | [ ] | | | |
| | [ ] | | | |
| | [ ] | | | |
| | [ ] | | | |
| | +-<Button>----+ | |+----------+ | |
| | | |[ ] +----------+| |
| | | |+-<Button>-+ [ ]| |
| | | | +-<Button>-+| |
| | | | | |
| | +-------------------+| | | |
| | [ ]| | | |
| | +-<Button>----------+| | | |
| | | | | |
| | | +----------------------------+ |
| | | |
| +----------------------------+ |
| |
+--------------------------------------------------------------------+
注意:虽然有多个布局管理器可用,但声明并坚持这种做法是公平的,以避免在同一个父框架中使用多个几何管理器。 如有必要,可以重新设计父子关系,以保持与同一父框架相关的所有小部件使用相同的布局几何管理器方法(全部.pack()
或全部.place()
,但不要混合他们 )。
本文适用于从Tkinter
代码的入门级实践开始建立对Tkinter
的理解的用户。 鹰派修行者肯定会有很多更高层次的见识和无数的实践经验。 答案并没有提供代码的野心,而是相信为驱动原则带来一些亮点可以帮助用户掌握概念,这些概念在面向语法的文档中不是那么直接可见(并且可能很难理解)来自其他(半)最终代码片段的代码示例的逆向工程,其布局策略动机可能不兼容)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.