Re: [Tcllib-devel] Tcllib: Adding a module for an enhanced procedure and argument management

[Andreas K. <and...@ac...>]

Andreas Drollinger wrote:
> Dear all,
> Thanks for your first feedbacks to my initial mail.
> I will try to answer all your questions in this single mail:
> 
> 1) License: I have already planned to use the BSD license for this package

Ok.

> 2) Tklib for the form generator: It may be wise to separate the 
> graphical parts from the procedure and argument manager and to place 
> them into Tklib. There is certainly no problem to use inside the Tcllib 
> packages other packages from Tklib, isn't there?

Such a dependency would be new, no other package has such (IIRC).
My take is that having it should be no problem.

 > The core TEPAM package
> would also rely on the form generator package in Tklib.

> 3) There is already a comprehensive regression test in place for the 
> non-graphical part of TEPAM. Nevertheless, in case Tcllib is using an 
> own test framework,

Tcllib uses Tcl's tcltest package as the basis of its test framework.

If your test framework is also based on tcltest then the main issue/difference 
may be the way the package under test, and support code, are loaded.

In tcllib we use semi-bolilerplate code like


	# --------------------------------------------------------------------

	source [file join \
	        [file dirname [file dirname [file join [pwd] [info script]]]] \
	        devtools testutilities.tcl]

	testsNeedTcl     8.2
	testsNeedTcltest 1.0

	testing {
	    useLocal aes.tcl aes
	}

	# --------------------------------------------------------------------

for this.

 > this regression test has certainly to be adapted to
> the Tcllib test framework. For the graphical part of the TEPAM package 
> there is no regression test for the moment available.

That is ok.

> 
> 4) It should be fine to write the command reference documentation in the 
> doctool format. Nevertheless, I am not sure if this format is adequate 
> for a tutorial (like the TEPAM introduction) that will also include some 
> pictures.

True, doctools currently does not support pictures as part of the manual. We 
have some semi-support in a related format (TIP's), and its rendering system.

We may be able to adopt a similar strategy for doctools. The strategy of 
tiprender is to have the basename of the image in the document sources, and 
then have the renderer select the specific format of the image, assuming that 
such exists. Example

Sources.
	#img foo
Renderers
	HTML	looks for foo.gif
	Text	looks for foo.text
	etc.

where it is assumed that these files are all containing the same image, in 
different representations. Like foo.text some ascii-art representation of the 
foo.gif).

What format are you using for your introduction which then gets converted into 
PDF ? Assuming that there is a source format different than PDF.

> 
> 5) Concerning the sub-commands, TEPAM is basically providing an easy way 
> to declare them. Sub-commands can be declared individually each from the 
> other with individual procedure bodies like normal procedures, and TEPAM 
> will then call the right procedure body in function of the selected 
> sub-command. The attached document provides an example of the 
> declaration and usage of sub-commands with TEPAM.

I believe declaration and usage were not in doubt, the original question 
pointed more to the implementation. However that is more for Gerald, as he put 
up the original question about this.


-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>