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

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

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

OK, good use case.  This is something the ttk::frame ought
to support.  

But there's a lot of platform variation that isn't accounted
for by -relief and -borderwidth alone.  On Windows, you
get slightly different borders with DrawFrameControl() than
you do with DrawEdge().  The former is used for things like
pushbuttons, the latter for editable fields and other things,
including most scrolled windows.

You can see the difference between the two if you compare
a ttk::entry with a core entry in the "winnative" theme --
Tk_Draw3DBorder on Windows draws (something similar to)
a DrawFrameControl-style border, which doesn't look quite
right for entry widgets.  Also compare ttk::button borders
with ttk::entry borders in the Tile "alt" theme, there's
a similar difference there (though the "alt" theme uses
3-color borders, and Windows post-98 uses 4-color borders).
Under Luna, editable fields use a 1-pixel thick solid border
instead of the 2-pixel 3-D sunken border, and under Aqua, 
things get even fuzzier (literally).

Borders are a lot more complicated than they look :-(

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

Just checked in some code that handles -relief solid on Windows,
this works better now.  Right now you still always get a 2-pixel
border regardless of -borderwidth; I've got an idea for how to make
-borderwidth 1 and -borderwidth 0 work too.

But I'm puzzled that -relief sunken doesn't look right --
the ttk::frame should be doing exactly the right thing here
(where "right" == "like other Windows 2K apps").


--Joe English

  jen...@fl...