No registered users in community xowiki
in last 10 minutes
in last 10 minutes
RE: [Xotcl] xotcllib?
From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Mon, 18 Oct 2004 13:44:26 -0400
> -----Original Message-----
> From: Jeff Hobbs [mailto:jeffh_at_ActiveState.com]
> Sent: Sunday, October 17, 2004 6:22 PM
> To: Schofield, Bryan (GE Transportation); xotcl_at_alice.wu-wien.ac.at
> Subject: RE: [Xotcl] xotcllib?
>
>
> > 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 things a little more complicated since xow widgets can & will pick up option db settings for base widgets and the -class option isn't available for most widgets. Personally, I am aware of this shortcoming and work around it. I'd rather not have this feature than have one that works partially and is unpredictable. Since I haven't had the time to devote to writing a complete implementation, I haven't done anything with it.
There is no special code to handle composition of megawidgets, focus, or event processing.
>
> > xcentuate - a theme engine for tk. This isn't all that
> > important on windows, but on unix tk often needs a little
> > help looking good. This package provides a very simple method
> > of defining and changing the look of tk apps. It can even do
> > it on the fly.
>
> I would not propagate this in favor of Tile. There is
> also already the 'style' package in tklib (which again
> may be abortive when Tile becomes part of 8.5). What
> features does xcentuate really provide? Should they not
> just go into 'style'?
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.
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 routines already, I just need to convert them to xotcl and integrate them. The widget classes and options applied to those classes are not hard coded in xcentuate. It can be trained to apply style to new widget classes or change what options are applied. Finally, xcentuate is OO. I like objects, I like them alot. This package works well for me but I look forward to Tile being part of 8.5 so I can declare this obsolete.
Below is an example of a LookAndFeel that shows what xcentuate can control right now. This particuler LookAndFeel gets applied by default on unix. Xcentuate will also learn what tk looks like by default so there is always a "default" LookAndFeel that can be applied. Oh, xcentuate can change styles (LookAndFeels) on the fly.
LookAndFeel lightgrey \
-name "Light Grey" \
-description "A simple light grey palette" \
-activebackground grey90 \
-activeforeground red \
-background grey80 \
-disabledbackground grey85 \
-disabledforeground grey40 \
-foreground black \
-highlightbackground grey80 \
-highlightcolor red \
-insertbackground red \
-readonlybackground grey90 \
-selectbackground skyblue \
-selectcolor red \
-selectforeground black \
-textbackground white \
-textforeground black \
-troughcolor grey75 \
-borderwidth 1 \
-labelframepad 4 \
-labelframebd 2 \
-texterrorbg \#fee \
-texterrorfg red3 \
-textwarnbg PeachPuff \
-textwarnfg orange2 \
-textokbg \#dfd \
-textokfg green3 \
-textnotebg \#ffd \
-textnotefg yellow3 \
-textinfobg \#def \
-textinfofg blue2
lightgrey apply
>
> > xout - a unit testing framework. I know, I know, tcl already
> > provides one, tcltest. But I found tcltest to be too
> > cumbersome and clunky. I'd write some tests, but maintaining
> > those tests often was neglected because of the amount of
> > programming overhead needed to write complex test cases. xout
>
> Did you compare against tcltest v1 or v2?
Version 2. Tcltest is more powerful, no question about that. But for testing complex scenarios, I like to build on the success of one test later. For example, consider the following distinct events that I can test, where later tests use something from previous tests.
1. Can I create object X?
2. Can object X do something?
3. Can object X do something else?
4. Can I delete object X and it clean up properly?
Thing can get way more complicated than that, too. Imagine trying to test db or remote server interaction. With tcltest, I'd have to create object X or connect to a db or server in the setup of every test. I can appreciate isolating tests from one another so that one test doesn't impact another, which is what tcltest does. To achieve that, I have two level in my test hierachy. One is the TestSuite. No two suites can interact with each other. They run in their own iterpreter from scratch. A TestSuite has one or more Tests that *can* interact with each other. Also, on a side note, I hate having to specify a test name with tcltest.
test example-1.1 {test file existence} -setup {
set file [makeFile {} test]
} -body {
file exists $file
} -cleanup {
removeFile test
} -result 1
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 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}
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 mention all of this because if other have some handy xotcl
> > packages, I'd be interested in creating a formal xotcllib
> > project. Perhaps something at sourceforge. I'll be making
> > these available soon either way.
>
> I think that would be a handy thing as an addon.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
>
>
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/
Sorry for being long winded.
-- bryan
Date: Mon, 18 Oct 2004 13:44:26 -0400
> -----Original Message-----
> From: Jeff Hobbs [mailto:jeffh_at_ActiveState.com]
> Sent: Sunday, October 17, 2004 6:22 PM
> To: Schofield, Bryan (GE Transportation); xotcl_at_alice.wu-wien.ac.at
> Subject: RE: [Xotcl] xotcllib?
>
>
> > 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 things a little more complicated since xow widgets can & will pick up option db settings for base widgets and the -class option isn't available for most widgets. Personally, I am aware of this shortcoming and work around it. I'd rather not have this feature than have one that works partially and is unpredictable. Since I haven't had the time to devote to writing a complete implementation, I haven't done anything with it.
There is no special code to handle composition of megawidgets, focus, or event processing.
>
> > xcentuate - a theme engine for tk. This isn't all that
> > important on windows, but on unix tk often needs a little
> > help looking good. This package provides a very simple method
> > of defining and changing the look of tk apps. It can even do
> > it on the fly.
>
> I would not propagate this in favor of Tile. There is
> also already the 'style' package in tklib (which again
> may be abortive when Tile becomes part of 8.5). What
> features does xcentuate really provide? Should they not
> just go into 'style'?
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.
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 routines already, I just need to convert them to xotcl and integrate them. The widget classes and options applied to those classes are not hard coded in xcentuate. It can be trained to apply style to new widget classes or change what options are applied. Finally, xcentuate is OO. I like objects, I like them alot. This package works well for me but I look forward to Tile being part of 8.5 so I can declare this obsolete.
Below is an example of a LookAndFeel that shows what xcentuate can control right now. This particuler LookAndFeel gets applied by default on unix. Xcentuate will also learn what tk looks like by default so there is always a "default" LookAndFeel that can be applied. Oh, xcentuate can change styles (LookAndFeels) on the fly.
LookAndFeel lightgrey \
-name "Light Grey" \
-description "A simple light grey palette" \
-activebackground grey90 \
-activeforeground red \
-background grey80 \
-disabledbackground grey85 \
-disabledforeground grey40 \
-foreground black \
-highlightbackground grey80 \
-highlightcolor red \
-insertbackground red \
-readonlybackground grey90 \
-selectbackground skyblue \
-selectcolor red \
-selectforeground black \
-textbackground white \
-textforeground black \
-troughcolor grey75 \
-borderwidth 1 \
-labelframepad 4 \
-labelframebd 2 \
-texterrorbg \#fee \
-texterrorfg red3 \
-textwarnbg PeachPuff \
-textwarnfg orange2 \
-textokbg \#dfd \
-textokfg green3 \
-textnotebg \#ffd \
-textnotefg yellow3 \
-textinfobg \#def \
-textinfofg blue2
lightgrey apply
>
> > xout - a unit testing framework. I know, I know, tcl already
> > provides one, tcltest. But I found tcltest to be too
> > cumbersome and clunky. I'd write some tests, but maintaining
> > those tests often was neglected because of the amount of
> > programming overhead needed to write complex test cases. xout
>
> Did you compare against tcltest v1 or v2?
Version 2. Tcltest is more powerful, no question about that. But for testing complex scenarios, I like to build on the success of one test later. For example, consider the following distinct events that I can test, where later tests use something from previous tests.
1. Can I create object X?
2. Can object X do something?
3. Can object X do something else?
4. Can I delete object X and it clean up properly?
Thing can get way more complicated than that, too. Imagine trying to test db or remote server interaction. With tcltest, I'd have to create object X or connect to a db or server in the setup of every test. I can appreciate isolating tests from one another so that one test doesn't impact another, which is what tcltest does. To achieve that, I have two level in my test hierachy. One is the TestSuite. No two suites can interact with each other. They run in their own iterpreter from scratch. A TestSuite has one or more Tests that *can* interact with each other. Also, on a side note, I hate having to specify a test name with tcltest.
test example-1.1 {test file existence} -setup {
set file [makeFile {} test]
} -body {
file exists $file
} -cleanup {
removeFile test
} -result 1
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 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}
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 mention all of this because if other have some handy xotcl
> > packages, I'd be interested in creating a formal xotcllib
> > project. Perhaps something at sourceforge. I'll be making
> > these available soon either way.
>
> I think that would be a handy thing as an addon.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
>
>
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/
Sorry for being long winded.
-- bryan