No registered users in community xowiki
in last 10 minutes
in last 10 minutes
RE: [Xotcl] xotcllib?
From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 18 Oct 2004 13:43:33 -0700
> > > 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
Date: Mon, 18 Oct 2004 13:43:33 -0700
> > > 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