xow - A megawidget framework. This is a package that allows xotcl objects to be megawidgets.
Does this handle the option db correctly, do composition of megawidgets, handle focus and events right, etc.?
No, currently doesn't handle the option db. This is a tricky area of building megawidgets. An xow widget can be based off of any other existing widget or megawidget. That can make
...
There is no special code to handle composition of megawidgets, focus, or event processing.
While I don't want to discourage good coding exercises, I do want to encourage others to use code based on all the best practices. We don't have a perfect megawidget framework to rely on yet, but hopefully you'll be willing to take part when we get around to it, or maybe work on yours until it is that system. ;)
xcentuate - a theme engine for tk. This isn't all that
I would not propagate this in favor of Tile. There is
I'm not sure what "style" package you are refering to. I see none in the docs for TkLib, but maybe I missed them or it's not in the latest official release. I did manage to google up a "as::style" package that you appear to have written. So I'll assume that's the package to which you refer.
Yes, that's a variant that was included.
xcentuate provides the common things like colors and borderwidth for widgets. It also provides some named colors and eventually named fonts. I have some good font generation
Hmmmm ... ok, you have created something more for users to define their own themes, whereas 'style' says "these are better overall alternate themes". I must say that I personally encourage the latter. It's a pity you couldn't make it to Tcl'2004 last week, because I had a tutorial and talk on these points. I don't mean to pick on you, I just want to give my ideas and how they may affect your current efforts.
The whole idea of themeing, which will be core in 8.5, is to enable a better look for Tk. However, it is not intended for the user (in the common case) to change this theme. The functionality is there merely for Tk to better adapt to current styles. Thus, the 'style' code defines styles for users to just use, rather than providing a framework to create their own.
I look forward to Tile being part of 8.5 so I can declare this obsolete.
Note that tile works perfectly well with 8.4. ActiveState will actually be shipping an app RSN that uses tile. What is now a testbed will soon be a core feature, but that doesn't mean you can't use it now.
interact with each other. Also, on a side note, I hate having to specify a test name with tcltest.
...
It's fine until you realize next month that you need a new test, and that it make more sense from a readability viewpoint to stick it in between example-1.1 and example-1.2. Do I call it example-1.1.5 or renumber the other tests below? The test name doesn't add much to me, the tester. It's the description that matters. For comparison purposes, xout test
OK, I've dealt with this before. There is nothing in the naming of that test that requires it be numbers, that is just convention. It makes it easier for grouping and such, and is handy when searching through the test suite after failures. In your example below:
file would be structured as follows:
TestSuite foo \-description "blah" \ -setup {set file [makeFile {} test]} \ -cleanup {removeFile test} foo test \ -description "test file existence" -result 1 \ -script {file exists $file}
What happens when you don't provide a description? This should be a required field, as it is in tcltest, so why have it an option? Otherwise, I see the structure you have chosen could make it easier to build tests.
Finally, xout is only a framework. It can be embedded into other applications such as an IDE. That can easily find and query TestSuite objects to run and get their results. Just so happens that the GUI can also be embedded in or run standalone.
I like the UI you added to it.
I threw some screen shots of xcentuate & xout in action on my (unfinished) website if anyone wants to take a look. http://www.abschofield.com/code/ss/
Very nice.
Sorry for being long winded.
No problem, and I don't want to sound negative. I'm just trying to assist constructively. As I've told Gustaf and Uwe before, xotcl (or some close variant) could be the OO for the core, if it provided 100% itcl compatability (for the many many folks that rely on itcl).
Jeff