ANNOUNCE: TIP#262 Published
Donal K. Fellows
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
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.
sleb...@gmail.com
I agree. It should be .frame configure -image ...
Robert Hicks
Robert
Donal K. Fellows
> 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
> 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 :-)
Christopher Nelson
> 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
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
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
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
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
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
> 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.
Eric Taylor
I have started a wiki page so some images could be posted
along with the code that would be used to generate it.
I'm considering proposing a -transparent option for frames as well, and
this wiki entry shows how this might look.
Eric
aldo.b...@tiscali.it
* Wiki page: Paved widgets
http://wiki.tcl.tk/13415
If you want to jump directly to the start page (with some screenshots),
see
* Paved-widgets - 1.1
A collection of standard widgets with paved (tiled) background
http://web.tiscali.it/irrational/tcl/paved1.1/doc/index.html
and in paricular for paved (tiled) frames, see:
* transforms an existing frame widget in a Paved::frame
http://web.tiscali.it/irrational/tcl/paved1.1/doc/index.html
What is worth noting is that with this package, you have two options:
A) create a new (paved) frame
B) transform an existing frame in a paved frame
Here is short sample ..
# creates a standard frame
frame .f -bg red
pack .f -expand true -fill both
# enlarge the window
wm geometry . 200x200
package require Paved::frame
# suppose xyz.gif is in current directory
# get the original frame .f and transform it in a paved-frame
Paved::frameAdaptor .f -tile xyz.gif
Aldo Buratti
Eric Taylor
surfaced, including using a canvas instead of a frame. In fact, after
some experimenting, I can't see what a frame could do that a canvas
cannot also do.
The one idea that did surface was the idea of transparency, and I
was wondering if a Paved::frame can be made transparent?
The reason I ask is that I often use heavily nested frames to
make placement (using pack manager) much easier. The idea
of having a transparency setting for a nested frame came up.
In the example paged widget demo, it shows 2 widgets over
a background image (looks like wood paneling). One is a text label
and the other is a button (close). So you have
label
button
Suppose later, I wanted to have 2 buttons so it would then become
label
button1 button2
The way I would do this would be to enclose the 2 buttons inside
a new frame and then setup the buttons to be side left, expanded etc.
In this trivial case, the grid manager might do the job w/o needing
any nested frames, but pretty soon the only way to construct something
a bit more complex would be by using nested frames.
Would these 2 buttons, now inside a frame hover over the wood
panelling outside with this added frame being completely invisible
(suppose it has a border size of zero) or would it too have to
have an image. And if it did, how would it line up with the outer image?
I was also thinking that a setting of -transparency with a float argument
would also allow for semi-transparency, assuming the underlying system
(windows, mac, unix) would probably be able to do this if it could do transparency
at all. Lots of neat effects could be implement with semi-transparency.
thanks
Eric
aldo.b...@tiscali.it
officially support a trasparent background, but this **does not work**
(at leat on my WinXP - Tcl 8.4.12).
You can try:
# ---------------------------------
toplevel .z -bg red
frame .z.f -bg yellow
# pack the frame over the toplevel, leaving a 20 pixel margin
pack .z.f -padx 20 -pady 20 -fill both -expand 1
# now comes the magic: set the frame bg transparent ..
.z.f configure -bg ""
# Unfortunatelly this does not work; if you try to resize the window,
# ugly effects appear ...
# ---------------------------------
I don't know the behaviour on other platforms, but on Windows XP it is
simply unusable.
The idea of a "transparent color" simply named "" is nice (elegant),
but I fear that a working implentation could be hard to achieve.
Regarding Paved::frame (and other Paved widgets), I can tell you that
they *cannot* handle transparency.
Simply, you can't achieve widget transparency with pure-tcl code, and I
agree with you ; it is a pity !
Some weeks ago, I posted a question, or better a challenge:
"Tk widgets with transparent background ?"
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/72f0936513ed7413/ba73a5c5d5203858
but the solution is still so far ..
Aldo
Eric Taylor
> 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.
>
And with reading the thread you mentioned, it seems I have been following
the trail you have been blazing :)
Interestingly, some other writers on the core programming list seem to think
that total transparency is not as difficult is it sounded in that thread. Some windows
and macos people seem to think they know how to do it.
I figured that if we were going to add a transparency option, then we ought
to give it a float for an argument, with 0. and 1. for opaque/transparent. Then
if someday, someone figures out how to get the semi-transparency, existing code
would not break and fractional values could be interpreted as a percentage of
transparency, while for starters, the value could simply be rounded to 0 or 1.
Well, at any rate, at least the subject of transparency seems to keep coming up as
a natural solution to various needs. Maybe another TIP on just transparency would
help. BTW, I submitted mine w/o any demonstration code (besides, I couldn't
program at that level even if I wanted to).
Cheers,
eric
MH
Eric Taylor <e...@rocketship1.com> wrote:
>Donal Fellows commented on this -bg "" option as follows:
>
>
>> 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.
That's good to know - we have QT updating a Tk frame, and this got rid of
any conflict between the two..
Thanks for the tip!
MH
Donal K. Fellows
>That's good to know - we have QT updating a Tk frame, and this got rid of
>any conflict between the two..
You found a use for the -bg "" oddity? Wow!
Donal (genuinely surprised).
MH
Ok, well, maybe it wasn't an issue anyway.. But, we ARE using this to
hopefully remove any attempt by Tk to update the frame's background..
And it's working quite well..
MH
George Peter Staplin
I once wrote a project called Tk_Theme that had a theme:frame command.
(now deceased because of Tk being unportable and some other reasons) It
supported exactly this feature and was very quick in X, because it used
Tk_SetWindowBackgroundPixmap. If you set widgets that are children to
have the ParentRelative pixmap then all children will have the proper
appearance. It's a shame that in Windows and the Mac Tk just has an
empty function in place of
Tk_SetWindowBackgroundPixmap/XSetWindowBackgroundPixmap. I asked if
this could be fixed ages ago on the tcl-core mailing list, and no one
was interested. I think the core team too lacks the knowledge of how to
fix it. :(
-George