Faster GUI text control

[none]

Hi,
I wrote a program for work that processed and formatted some
collected text data in a Tkinter based GUI display. I've found that as
my data files get longer (a few thousand lines), there seems to be a
real lag when it comes to clearing or updating the Text control, enough
so that the program just isn't useful. I poked around some and saw
several people mention that is was a known issue with Tkinter.
I'm trying to decide what is the best replacement for the control. I
was originally planning on redoing the GUI with wxpython, but I've seen
people indicate I would have the same problem. I also was looking at
Fredrik Lundh's widget construction kit info. That looks like it could
be useful, but it would still require building a new control and I'm not
sure if it would solve my base problem. I'm still pretty inexperienced
with Python, so I'd like to concentrate on using a working text control
and writing the data processor part of my program rather than writing
and debugging a text control to use. Does anyone have any
recommendations they could share? Thanks very much.

 

[Jeremy Bowers]

I'm trying to decide what is the best replacement for the control. I
was originally planning on redoing the GUI with wxpython, but I've seen
people indicate I would have the same problem.

Honestly, if this is important to you, the best thing to do is try all the
ones relevant to your platform; generally creating a window with a text
widget and loading it with "a whole lotta text", as appropriate to your
app, is fairly easy; it is not true that once you've tried one GUI toolkit
you've tried them all, but each one is easier than the last, and
generally, you can:

* Use the tutorial up to where they place a widget.

* Jump to the reference manual where they describe the text widget and
insert it instead.

* Fill the widget with a bunch of text. ("some string\n"*100000 or
something works well.)

* Start the program and go.

Not counting downloading, an hour each, tops. (The only tricky one that I
am aware of is that GTK insists that text widgets have to be in a Scrolled
Window to get a scrollbar on them.)

The problem is that if you're really looking for performance, it may
differ based on the characteristics of the text and the quality of the
target computer, the platform (which you don't mention; GTK may scream in
Linux and make you scream in Windows...), etc., and there may be no one
person who can give you a firm "This is the best solution for your
situation" answer.

 

[Paul McNett]

The problem is that if you're really looking for performance, it may
differ based on the characteristics of the text and the quality of the
target computer, the platform (which you don't mention; GTK may scream in
Linux and make you scream in Windows...), etc., and there may be no one
person who can give you a firm "This is the best solution for your
situation" answer.

Also, it must be said that thousands of lines of text in a GUI control
may not be necessary. Do the users really need to be able to scroll
through that much text all at once in the general case, or do they
perhaps only ever need to see the last few dozen lines? Could they
instead "page" through the text in swallowable morsels, say a couple
hundred lines at a time?

Python can handle gargantuan amounts of text with little noticable
performance penalty, while GUI controls aren't necessarily designed for
that. What I'm getting at is that you could still have the entire string
in memory, but only feed portions of that string to the GUI text control
at a time.

I'm jumping in here - perhaps the OP already told us what the
application is, but I'm curious why it is necessary to have thousands of
lines displayed and editable all at once, and wonder if the design
should be reconsidered. I know that native Windows controls in
particular tend to get really squirrly and unpredictable once you push
into thousands of lines.

 

[Fredrik Lundh]

several people mention that is was a known issue with Tkinter.
I'm trying to decide what is the best replacement for the control. I
was originally planning on redoing the GUI with wxpython, but I've seen
people indicate I would have the same problem. I also was looking at
Fredrik Lundh's widget construction kit info. That looks like it could
be useful, but it would still require building a new control

no, it would mean writing some python code. if all you need is a scrolling
text list, you can simply use the code on this page:

http://effbot.org/zone/wck-4.htm

(see "A scrollable list view, with scrollbar support" and, optionally,
the virtual data modifications under "Displaying Huge Data Sets")

the resulting widget will update at constant speed, independent of the
data size.

</F>

 

[none]

no, it would mean writing some python code. if all you need is a scrolling
text list, you can simply use the code on this page:

http://effbot.org/zone/wck-4.htm

(see "A scrollable list view, with scrollbar support" and, optionally,
the virtual data modifications under "Displaying Huge Data Sets")

the resulting widget will update at constant speed, independent of the
data size.

</F>

Thanks for the suggestion. I looked at that, but I need to be able to
selectively change colors on parts of the text and I didn't think I
could do that with a list box. Am I misunderstanding that?

 

[none]

That's a good point about the amount of text available at once. As
long as I could swap the visible section fast enough that might be a
good solution.
This will run mostly on Windows, but I'd like for it to be equally
usable on Linux.

 

[Fredrik Lundh]

Thanks for the suggestion. I looked at that, but I need to be able to
selectively change colors on parts of the text and I didn't think I
could do that with a list box. Am I misunderstanding that?

yes. the list view isn't a listbox, it's a new widget.

with the list view, you control the drawing yourself, and can draw things
in whatever way you want. (the section "Non-Standard Rendering" talks
about this; reading http://effbot.org/zone/wck-3.htm also helps).

</F>

 

[none]

yes. the list view isn't a listbox, it's a new widget.

with the list view, you control the drawing yourself, and can draw things
in whatever way you want. (the section "Non-Standard Rendering" talks
about this; reading http://effbot.org/zone/wck-3.htm also helps).

</F>

Thanks for the clarification. I'm going to go back and read the
"Writing widgets" articles in detail.

 

[Cameron Laird]

Honestly, if this is important to you, the best thing to do is try all the
ones relevant to your platform; generally creating a window with a text
widget and loading it with "a whole lotta text", as appropriate to your
app, is fairly easy; it is not true that once you've tried one GUI toolkit
you've tried them all, but each one is easier than the last, and
generally, you can:

* Use the tutorial up to where they place a widget.

* Jump to the reference manual where they describe the text widget and
insert it instead.

* Fill the widget with a bunch of text. ("some string\n"*100000 or
something works well.)

* Start the program and go.

Not counting downloading, an hour each, tops. (The only tricky one that I
am aware of is that GTK insists that text widgets have to be in a Scrolled
Window to get a scrollbar on them.)

The problem is that if you're really looking for performance, it may
differ based on the characteristics of the text and the quality of the
target computer, the platform (which you don't mention; GTK may scream in
Linux and make you scream in Windows...), etc., and there may be no one
person who can give you a firm "This is the best solution for your
situation" answer.

The known Tkinter symptoms, incidentally, have more to do with
*removing* content from a text than adding them. Any exercises,
therefore, should not only load data into a text or near-text,
but also remove them.