+1, it was never our intention to force users to know all of Tcl before being able to use Tkx (that just happens to help a lot ;) ). In reality it was time limitations that did and do prevent us from making much better Tkx docs ourselves.

We'd be happy to shuttle in extended docs for anyone who has the time and inclination to help us clarify for other users.

Jeff

On 03/09/2009 7:33 AM, Laurence Anthony wrote:
I also support the position that most Tkx users will be coming from Perl/Tk,
which is well documented through books like Mastering PerlTk. So, the first
problem we get when trying to use Tkx is the limited documentation.
Basically, we have to read between the lines to figure out how to do things.
When I first started using Tkx I was trying to figure out the translation
from Perl/Tk but I've been increasingly disappointed that the translation is
not that simple. These days, I'm reading the Tcl documentation and trying to
figure out how to translate that into Tkx syntax. Surprisingly, this isn't
always easy either.

I think redundancy is the key to documentation. Even if Tkx::eval() is just
like any other Tkx::foo if it's useful, then it would be nice to have in the
documentation, even if just as an example of how powerful Tkx::foo can be.

We also need to generate a strong Tkx community (to cover cases not in the
documentation). I think the fact that there's isn't a proper Tkx discussion
group is a serious problem. Why isn't one created? A first good step would
be to at least explain in the documentation where people should post
questions about Tkx. (Is the tcltk mailing list the right place?)

Just my thoughts...
Laurence.

Reply via email to