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.

I'll take this on.

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 ;-).

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!

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.

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()

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.

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. :\

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

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.

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()

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

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.

Oh I had no idea! That makes sense. How do I know which version of Tk I'm working with? I'm testing on Mac OSX as well!

Would there be anyway for you to test my patch for turtledemo to see if the sash causes artifacting for you? I see tearing but it snap back into place within less than a second, which doesn't seem that bad.

Stuttering might be a better term. For the initial small window, I did not see much difference between 2.7 and 3.4. At full screen on a 25xx x 14xx screen, both stuttered. If the 2.7 looked better, it is because it redrew slower. If I zipped the mouse fast enough, the border temorarily disappeared instead of being repeatedly redrawn. But full-screen empty panes were not as bad as the quarter-screen demo with each pane full. From Ned's comments, Windows simply does not handle this operation as well as Mac.

The left.pack and right.pack statements are not needed as left and right are 'add'ed to the PanedWindow.

The easiest way to expose more text is to enlarge the Window with the text frame heavily weighted. This would allow people with big screen to grab the right edge, pull, and leave the window with both text and canvas fully exposed. With ttk (but apparently not tk), the panes can be weighted.
paned.add(left, weight=10)
paned.add(right, weight=1)
(To 'compensate', showhandle seems to have been deleted for ttk.)

The same can also be done with grid. The advantage of using the paned window is to give more flexibility to people with small screens, who cannot view both text and canvas simultaneously. However, I am not sure about the acceptibility of switching to ttk, especially before 3.5. Perhaps I should ask on pydev.

I feel like the PaneWindow is nice. I could also see down the road making the code text bigger.

However, if on Windows, the artifacting is really bad, I can totally switch this back to the grid view.

If we can use the weighted ttk paned window, so sash movement is only used when really needed (small windows) then it would be ok. (I would add a note in one of the help texts -- "On some systems, there are visual artifacts when enlarging the window or moving the sash. We feel this is preferable to having to scroll a too narrow text window.") There is some stuttering when enlarging the window, but if only done once, it is not a big deal.

Lita, to find the detailed Tk version info (which is really important with 8.5 since it has changed considerably over its long life):

>>> import tkinter
>>> t = tk.Tk()
>>> t.tk.call('info', 'patchlevel')
'8.5.15'
>>> t.tk.call('tk', 'windowingsystem')
'aqua'

http://www.tcl.tk/man/tcl8.5/TclCmd/info.htm
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm

Terry,

I don't have a physical Windows machine but I fired up a Windows 7 virtual machine and, again, with the stock python.org 2.7.8 and 3.4.1, the test in msg222301 works just fine for me. I also tried it on a relatively current Ubuntu Linux VM and its fine there, too. All of these were using either Tk 8.5.15 or 8.6.1 and they all work the same. For any kind of Tk work, one needs to be using recent versions of Tk, ideally 8.5.15 or 8.6.1. But this is pretty basic stuff. I don't know why there why a current Tk would not be able to render this perfectly, unless it was being run on *really* old hardware/graphics, or possibly if one were trying to run this under IDLE rather than standalone.

Oh man, I was running version '8.5.9' using 'aqua'. I am going to try and upgrade and see if the artifacting goes away.

Lita

Lita, testing the second turtledemo_pane.patch (2014-06-09) with a current default (pre-3.5) build and with OS X ActiveTcl 8.5.15: if an example is selected but not running, moving the slider to the left is fairly smooth but the scroll bar for the right frame tends to also move to the left while the slider is moving, then settles back to the right side of the window when the slider motion stops. When moving the slider to the right, the right side of the outline rectangle of the left frame tends to lag behind the slider and then catches up to the slider when motion stops. Both the left and right lags are slight (IMO) but noticeable. I tried moving the slider while running a couple of demos and, as could be expected, the overall response is a little jerky as the demo graphics get redrawn but it didn't look bad to me. The OS X Tk 8.4.20 was pretty similar. With the OS X X11-based Tk (8.6), there were more noticeable sections of a darker background that would briefly appear to the right in the right frame when moving the slider to the left. (I did not try the patch on virtual machines.) All in all, I think having the resizable frames is a usability improvement, even if the resizing is not 100% smooth on all platforms.

Hm, when I upgrade to 8.6, I still get the tearing action on the very right of the window. Although, again, it doesn't seem that bad. I've attahed what I am seeing, just to confirm we are all talking about the same thing.

Lita, the movie looks comparable to what I'm seeing but without the background colors and with thin-lined black border rectangles around each of the two frames.

Yes! This is the first version of the code without using ttk widgetd. Using Labels instead of buttons.

'under Idle' here means in a separate process with its own tk loop. I tried from the cmd line and see the same. My 3-yr-old machine has what was then a top-of-the-line Pentium. Also, as I said, the test code works much better than the 6/09 patch with widgets in the frames. Perhaps the demo would work if the two scrollbars and main widget were in a 2x2 grid, with the lower left or right cell left empty, instead of packed.

"Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file." However, Ned's description matches what I see, including the detail about a frame being momentarily being pulled away from the outer edge.

Hey Terry,

So the reason why the tearing is a lot slower in 06/09 patch is because the canvas is using the turtle.ScrolledCanvas widget. Everytime the window resizes, it is calling a callback to onResize -> adjustScrolls to update the scrollbars. When I comment out that binding in turtle.py (line 358) it still tears, but it snaps back a lot quicker.

The main widget is already a 2x2 grid (ScrolledCanvas). I tried just returning the ScrolledCanvas, but that didn't work either.

I will try to ask in stackoverflow tomorrow and seeing what they say!

I also put this patch out there. This doesn't have the PaneWindow, but I manually widen the text pane. This would be the compromise if I can't figure out the tearing due to the sash moving.

?! After debugging for awhile, I got it so that PanedWindow doesn't cause the rightmost widget to tear! I had to disable the resizing binding on Turtle to make it work.

However, now it seems like the canvas is no longer centered. Is there anyway for me to get around this? Maybe I disable the binding on the demo side and re-adjust the center when we initialize the canvas?

I want to make sure it works for you guys first before digging into it.

Lita, turtledemo_pane_srcoll_fix.patch definitely solves the "tearing" problems (when viewed with OS X Cocoa and X11 Tk's): yay! Good luck with getting the centering working!

!!!!

I think I have a fix!! I made it so that centering works while fixing the tearing.

For some reason, in the Turtle API, the adjustScrolls method creates a new scroll widget for x and y and deletes the old one. I am not sure why it does it this way. I'm sure there is a reason for it though.

For the demo, I overwrote the onResize method so that it centers canvas but doesn't instantiate a new scroll widget and throws away the old one, which fixes the tearing!

I would love for someone to review the patch. Thanks!

Great improvement. Full screen on my system, the artifact ghosting band is about 1/4 inch, as with the empty panes, instead of several inches, as it was in the original patch moving right to left. This worst-case (Windows) behavior is good enough to commit when I recover enough from a minor eye injury to read and review the actual code.

The one thing I think this patch still needs is a notice to the user that the sash can be moved. Once place is one of the help files. I can do that. Can we also put a line in the text box on startup?
"Change text pane width by moving the divider ==>"

With wider text panes, the tiny font, which is too small for my less than perfect, uninjured, 'normal' vision, is no longer necessary. Lita, feel free to open another issue and start on a patch. I think the best option be to have control-mousewheel change size, as is standard in browsers. (And add help text.) If tk has a problem with that, a second choice would be a menu entry "Font size with choices such as the current size (9?), 10, 12, 14.

The one thing I think this patch still needs is a notice to the user that the
sash can be moved. Once place is one of the help files. I can do that. Can we
also put a line in the text box on startup?
"Change text pane width by moving the divider ==>"

Is that really necessary? Adjustable dividers like that have been a standard user interface element on desktop applications for a long time. I would expect most users to be surprised to find that it didn't adjust. And Tk, at least on the OS X ones I tried, provides a visual clue that the frame is adjustable by changing the cursor to a 2-headed arrow when mousing over the slider. Adding something to the help files is sufficient, I think.

I don't really know what most beginners will expect. Perhaps an entry in the help will be enough. I would like have a better how to use summary at the top of the file anyway.

If I swish the normal cursor across the divide, it jumps from I-bar on text side to arrow on canvas side without even displaying the two-headed arrow. Checking with a magnifying glass, I have to pause the cursor in the 3 pixels wide gray shadow of the solid black line*. (The And even then, the cursor does not always switch. Since this patch does not use ttk, I will try 'showhandle=True' and see how it looks and behaves.

The shadow is not normal for Windows divider lines. It would be better is if could be turned off. The 'sensitive' zone of about 3 (maybe 4) pixels to the right or under the line seems to be normal.

Hi Terry,

So the shadow can easily be removed. I just went with the default sashrelief style. I am going to attach two patches with different sashrelief styles, both of which don't have the shadow.

I personally like the FLAT look because it matches with the rest of the GUI.

Ping! Just wanted to see what the status was on getting this patch reviewed. I hope your eye is feeling better, Terry!

For me, FLAT is about as mushy as the default, while SOLID actually looks like a divider. I find the sash easier to 'grab' and move. I plan to go with that. If it looks substantially worse on some other system, we could make the argument conditional on sys.platform or whatever.

I plan to do a 'final' review in the next day and either commit or post a revision for testing on non-Windows systems.

I reviewed code and made the following changes in uploaded file:
Move some code and blank lines around.
Since you left packing within mBar frame, removed
self.mBar.grid_columnconfigure(0, weight=1)
Since the only thing packed in the left frame was the text frame, renamed makeLeftFrame to makeTextFrame, removed the left frame and returned the text frame to be gridded directly. Works fine.
Remove left_frame, graph_frame temporaries.

The questions that stopped me from pushing this are about the following lines in makeGraphicFrame.

        self._canvas = turtle.ScrolledCanvas(root,
                                             800, 600,
                                             self.canvwidth, self.canvheight)
        turtle._Screen._canvas = self._canvas #*
        turtle._Screen._canvas.adjustScrolls()
        turtle._Screen._canvas._rootwindow.bind('<Configure>', self.onResize)
        turtle._Screen._canvas._canvas['borderwidth'] = 0
        turtle._Screen._canvas.grid(row=0, column=0, sticky='news') ##
        ...
        return  turtle._Screen._canvas

It seems that in all lines except #*, 'turtle._Screen._canvas' could be replaced by 'self._canvas' or even a 'canvas' temporary. The ## line seems wrong, as the parent is root and 0,0 is not where the canvas shoud be gridded and indeed not where it is gridded after being returned. The demo seems fine after commenting out the line. So it seems that the following should work.

        self._Screen._canvas = self._canvas = canvas = (
                turtle.ScrolledCanvas(
                root, 800, 600, self.canvwidth, self.canvheight))
        canvas.adjustScrolls()
        canvas._rootwindow.bind('<Configure>', self.onResize)
        canvas._canvas['borderwidth'] = 0
        ...
        return  canvas

Am I missing something? Just curious, what is the <Configure> event? Or rather, what generates it?

On Tue, Jul 22, 2014 at 8:20 PM, Terry J. Reedy <report@bugs.python.org>
wrote:

Terry J. Reedy added the comment:

I reviewed code and made the following changes in uploaded file:
Move some code and blank lines around.
Since you left packing within mBar frame, removed
self.mBar.grid_columnconfigure(0, weight=1)
Since the only thing packed in the left frame was the text frame, renamed
makeLeftFrame to makeTextFrame, removed the left frame and returned the
text frame to be gridded directly. Works fine.
Remove left_frame, graph_frame temporaries.

The questions that stopped me from pushing this are about the following
lines in makeGraphicFrame.

    self.\_canvas = turtle.ScrolledCanvas(root,
                                         800, 600,
                                         self.canvwidth,

self.canvheight)
turtle._Screen._canvas = self._canvas #*
turtle._Screen._canvas.adjustScrolls()
turtle._Screen._canvas._rootwindow.bind('<Configure>',
self.onResize)
turtle._Screen._canvas._canvas['borderwidth'] = 0
turtle._Screen._canvas.grid(row=0, column=0, sticky='news') ##
...
return turtle._Screen._canvas

It seems that in all lines except #*, 'turtle._Screen._canvas' could be

replaced by 'self._canvas' or even a 'canvas' temporary. The ## line seems
wrong, as the parent is root and 0,0 is not where the canvas shoud be
gridded and indeed not where it is gridded after being returned. The demo
seems fine after commenting out the line. So it seems that the following
should work.

    self.\_Screen.\_canvas = self.\_canvas = canvas = (
            turtle.ScrolledCanvas(
            root, 800, 600, self.canvwidth, self.canvheight))
    canvas.adjustScrolls()
    canvas.\_rootwindow.bind('\<Configure\>', self.onResize)
    canvas.\_canvas['borderwidth'] = 0
    ...
    return  canvas

Yes! I like this a lot better. turtle._Screen._canvas was how the canvas
was being manipulated before. I was trying to follow the original
programmer's convention, but that works perfectly!

Am I missing something? Just curious, what is the <Configure> event? Or
rather, what generates it?

The Configure event is triggered when the widget changes size. It is super
confusing. Look for '<Configure>' in the documentation here:

http://effbot.org/tkinterbook/tkinter-events-and-bindings.htm

I had to override Turtle's onResize metbod because the canvas wasn't
centering properly when the sash was being moved.

----------

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue21597\>

---

Just to clarify, should I submit a new patch with outlined style changes?

New changeset 60301b9982b2 by Terry Jan Reedy in branch '2.7':
Issue bpo-21597: Turtledemo text pane can now be widened to view or copy complete
http://hg.python.org/cpython/rev/60301b9982b2

New changeset 0fb515063324 by Terry Jan Reedy in branch '3.4':
Issue bpo-21597: Turtledemo text pane can now be widened to view or copy complete
http://hg.python.org/cpython/rev/0fb515063324

No, I believe this is done ;-). Onward to font sizing.
Thank you for the hard work on this. It is a great improvement.

Sweet! Thank you so much, Terry!

On Wednesday, July 23, 2014, Terry J. Reedy <report@bugs.python.org> wrote:

Terry J. Reedy added the comment:

No, I believe this is done ;-). Onward to font sizing.
Thank you for the hard work on this. It is a great improvement.

----------
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed

---

Python tracker <report@bugs.python.org <javascript:;>>
<http://bugs.python.org/issue21597\>

---

Lita, when replying by email, please, please delete the message you are replying to (except possibly for a directly quoted line or two).

Sorry about that!! Thanks for letting me know.