[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 112

[Michael Barton]

On Mar 28, 2008, at 10:55 AM, grass-dev-request at lists.osgeo.org wrote:
> Date: Fri, 28 Mar 2008 23:24:36 +0600
> From: Ivan Shmakov <ivan at theory.asu.ru>
> Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
> To: grass-dev at lists.osgeo.org
> Cc: Ivan Shmakov <oneingray at gmail.com>
> Message-ID: <m263v67odn.fsf at cherry.siamics.int>
> Content-Type: text/plain; charset=us-ascii
>
> 	The lines marked ``>'' below seem nonsensical to me.  For what
> 	reason, e. g., would one need to assign to an `array' variable
> 	thrice, let alone introducing the `#' variable?
>
> barscale.tcl	12	namespace eval GmBarscale {
> barscale.tcl	13 >	    variable array opt # barscale current options
> barscale.tcl	14	    variable count 1
> barscale.tcl	15 >	    variable array lfile # scale
> barscale.tcl	16 >	    variable array lfilemask # scale
> barscale.tcl	17	    variable optlist
> barscale.tcl	18	    variable first
> barscale.tcl	19 >	    variable array dup # layer
> barscale.tcl	20 >	    variable placement #LabelEntry widget for  
> scale bar placment coordinates
> barscale.tcl	21	};


Ivan,

Everything following the # is a comment to document the variable

The "variable xxx"

is to assign this to a local namespace.

I had to learn TclTk from deconstructing others' (sometimes not so  
elegant or uptodate) code and trying to work through the (often  
obtuse) online manual.

If there is a better way to do it, that also makes the code more  
reliable or faster, that's great--as long as it is also readable.  
Because this is done by self-taught, amateur, volunteer programmers,  
however, whatever changes that are made need to be very well  
documented. There are chunks of code (e.g., for gronsole) that are  
not well documented and quite difficult for someone like me to untangle.

There is one place that is a serious problem where we could really  
use a much more experienced TclTk programmer like you to sort out:  
the progress bar. It seems like it ought to be straightforward, but  
there is something wrong with the progress bar code so that if a  
module executes too quickly, it crashes the entire TclTk interface. I  
didn't write it but I've tried to sort it out and made some  
improvement to it. But my 'fixes' involved more guesswork than they  
should have and there are still problems on some modules.

Thanks for your help.
Michael