Re: [Tile-dev] Heads up -- upcoming changes

[Damon C. <dam...@tc...>]

> Release 0.7.0 will follow shortly afterwards.  This is when
> all the BWidget compatibility hacks will be removed.  Hopefully
> by that time there will have been a new BWidget release with
> Tile integration done right (Damon?  Any progress on that?)

    The new BWidget release should be hitting a beta pretty soon here. 
Jeff said he had some stuff to commit, and I need to get his in and
call a freeze before merging all of my stuff.  Now that I have a clear
roadmap for Ttk, I can make all the needed modifications to BWidget to
finish off the support.  After the first iteration, some of the
options still look at Tk resources for their values, which was fine
when Ttk was still including dummy options, but now that they're going
away, I need to make sure BWidget's use of them does too.

    As far as Ttk support in widgets goes, I have some basic stuff going
on that should work decently well, but it basically mimics some of the
(unwanted?) behavior that Ttk has now.  Like a Button, for example,
has a new -style option that will pass on to Ttk, but it still has all
the rest of the options that just don't do anything.  So, you can do:

Button .b -background white -foreground black -style Style

    And if you're using Ttk, the style option does something while the
other two do nothing, but if you're not using Ttk, the style option
does nothing and the other two do.  Should we go a different route
with this?  Turning on Ttk support in BWidgets goes like this:

BWidget::use ttk

    Should we use this to redefine the widget classes?  Should the Button
class only inherit the options for what it's actually using?  IE:

if {[BWidget::using ttk]} {
    ## Define Ttk options for the button class
    Widget::declare Button ...
} else {
    ## Define using normal options.
    Widget::declare Button ...
}

    I, personally, kinda' like having the options dummy'd out in BWidgets
because it lets BWidgets become a bridge between Tk and Ttk.  I can
specify all of my options including a style, and if I've chosen to
turn on Ttk support for this platform, it will draw using Ttk, and if
I've chosen not to turn it on, I don't have to rewrite anything.  The
BWidget Button will just do the right thing.

    Opinions?  Jeff?

> [ Explanation: (1) is why the contents of [ttk::notebook]s don't
>   look right on Windows XP, and why nothing really looks right
>   under OSX.  (2) is why Tile still doesn't have native-looking
>   scrollbars in the aqua and tile-qt themes.  (3) is why e.g.
>   a ttk::frame inside a core toplevel often have different
>   colors on X11.   (3) is almost solved; (1) and (2) still
>   have me stumped. ]

    For "The Scrollbar Problem," couldn't you just accept that themes like
OS X and KDE don't want you to draw element-by-element and just draw
them as one, big thing when using those themes?  If I understand
correctly, the problem is that OS X and KDE provide APIs to draw
entire scrollbars but not smaller elements within them, right?  So, if
the user has chosen a theme with that limitation, just draw it that
way.  How many people fiddle with the damn scrollbars anyway?  I don't
think I've ever changed a scrollbar option outside of -orient.

Damon