Re: ANNOUNCE: TIP#262 Published

slebetman@xxxxxxxxx <slebetman@xxxxxxxxx> wrote:
Christopher Nelson wrote:
The TIP says:
Just a there is an -image option for button widgets, this TIP
suggests that a -backgroundimage option for frames be
implemented.
While I think that the feature is a great idea, I don't understand why
we'd have a different name for the option if it does the same thing.

I don't think so. The button's image is displayed once, on
some defined position (relative to the text), and can thus be
clearly seen as belonging to the widget's "foreground"

The frame's proposed image-feature would be a background-image
with quite different semantics.

I'm not very happy with the second option "-tile": it might
confer some connection to ttk (the "tile" widgets), which
I think is not meant. Also, IMHO a single background image
is not the job of a frame (use a label instead).

How will the (repeated) background image cope with a border?
e.g. for "-bd 10 -relief groove" would it shine through the
border, or be overdrawn with it? (for -bd 0 this is of
course moot)

Rather than a tile-option, I'd have an -bgoffset option,
that takes either x,y-offsets or the name of some
ascending widget (up to toplevel), on whose origin
the repeating images are "anchored". This would make
it possible to have sibling-, cousin- etc.-frames
have a consistent background.

Oh! And finally, I'd like an abbreviation -bgimg
for -backgroundimage.

PS: finally I wonder about the usefulness of a background-image
specifically for frame-widgets. To me it feels like one by one
each widget would then start to need a bgimage, and then we've
almost reached ttk :-)

.

Quantcast