Stupid tk scrollbar limit (OOPS - It's my fault)

Sometimes I love to complain.  I have been quite successful getting my ebe programming environment working.  It does a large number of editing tricks now.  I think I may have figured out most of how to use the tkinter Text widget.

Things worked great testing copy and paste until my file got over a couple of thousand lines long.  The scrollbar failed to work properly.


I found the source code for the insert code in python on the net and it simply passes the insert request into the tk code.  Then I found a cute test program at http://paste.tclers.tk/2464 listed here for convenience

set linecount 5000

. configure -width 600 -height 300
pack propagate . 0

set msg [canvas .msg]

set yscroll [scrollbar .yscroll -orient vertical \
                -command [list $msg yview]]

pack $msg -side left -fill both -expand 1
pack $yscroll -side left -fill y

for {set i 0} {$i<$linecount} {incr i} {
   append text "$i\n"
}
append text "The end"

$msg create text 0 0 -anchor nw -text $text

foreach {xmin ymin xmax ymax} [$msg bbox all] break
$msg configure -scrollregion [list $xmin $ymin $xmax $ymax]
$msg configure -yscrollcommand [list $yscroll set] \
                -scrollregion [list $xmin $ymin $xmax $ymax]

This code creates a text widget with the numbers 1 through 4999 followed by "The end".  However if you try to scroll to the end, you are limited to 2255 lines or so, depending on the size of the window.  The top line on the screen seems to be the actual limit which is 2187.

So I have a pretty functional IDE with a file size limit.  This is OK for educational purposes, but it is fundamentally stupid.  When you have a computer with 16 GB of RAM you would expect limits to be more reasonable - maybe 1 million lines of code.  But no, someone years ago when RAM was terribly expensive designed a tool with a  small limit.

I tried doubling the number of characters displayed by the limit test program and it remained with the same limit.  So it is not a buffer size limit, it is a number of lines limit.  The wish program didn't die or complain about the lines past 2255,  so I figure that the program probably doesn't have a problem storing the lines.  I am guessing that the scrollbar code is the problem.  1.0/2000 = 0.0005, so perhaps there is some sort of test on the size of the scrollbar itself. 

I don't yet know what I will do with this issue.  I don't want to migrate to a different python widget set.  Trying to predict my future I guess that I will replace this code with a QT program.  I expect that QT will have a more reasonable Text widget which I can control with large files.  For now I think I will set the limit at 2000 lines and post a message whenever a file is too large.  I just checked ebe with a file with 4496 lines.  I loaded it and saved it without changing it.  That means that ebe will allow editing and debugging on the first 2000 lines or so of a file while keeping the rest hidden.

I am suspicious that tk has a way around this issue, though the post in May 2011 had no replies.  I will spend a little more time to see if I can tweak the use of the scrollbar.

I just tried the idle IDE for python.  I created a file with over 4000 lines and it successfully scrolled.  Now it's time to review how idle handles its scrollbar.  There does seem to be a way past this confusion, though I do wonder why nobody helped the person with tcl code illustrating the problem.  There seems to be no special trick employed by idle to get part this problem.  I could try to copy parts of the idle code, though my frame has 2 Text widgets.  It will require some study.

Back again.  Idle is a gold mine!  I haven't quite decided to use it for its intended purpose, but it is a gold mine of sample python code.  I can figure things out, though it will take a little time to become proficient.

Well, after about 5 hours I have mostly conquered my problems with tk's Text widget.  I gave up on having a separate Text widget for placing breakpoints and arrow in.  Instead I will settle for a much more functional plain text region.  I will simply change the background color to red for the first character of lines with breakpoints.  I will also highlight the next line to execute with a nice color like a light cyan.  This will fit the design strategy of the Text widget better.  One immediate benefit (in addition to large files) is that I have eliminated the nagging flashing that I had developed in my ignorance.

Once again, it's all my fault.  I still don't know what to think of the sample code which seems to show a problem with tk.  At least I don't have much desire to rewrite this in QT.  There are more useful things to do.

I highly recommend reading some of the idle code for anyone building a GUI with a text editor in it.  There are some pieces which are a bit convoluted for my python skill level, but overall it is moderately easy to read given the job it does.  I will probably continue learning from it.  I did try editing with it, but I am far too used to vim.