Allow turtledemo code pane to get wider.

[terryjreedy]

BPO	21597
Nosy	@terryjreedy, @ned-deily
Files	turtledemo_pane.patch turtledemo_pane.patch tkinter_tear.mov turtledemo_grid.patch turtledemo_pane_srcoll_fix.patch turtledemo_pane_srcoll_fix.patch turtledemo_pane_scroll_FLAT.patch turtledemo_pane_scroll_SOLID.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2014-07-23.19:07:27.150>
created_at = <Date 2014-05-28.19:53:07.714>
labels = ['type-bug']
title = 'Allow turtledemo code pane to get wider.'
updated_at = <Date 2014-07-23.22:06:48.865>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2014-07-23.22:06:48.865>
actor = 'Lita.Cho'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2014-07-23.19:07:27.150>
closer = 'terry.reedy'
components = []
creation = <Date 2014-05-28.19:53:07.714>
creator = 'terry.reedy'
dependencies = []
files = ['35503', '35546', '35859', '35874', '35877', '35878', '35889', '35890']
hgrepos = []
issue_num = 21597
keywords = ['patch']
message_count = 46.0
messages = ['219296', '219539', '219543', '219902', '219920', '220120', '220122', '221146', '221147', '221206', '222301', '222302', '222306', '222317', '222318', '222319', '222320', '222321', '222322', '222323', '222326', '222327', '222328', '222330', '222331', '222332', '222398', '222411', '222420', '222423', '222425', '222434', '222435', '222441', '222490', '222491', '223595', '223627', '223718', '223719', '223731', '223760', '223763', '223773', '223786', '223787']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'ned.deily', 'jesstess', 'python-dev', 'Lita.Cho']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21597'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[terryjreedy]

Turtledemo (python -m turtledemo) has a text pane for code and a canvas pane for the actual demo. The code pane is fixed at about 60% of the width needed to display full-width code lines. If the window is expanded horizontally, all the expansion goes to the canvas pane, where it is mostly not needed or used. Almost all the examples are a fixed size on the canvas, independent of the size of the window on the canvas.

Having the text pane too narrow makes it harder to read and copy the code than it would be if entire code lines were visible. The default width of the overall window is about 1250 pixels on my big monitor. Many people have more pixels than that. Even on smaller screen, people might like to temporarily allocate more space to the text. So I think the best solution, if possible with tkinter, would be a movable divider.

[LitaCho]

I'll take this on.

[terryjreedy]

The patch for bpo-18132 replaced pack with grid, But the replacement seemed partial even within the top frame (but I may have misread). Mixing the two is known to be a bad idea. http://effbot.org/tkinterbook/grid.htm has a big warning box about this. I think we can fix both issues with a 2row x 4col grid. The first col would have a minsize as now but be expandable. The canvas would have a rowspan of 3. The bottom row would have a fixed size so it does not disappear. I don't know if gridding a frame with a widget and scrollbars packed inside is ok or not. If not, it should be possible to grid widget and scrollbars instead. In any case, the result should be a bit simpler, with at least 1 less intermediate frame (for the 3 buttons under the canvas. Unless someone else would rather, I will do a final review, test, and commit.

If you try an approach that does not work, say so and I will know not to suggest it ;-).

[LitaCho]

Hi Terry!

I went ahead and added a movable divider (also known as a "sash") using the PanedWindow widget. http://effbot.org/tkinterbook/panedwindow.htm#reference

I also converted the master window to use a grid geometry manager. It looks like you can use pack manager and grid managers together as long as each manager is separated by a container/frame. So I use the pack manager to manage the scrollbars within the Frame. It ended up working out nicely.

I've attached a patch and would like to submit it for review!

[terryjreedy]

I ran the patched code but have not looked at the code itself. Pending such a look, I would consider committing it if we cannot do better, as it solves both issues. However, there are two visual issues.

1. The minor one: The blue label does not have drop shadows, the red/yellow buttons do. I suspect the intent is to differentiate something that cannot be pressed from things that can. But the effect at the boundary is bit jarring. On the bottem, the buttons are underlined in black, the label not. On the top, the button have a very light shading that makes them look narrower than they are. I wonder if it would look better if the label has shadows to match, or if there were a small separation between the labels and buttons (horizonatal padding on the label?). If you understand what is bother me, see if you can come up with something that looks better than you. Even post a couple of alternatives, if you want.

