[Tile-dev] RE: scrolledw + :ttk::frame

[Jeff H. <je...@Ac...>]

Joe English wrote:
> Jeff Hobbs wrote:
> > I looked into the ttk::frame usage for the tklib widget package, but 
> > it's handling of -borderwidth / -relief is not consistent with 
> > tk::frame's.  It appears to be locked at 1/2 pixels, based on -relief, 
> > with -borderwidth essentially ignored.

> The current policy (which is not entirely satisfactory) is:
> (1) the ttk::frame widget honors any user-specified 
> -borderwidth when computing internal padding, but (2) the 
> Frame.border element may draw a thinner border if necessary.  
> Also, (3) the Frame.border element should make a best-effort 
> attempt to honor -relief, but it's allowed to substitute a 
> "morally equivalent" border in case the Motif style is 
> visually incompatible with the rest of the theme.
	...
> with an arbitrary thickness.  (For example, the Win32 
> DrawEdge() routine draws borders that are SM_C[XY]EDGE pixels 
> thick -- the caller doesn't have any say in the matter.)  Hence #2.

OK, it seems like this may be something that themed widgets may
simply not be able to handle.  Let me elaborate on what I use
the frame for commonly in tklib's widget package.

Frames are the best containers for megawidgets.  In general,
they are merely containers and are completely covered, but
sometimes they have parts exposed (as in the scrolledwindow
example when both scrollbars are visible).  Thus it would be
nice to have themed frames.

In the scrolledwindow though, it is common to want the
megawidget have the inset border so the widget and scrollbar
appear as one.  Thus you want the -bd/-relief on the frame
(sunken or solid, 1 pixel usually), not the interior widget.
This doesn't work with ttk::frame, at least not the XP theme.
Solid relief isn't supported at all, and sunken just isn't
"right".  I'm not sure how important it is to get this part
working though.

Jeff