On Mar 28, 2008, at 10:55 AM, [EMAIL PROTECTED] wrote:
Date: Fri, 28 Mar 2008 23:24:36 +0600
From: Ivan Shmakov <[EMAIL PROTECTED]>
Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
To: [email protected]
Cc: Ivan Shmakov <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
