From: Harald O. <Har...@El...> - 2009-08-05 09:33:36
|
Koen, Thank you contributing. The one Widget::_theme variable may be replaced by widget names or other mechanism, this is IMHO no issue. The issue is IMHO just the raising complexity to support tk and ttk by one set of code. Making a new CWidget (O-T-BWidget) packet is anyway a todo to support oo and ttk. But this is not the aim at the moment. Koen Danckaert schrieb: > Another option is to simply add some files to the current BWidget > sources, to support ttk. For example, there is scrollframe.tcl, and you > could add a tscrollframe.tcl file which uses ttk widgets. This has the > advantage that tk bwidgets and ttk bwidgets can be used in the same > application, which would not be possible in your proposal. (And which is > not even possible in the current half-working approach, since there is a > single global BWidget::theme variable). > > Of course, this is not possible if you want (or need) to rewrite the > complete framework (in widget.tcl). But in that case, maybe it would > even be better to start from scratch and make a new CWidget package... :-/ > Harald Oehlmann wrote: >> it is planed to branch BWidget into two source trees: >> - BWidget - use tk8.1 and later, no ttk code >> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code >> >> Why two source trees ? It is a real split of scope. >> BWidget is complicated enough. To support ttk and tk, many code will be >> doubled. In addition, I don't want to drop tk8.1 compatibility, but many >> things just would be more elegant and some work-arounds will go away. |