Diferències

Ací es mostren les diferències entre la revisió seleccionada i la versió actual de la pàgina.

Enllaç a la visualització de la comparació

info:cursos:pue:python-pcpp1:m3:1.3 [22/12/2023 12:59] – creat mateinfo:cursos:pue:python-pcpp1:m3:1.3 [23/12/2023 19:49] (actual) mate
Línia 74: Línia 74:
 You're not obliged to declare the number of rows and columns in advance – ''grid()'' finds the proper numbers for you. Let's try it. You're not obliged to declare the number of rows and columns in advance – ''grid()'' finds the proper numbers for you. Let's try it.
  
 +The most commonly used ''grid()'' method parameters are gathered below (as, previously, all of them are passed as keyword arguments):
 +
 +  * ''column=c'' – deploys the widget in the column number c; note: the columns' numbers start from zero, and if you omit this argument, the manager will assume 0 (the left-most column)
 +  * ''row=r'' – deploys the widget in the row number r; if you omit this argument, the manager will assume the first free row starting from the top;
 +  * ''columnspan=cs'' – determines how many neighboring columns the widget occupies; the parameter defaults to 1 (the widget won't cross a single grid's cell)
 +  * ''rowspan=rs'' – works as columnspan but refers to rows.
 +
 +Let's see them all in action.
 +
 +<code python>
 +import tkinter as tk
 +
 +window = tk.Tk()
 +button_1 = tk.Button(window, text="Button #1")
 +button_2 = tk.Button(window, text="Button #2")
 +button_3 = tk.Button(window, text="Button #3")
 +button_1.grid(row=0, column=0)
 +button_2.grid(row=1, column=1)
 +button_3.grid(row=2, column=2)
 +window.mainloop()
 +
 +</code>
 +
 +Analyze the snippet in the editor and determine the resulting number of columns and rows. That's essential if you want to imagine the resulting window's appearance.
 +
 +Are you ready to solve the puzzle? Did you imagine the window that way?
 +
 +{{ :info:cursos:pue:python-pcpp1:m3:pasted:20231223-103426.png }}
 +
 +We're sure you did. Look. The window is divided into **nine cells**: three rows and three columns. The buttons are settled on the **grid's diagonal**.
 +
 +Now we’re going to affect the buttons’ relation to the cells’ boundaries.
 +
 +Can you see what we changed in the code?
 +
 +<code python>
 +import tkinter as tk
 +
 +window = tk.Tk()
 +button_1 = tk.Button(window, text="Button #1")
 +button_2 = tk.Button(window, text="Button #2")
 +button_3 = tk.Button(window, text="Button #3")
 +button_1.grid(row=0, column=0)
 +button_2.grid(row=1, column=1)
 +button_3.grid(row=2, column=0, columnspan=2)
 +window.mainloop()
 +
 +</code>
 +
 +Yes, we modified the third ''grid()'' invocation a bit. We wanted to deploy the button inside the cell located in the third (actually, the lowest) row and the first (the left-most) column, but we also did something else – we wanted the widget to span across two horizontally neighboring cells.
 +
 +We admit that this puzzle is somewhat harder than the previous ones. Don't rush through this – think it over carefully.
 +
 +Here's the solution.
 +
 +{{ :info:cursos:pue:python-pcpp1:m3:pasted:20231223-103658.png }}
 +
 +Note: the manager noticed that the total number of columns is actually two, not three as in the previous code. This is why the window looks different.
 +
 +The third, fully automatic geometry manager is named ''pack()'' as it **packs subsequent widgets** into the window's interior. This means that the **order** in which the widgets are packed **matters** – in contrast to ''grid()'' and ''place()''.
 +
 +Let's take a look at it.
 +
 +The default pack's operation tends to deploy all subsequent widgets in one column, one below the other. You can change this behavior to a limited extent by using the following parameters:
 +  * ''side=s'' – forces the manager to pack the widgets in a specified **direction**, where s can be specified as:
 +    * ''TOP'' – the widget is packed toward the window's **top** (it's manager's default behavior)
 +    * ''BOTTOM'' – the widget is packed toward the window's **bottom**;
 +    * ''LEFT'' – toward the window's **left** boundary;
 +    * ''RIGHT'' – toward the window's **right** boundary;
 +  * ''fill=f'' – suggests to the manager how to expand the widget if you want it to occupy more space than the default, while ''f'' should be specified as:
 +    * ''NONE'' – do not expand the widget (default behavior)
 +    * ''X'' – expand it in the **horizontal** direction;
 +    * ''Y'' – expand it in the **vertical** direction;
 +    * ''BOTH'' – expand it in **both** directions;
 +
 +We want to warn you that the results produced by ''pack()'' can be extremely surprising, and you should spend some time on your own experimenting with all its vices.
 +
 +We suggest you use it only as a temporary solution to help you get a working application quickly, but if you want your application to look nice and to be legible and clear (of course, you would want that!) you'd better forget about ''pack()'' and use either ''grid() ''(in simpler cases) or ''place()''.
 +
 +Let ''pack()'' show us what it can do for us. Look at the code in the editor.
 +
 +<code python>
 +import tkinter as tk
 +
 +
 +window = tk.Tk()
 +button_1 = tk.Button(window, text="Button #1")
 +button_2 = tk.Button(window, text="Button #2")
 +button_3 = tk.Button(window, text="Button #3")
 +button_1.pack()
 +button_2.pack()
 +button_3.pack()
 +window.mainloop()
 +
 +</code>
 +
 +As you can see, using ''pack()'' simplifies the code – you don't need to specify any coordinates – but that doesn't mean this will simplify the developer's life. You may expect that ''pack()'' will know how to handle your widgets, but sometimes it's work results are like a lottery.
 +
 +Let's look at the window we get. The window looks different.
 +
 +{{ :info:cursos:pue:python-pcpp1:m3:pasted:20231223-104409.png }}
 +
 +Very different. For example, the window fits its size to the area occupied by the widgets. The buttons are located one after the other, from top to bottom.
 +
 +Let's play a little game with ''pack'''s arguments.
 +
 +We've ordered ''pack()'' to push the ''button_1'' button to the right window's boundary.
 +
 +<code python>
 +import tkinter as tk
 +
 +window = tk.Tk()
 +button_1 = tk.Button(window, text="Button #1")
 +button_2 = tk.Button(window, text="Button #2")
 +button_3 = tk.Button(window, text="Button #3")
 +button_1.pack(side=tk.RIGHT)
 +button_2.pack()
 +button_3.pack()
 +window.mainloop()
 +
 +</code>
 +
 +Can you predict the window's appearance? We admit that it may be difficult.
 +
 +Is this what you expected?
 +
 +{{ :info:cursos:pue:python-pcpp1:m3:pasted:20231223-104640.png }}
 +
 +No? Are you surprised? You have the right to be. Pack is the **least intuitiv**e geometry manager for sure, and you really need to spend some time testing its whims.
 +
 +We have one more experiment left to carry out.
 +
 +Note: we want the ''button_1'' button to be **filled (expanded)** in the **vertical** direction:
 +
 +This puzzle is a bit easier than the previous one. Think for a moment.
 +
 +<code python>
 +import tkinter as tk
 +
 +window = tk.Tk()
 +button_1 = tk.Button(window, text="Button #1")
 +button_2 = tk.Button(window, text="Button #2")
 +button_3 = tk.Button(window, text="Button #3")
 +button_1.pack(side=tk.RIGHT, fill=tk.Y)
 +button_2.pack()
 +button_3.pack()
 +window.mainloop()
 +
 +</code>
 +
 +Yes, you're right – this is the expected answer.
 +
 +{{ :info:cursos:pue:python-pcpp1:m3:pasted:20231223-104848.png }}
 +
 +We think that there is one intriguing question that can be asked here and now: do these buttons have to be **gray**? It's boring. Very boring.
 +
 +We're going to clear up this issue soon
  
  • info/cursos/pue/python-pcpp1/m3/1.3.1703246340.txt.gz
  • Darrera modificació: 06/07/2026 18:29
  • (edició externa)