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

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

Damon Courtney wrote:
> > 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 

I have commited my BWidgets changes that reflect tile
"awareness".  There are likely more fixes to come, but I
haven't even made them yet (like BWidgets dialogs need a
platform-awareness overhaul).

> we go a different route with this?  Turning on Ttk support in 
> BWidgets goes like this:
> 
> BWidget::use ttk

Mind you, I added (not documented):
	Widget::theme ?bool?

I don't mind the above either, but perhaps 'theme' instead of
'use' is better?  That way it can default to classic or something.

>     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]} {

I have done some stuff like that, see font.tcl, statusbar.tcl
and scrollframe.tcl.  Those are only ones I used, but others
could be updated.  In some cases though, you just have to
punt/abort/port.  For example, if you use the BWidgets
ComboBox, then you should just replace it with a ttk one and
figure out the options changes.

>     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 

Again, I'm against this due to the enhanced possibility of
bugs (as my previous Entry -vcmd example).

Jeff