Tcl - ANNOUNCE: TIP#262 Published

Author

ANNOUNCE: TIP#262 Published

Donal K. Fellows

2006-03-31, 8:02 am

The TIP editor is pleased to announce that

TIP #262: Background Images for Frames
http://tip.tcl.tk/262.html

has been published as a Project TIP targetting Tcl/Tk 8.5

Christopher Nelson

2006-03-31, 8:02 am

Donal K. Fellows wrote:
> The TIP editor is pleased to announce that
>
> TIP #262: Background Images for Frames
> http://tip.tcl.tk/262.html
>
> has been published as a Project TIP targetting Tcl/Tk 8.5

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.
There's no existing -image option to frame. It seems best to use the
same option name for the same feature on multiple widgets.

slebetman@yahoo.com

2006-03-31, 8:02 am

Christopher Nelson wrote:
> Donal K. Fellows 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.
> There's no existing -image option to frame. It seems best to use the
> same option name for the same feature on multiple widgets.

I agree. It should be .frame configure -image ...

Robert Hicks

2006-03-31, 8:02 am

I agree...it should be -image for consitency.

Robert

Donal K. Fellows

2006-03-31, 7:03 pm

Christopher Nelson wrote:
> 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.
> There's no existing -image option to frame. It seems best to use the
> same option name for the same feature on multiple widgets.

The original submission said that the new option should be called
-image, but I changed it because the interpretation of the option here
is quite at variance to the interpretation of -image in the other
widgets that use it (e.g. labels, buttons, etc.) Experience suggests
that keeping the names the same would cause immense problems for new
users, and it would definitely cause problems for those of us writing
the documentation! By calling it -backgroundimage, it's purpose is far
more immediately obvious. It also leaves open the possibility of adding
a -backgroundimage option to other widgets that already have an -image
option...

Donal.

Andreas Leitgeb

2006-03-31, 7:03 pm

slebetman@yahoo.com <slebetman@gmail.com> wrote:[color=darkred]
> Christopher Nelson wrote:

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 :-)

Christopher Nelson

2006-03-31, 7:03 pm

Donal K. Fellows wrote:
> Christopher Nelson wrote:
>
> The original submission said that the new option should be called
> -image, but I changed it because the interpretation of the option here
> is quite at variance to the interpretation of -image in the other
> widgets that use it (e.g. labels, buttons, etc.) ...

OK. I accept that the feature is different and we may want to add this
feature to other widgets later. Then I suggest that the comparison to
button's -image option be removed or rewritten as it draws an
inaccurate analogy.

Eric Taylor

2006-03-31, 7:03 pm

Andreas Leitgeb wrote:

>
> 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.

Good point. I often have frames within frames, which make
it much easier for me to use the pack manager. I also develop
using visual tcl, and so adding lots of nested frames is something
that I do rather often. If I understand your point, the
inner frames would obsure the outer frame which might be the
logical choice for where to add a single background image.

What if we also allowed an option for frame transparency. In this case,
I would think the inner frames would want to be flat with no
border. But that might not be handy for positioning nested packed
frames. Maybe we'd want an option to make a frame entirely
transparent, even if it had some inrternal and external borders.

The idea for a tiling option came from my attempts to use
a large image. I was trying to implement this idea using a
canvas and there was a wiki entry with some tiling ideas

http://mini.net/tcl/4389

I also wanted to imbed the image as text, like in this wiki article,
to avoid the need for any extra files to distrubute. While the
image was a reasonably small gif file, converting it to text
added many hundreds (possibly thousands) of lines of
text to the script. And it also was noticably slow at starup.

My intent was to be able to create a small swatch of background and
hopefully it would repeat nicely. I figured to use something
like photoshop to create some nicely tiled textures. Then it would
be a reasonably small -data set for the image.

Uwe Klein

2006-03-31, 7:03 pm

This is a can of worms.

Eric Taylor wrote:

>
> Good point. I often have frames within frames, which make
> it much easier for me to use the pack manager. I also develop
> using visual tcl, and so adding lots of nested frames is something
> that I do rather often. If I understand your point, the
> inner frames would obsure the outer frame which might be the
> logical choice for where to add a single background image.

what about .f.ff.fff configure -bg {} ?

if you set the bg before packing ...

uwe

Wojciech Kocjan

2006-03-31, 7:03 pm

On Fri, 31 Mar 2006 14:53:36 +0200, Donal K. Fellows
<donal.k.fellows@manchester.ac.uk> wrote:

> The TIP editor is pleased to announce that
>
> TIP #262: Background Images for Frames
> http://tip.tcl.tk/262.html
>
> has been published as a Project TIP targetting Tcl/Tk 8.5

I agree with -backgroundimage (and -bgimg shortcut), but I would call the
other option -backgroundmode - and options could be "single" (anyone has a
better name), "tile" or maybe "stretch" somewhere in the future.

Also, I agree with ability to specify offset (as {x y} or .widget.name).

--
WK

Donal K. Fellows

2006-03-31, 7:03 pm

Uwe Klein wrote:
> what about .f.ff.fff configure -bg {} ?

Currently, setting the background to the empty string stops a frame
widget from redrawing itself. This would be good, except that it really
means that what you see there is whatever was on the screen before,
often just random crud in practice. In other words, as options go it's
practically useless...

Donal.

Sponsored Links