2. More important: when I move the slider right, the text widen and the canvas narrows relatively smoothly. When I go the other way, to the left, a trail of vertical line is left behind for perhaps a third of a second. The right scrollbar, the vertical canvas bars, jiggles back and forth about a few mm, as if it were not fixed in place but attached to springs and dragged by the canvas. This happens even with both panes empty. It looks pretty bad.

I wonder if this has anything to do with mixing grid and pack. An experiment would be to put an empty PanedWindow into a window and see if it behaves as badly. I have a decent system, and moving -> work almost ok, so something seems wrong.

[LitaCho]

Hi Terry!

2. More important: when I move the slider right, the text widen and the canvas narrows relatively smoothly.

This is not due to the mixing of Pack and Grid Managers. This is due to adding Frames within a Pane Window. If I just create two empty Pane Windows, I don't get the lag. However, if I add a Frame container within Pane Window, I do. I've tried switching between using only the Pack Manager and then again using only the Grid Manager. However, that lag still exists.

I have the code here if you want to try the packed version.

from tkinter import *
root = Tk()
m = PanedWindow(root, orient=HORIZONTAL, sashwidth=10)
rightF =  Frame(m)
leftF = Frame(m)
top = Label(leftF, text="lefgt pane", bg='blue')
bottom = Label(rightF, text="right pane", bg='red')
top.pack(fill=BOTH, expand=1)
bottom.pack(fill=BOTH, expand=1)
m.add(leftF)
m.add(rightF)

m.pack(fill=BOTH, expand=1)
mainloop()

[LitaCho]

1. The minor one: The blue label does not have drop shadows, the red/yellow buttons do.

I created a patch to add a border around the label and create some padding between the buttons and the label. Let me know if this is less jarring than the previous version.

[LitaCho]

ping!

I just want to know how I should proceed with this ticket. I can try removing the Frames with get rid of the lag, but then I feel like we can't use the Grid Manager at all. :\

[terryjreedy]

I downloaded new patch and will try to look at it this weekend.

[terryjreedy]

I played around for a couple of hours, but am not sure what I want to do other than catching currently uncaught turtle.Terminator (in another issue). I might want to try my original idea of just using grid, without PanedWindow.

Another idea is to ttk widgets, including PanedWindow, to see if they act the same.
http://www.tkdocs.com/tutorial/complex.html
says "Typically the widgets you're adding to a panedwindow will be frames containing many other widgets.". Than implies that the combination should work. The (partial) example there (including a Python tkinter version) uses two ttk.LabelFrames in a ttk.PanedWindow. Perhaps you can try your minimal example with a ttk Frame.

Through Google I found an example of PanedWindow with two Frames here (line 29):
http://nullege.com/codes/show/src%40r%40o%40robotframework-workbench-0.5%40rwb%40editor%40custom_notebook.py/29/Tkinter.PanedWindow/python
so it is definitely being done. If we cannot get it to work without tearing, I may ask on StackOverflow. So please post your minimal code of empty frames that exhibits the problem.

[LitaCho]

Hi Terry, I started digging into this deeper and it looks like my tests doesn't tear in Python 2.7. I have tried on Python 3.5 and 3.4 and it tears on those versions.

I also tried the ttk objects, and the widgets also teared when I added frames. Here is the code I tried.

from tkinter import *
from tkinter import ttk

paned = ttk.Panedwindow(orient="horizontal")
left = ttk.Frame(paned)
left.pack(side='left', fill='both', expand=True)
right = ttk.Frame(paned)
right.pack(side='right', fill='both', expand=True)
button = ttk.Button(left,text="lefgt pane")
button.pack( fill='both', expand=True)
button2 = ttk.Button(right, text="right pane")
button2.pack( fill='both', expand=True)
paned.add(left)
paned.add(right)
paned.pack(fill="both",expand=True, pady = (4,1), padx=4)

mainloop()

[LitaCho]

Should I file a bug? I feel like this a bug specifically related to Python 3 and Tkinter.

[ned-deily]

If by tearing you mean leaving artifacts on the screen, differences in behavior are almost certainly due to different versions of Tk being used. Tkinter is really just a wrapper around calls to Tk; nearly all of the heavy-duty graphics work is done by Tk making calls to other, platform-specific graphics libraries. FWIW, I ran your last test with the current python.org 2.7.8 and 3.4.1 on OS X with the current ActiveTcl Tk 8.5.15 and they both performed identically: I expanded the frame to fill the screen and could cleanly move the slider to the left or right with no artifacts.