Re: [Tcllib-devel] BWidget Revitalization... progress report 25.08.09

[Harald O. <Har...@El...>]

Hello Johann, Hello Jeff, Hello Community,

I want to welcome Johann Oberdorfer who pushes BWidget ttk forward.
I propose him as tcllib developper how should be active on cvs, file
release and the web site. Please provide him with the corresponding
rights and the support.

Some folks got an intermediate version of BWidget 1.9.1. You may drop
him (or me) an E-Mail if you want it for evaluation or support purposes.

Most passed discussions of the last month initiated by me about ttk
BWidget are obsolate. I will remove any steps done for TWidget.

Basicly, ttk support will be in the normal package which will be
compatible to tcl/tk 8.4. This package might be BWidget 1.10 or 2.0, I
don't know. The interface stays intact, so no need for 2.0 any more.

I will stay available to bring BWidget foreward and support Johann.
Please support him, too.

Best regards,
Harald

Johann Oberdorfer schrieb:
> Hello Harald and as well hello to Dr.Csaba Nemethi,
> 
> I have done some progress:
> I now merged my code changes with the changes you did (BW 1.9.0) and
> raised the sub-version to 1.9.1.
> I am not completely finished/happy with it, so I am asking for some more
> patient until the code is ready to go.
> 
> Basically I'am planning/proposing to have only one package which is
> initialized as usual with: "package require BWidget".
> Doing so, everything is compatible to previous tcl/tk releases (I am
> still forced to use tcl/tk 8.4 for some techn. reasons - without further
> explanations given here).
> If a programmer want's to have ttk, then here are just 2 more lines
> required:
> 
> package require tile 0.8
> package require BWidget
>   BWidget::using ttk
> 
> Further on in the code, we distinguish between both cases with the
> [BWidget:using ttk] procedure. Unless otherwise stated in the text
> below, using a proc has the advantage to initialize some more extensions
> as well (maybe tablelist package ?). This might be a bit more "future"
> proove, if you agree, performance for 1 more proc to call should not be
> an issue.
> 
> I really like the idea to encapsulate the ttk functionality within the
> package, without confusing the programmer's with additional namings, but
> this is just one opinion of many -  at the end of the day, it's the
> functionality and usability which counts.
> 
> When dealing with tablelist and tablelist_tile the only thing I
> discovered is that you have to take the decision beforehand, what you
> want to have: initializing both on different places in the code will
> raise an error, which drops off a bit of flexibility.
> By the way tablelist is marvelous from the functionality point of view
> and very well documented as well - thank you Csaba.
> 
> Once a tile theme has changed (for interactively choosing a user's
> favorite theme), I am planning to bind to each class, which needs to be
> updated (e.g. ListBox, Notebook, ...) a "_themechanged" procedure, which
> in turn retrieves colors from ttk "ttk::style configure ." and
> propagates them back to BWidget widget's (mostly based on a canvas's).
> Therfore the <<ThemeChanged>> virtual event seems to be perfect - I have
> read through the tablelist source, of this problem is solved there.
> 
> And for sure, there needs to be a createOrUpdateBWCustomStyles procedure
> somehow, for setting up special commonly used style declarations - if
> required. Otherwise styles are defined within each widget related source
> file.
> 
> Oh: I still need to create a sourceforge user. Once this is done I'll
> let you know.
> 
> See attachement for the current developemet version 1.9.1 for testing
> (maybe) - still flagged as preliminary!
> 
> 
> One more thing:
> It's would also be beneficial to gather famous icon themes together and
> put them into one package/project, windxpblue, keramik, plastik, etc,
> ... Q: Does something already exist ?
> 
> Thank you all for support and information - comments are welcome!
> 
> With kind regards,
>     Johann