Recipe:
% ::Widget::theme 1;
% ::Button .b;
% .b configure
unknown option "-activebackground"

Ok, reverted the patch and did it the traditional way, e.g. remove all options which are in button and not in ttk::button. Commit [702ef20c55] Bug closed. Thank you, Harald

By E-Mail, I asked the original BWidget author (Eric Boudaillier) and he commented as follows:

I'm absolutely unsure if using ttk widgets for tkinclude will solve the problem. In fact, the "declare" part also defines options that are available only inTk widgets, and some widgets implementation probably relies on Tk widget options or commands.

As Adrian said in the ticket, using an alternate class for bwiget's wrapping Ttk widget will solve options incompatibilities defined in the options database.

I had a brief look.  The situation is quite unfortunate: BWidget's ::Button megawidget has "Button" as its class.  Exactly the same class as Tk's ::button widget.  When using a ::ttk::button as the underlying widget for BWidget's Button, the X resources for class Button get initialized to the Ttk's defaults.  Ttk's defaults for ::ttk::button are not compatible with Tk's ::button (and indeed ::ttk::button uses TButton as its class).

The issue here comes from two decisions BWidget has taken:

1) Use Tk's classes for some of its widgets (e.g. Button, Label).
2) Support Ttk for those widgets without changing the class.

I see no painless exit from this situation.

We could, for megawidgets that reuse the Tk's class from its underlying widget (e.g. Button, Label), change the class to Ttk's one when using the tiled widgets (i.e. TButton, TLabel).  (This assumes that reusing Tk's class was done on purpose in order to take advantage of resources for Tk's widgets for BWidget's ones.)  This will break applications using the option database to configure BWidget's widgets, but I argue that it should have always been part of porting to themed BWidgets.

Another option would be to cherry-pick defaults compatible with both widgets (using include, initialize, etc).  Core Tk has decided not to do this when tiled widgets were introduced; I'm not sure whether it's worth the effort or even whether it's possible.

Best regards,
Adrián.

Ok, thanks, closing bug.

Hello Harald,

indeed, it fixes the issue.  As far as I understand, this is the correct fix, as the -state option ends up being applied to the ttk::button, so it should "take inspiration" from it.  But I've been wrong before :-).

Thank you and best regards.

Adrián.

Thanks for the report.

Could you verify the fix in [987852ad44].

I have no idea about the side effects within the black magic of BWidget option handling...

-Harald