Faster GUI text control

Cameron Laird claird at lairds.us
Mon May 16 16:08:03 EDT 2005


In article <pan.2005.05.14.04.20.18.359033 at jerf.org>,
Jeremy Bowers  <jerf at jerf.org> wrote:
>On Fri, 13 May 2005 15:44:24 -0500, none wrote:
>
>>   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.

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.



More information about the Python-list mailing list