[Tutor] Dynamic TKinter widgets?

Nathan sdragon1984 at gmail.com
Mon Nov 26 02:10:53 CET 2012


On Nov 25, 2012 6:49 PM, "ALAN GAULD" <alan.gauld at btinternet.com> wrote:
>
> CC'ing the list...
>

Oops, my bad. I forget to hit Reply All.

>>
>> I know you can use images instead of text with Labels, like you can with
Buttons.
>> The advantage of a Text widget, in this case, is that you can use both
in the same widget.
>> That way, I don't need to worry about how widgets are displayed,
shuffled around, and
>> undisplayed during runtime. One widget should handle everything.
>>
> Don't get hung up on the number of widgets. In the scheme of things
widgets are not
> expensive. Create them as you need them, delete them when you are done.
Layout
> managers are there to manage the layout for you. if you can define the
layout in terms
> of a grid then you can fill the grid with blanks to hold the shape and
add/remove
> widgets as you like.
>
> If you use pack you can either force the containing frame to a fixed size
or allow it
> to grow/shrink with the widgets. Either approach can work.
>>
>> This is standard? That's interesting to know. The biggest issue I'm
having here is scalability.
>> Each new spread is going to need a new frame widget, which in turn will
need
>> (number of cards in spread)*2 more widgets.
>>
> But that's how many? If its getting up beyond a couple of thousand then
you might
> have a problem. If its less than a hundred its not an issue. In between
you might want
> to be a bit clever.

Well, that depends entirely on how many spreads I'll eventually have, and
the average number of cards per spread. Celtic Cross, for example, is a ten
card spread, so it needs 21 widgets by itself. A hundred widgets is reached
with just 10 spreads averaging 4.5 cards each. I expect, ultimately, to
have more than that.

>>
>> As noted above, the Text widget solution only needs one.
>>
> Actually it probably needs more. Each image is a widget too, so you just
organise
> the widgets inside a Text instead of inside a Frame or Canvas.

Is that how it works on the source level, or "under the hood"? The code
makes it look like I'm only writing one widget, with multiple text and
image elements within it, but perhaps I'm misunderstanding something.

The approach I'm taking now is a Label widget, containing a single string
constructed with elements from lists. I'm hoping that I can take the same
approach using a single Text widget, and just convert every other string
element from a filename to an image.

>All these things are
> just containers for more widgets. Frames are designed to hold widgets,
end of story.
> Text is designed to *display* images and text - usually within a Frame.
Canvas is
> designed to *display* images and graphics shapes. If you want your images
joined
> or surrounded by lines/circles etc then go with Canvas. If you need to
include
> explanatory text around the images use a Text. If you want to create a
reusable
> widget that you can use in multiple screens or hot swap with other
variants of
> the same go with a Frame and build a display widget hierarchy. If you
just want to
> display a bunch of images it doesn't matter much which one you pick.
>

Then it seems Text it is. Perhaps later in development, Frames and/or
Canvases might be appropriate for more complex designs.

> I repeat, don't sweat over the widget count, that's not usually an issue.
>
> Alan G.
>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20121125/8e4628b8/attachment.html>


More information about the Tutor mailing list