--->[Quoting Glynn Clements <glynn.clements@virgin.net>:]
Alex Shevlakov wrote:
> I'd like to attempt making permanent changes to tcltk
> scripts (especially, tcltkgrass) code in order to
> internationalize them. As much as I know, there
> is a Tcl built-in 'msgcat' command allowing to
> internationalize messages.
AFAICT, the msgcat package was added in Tcl 8.1;
versions prior to that won't have it.
Personally, I don't think that it's reasonable to
require 8.1+ in order to use tcltkgrass. Instead, any
changes should be made in such a way that tcltkgrass
continues to work with older versions of Tcl (albeit
without I18N).
Hello Glynn,
maybe for you internationalisation is not important, but
for me - essencial. We have to do it with minimal
difficulties, of course, but if we have to use newer
Tcl/Tk - we should do it.
--
http://ibiblio.org/ser/ | http://it-zone.org/
_________________________________________________________
tldp.org|gnu.org|hyperreal.info|pld-linux.org|it-zone.org
"The moon is made of green cheese." -- John Heywood
On Fri, May 17, 2002 at 04:59:37PM +0200, ser@it-zone.org wrote:
--->[Quoting Glynn Clements <glynn.clements@virgin.net>:]
>
> Alex Shevlakov wrote:
>
> > I'd like to attempt making permanent changes to tcltk
> > scripts (especially, tcltkgrass) code in order to
> > internationalize them. As much as I know, there
> > is a Tcl built-in 'msgcat' command allowing to
> > internationalize messages.
>
> AFAICT, the msgcat package was added in Tcl 8.1;
> versions prior to that won't have it.
>
> Personally, I don't think that it's reasonable to
> require 8.1+ in order to use tcltkgrass. Instead, any
> changes should be made in such a way that tcltkgrass
> continues to work with older versions of Tcl (albeit
> without I18N).
Hello Glynn,
maybe for you internationalisation is not important, but
for me - essencial. We have to do it with minimal
difficulties, of course, but if we have to use newer
Tcl/Tk - we should do it.
... I still dream of an extension to tcltkgrass (or whatever)
to utilize the "--interface-description", e.g.
d.rast --interface-description
to generate the tcltkgrass menu windows on the fly. This should
solve the internationalization problems (since "only" the modules
themselves must be internationalized, not also the menu system)
along with a reduction of maintenance workload (to synchronize
tcltkgrass with the module parameters).
Just a useless comment,
Markus
ser@it-zone.org wrote:
> > I'd like to attempt making permanent changes to tcltk
> > scripts (especially, tcltkgrass) code in order to
> > internationalize them. As much as I know, there
> > is a Tcl built-in 'msgcat' command allowing to
> > internationalize messages.
>
> AFAICT, the msgcat package was added in Tcl 8.1;
> versions prior to that won't have it.
>
> Personally, I don't think that it's reasonable to
> require 8.1+ in order to use tcltkgrass. Instead, any
> changes should be made in such a way that tcltkgrass
> continues to work with older versions of Tcl (albeit
> without I18N).
Hello Glynn,
maybe for you internationalisation is not important, but
for me - essencial. We have to do it with minimal
difficulties, of course, but if we have to use newer
Tcl/Tk - we should do it.
Requiring Tcl 8.1+ in order to obtain I18N is reasonable. Changing
tcltkgrass so that it will not run at all without Tcl 8.1+ isn't
reasonable.
Basically, it just means that the implementation method needs to allow
for the case where the "msgcat" package isn't available, e.g. by
providing a stub implementation.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, May 17, 2002 at 05:11:35PM +0200, Markus Neteler wrote:
... I still dream of an extension to tcltkgrass (or whatever)
to utilize the "--interface-description", e.g.
There're still a few problems with the --interface-description
mechanism:
1) There is no way to flag if a command goes interactive. This is
necessary for tcltkgrass as it spawns an xterm when the module
description indicates the command is interactive. This can be added to
the GModule struct (and GModule should be renamed as it conflicts with
an interface in GLIB, case folks want to use that library for something).
2) Some commands still don't function with the --interface-description.
3) Some commands spew out extraneous info that gets into the XML
stream, thus making it invalid.
4) The tcltkgrass module interface has some extra capabilities not
directly reflected in the output of --interface-description (file
browsing, color selection, etc.). The "standard option" interface will
help make these recognizable.
5) ???
I think this can all be tackled in 5.1.
--
Eric G. Miller <egm2@jps.net>
--->[Quoting Glynn Clements <glynn.clements@virgin.net>:]
Requiring Tcl 8.1+ in order to obtain I18N is
reasonable. Changing tcltkgrass so that it will not run
at all without Tcl 8.1+ isn't reasonable.
Basically, it just means that the implementation method
needs to allow for the case where the "msgcat"
package isn't available, e.g. by providing a stub
implementation.
Ok - I think, that the road to nowhere means we will
write another Tcl/Tk 
I am thinking economically: are
you sure we have enough resources for that? Until we
finish Grass 5.1 - Tcl/Tk in new version will be much
wider available.
But I am working on Linux - maybe upgrading Tcl/Tk on
other Un*x systems is more complicated...
I am very happy we start i18n work, and forgive me I
insist on it.
Sergiusz
--
http://ibiblio.org/ser/ | http://it-zone.org/
_________________________________________________________
tldp.org|gnu.org|hyperreal.info|pld-linux.org|it-zone.org
"The moon is made of green cheese." -- John Heywood
On Friday 17 May 2002 05:47 pm, Eric G. Miller wrote:
On Fri, May 17, 2002 at 05:11:35PM +0200, Markus Neteler wrote:
> ... I still dream of an extension to tcltkgrass (or whatever)
> to utilize the "--interface-description", e.g.
There're still a few problems with the --interface-description
mechanism:
1) There is no way to flag if a command goes interactive. This is
necessary for tcltkgrass as it spawns an xterm when the module
description indicates the command is interactive. This can be added to
the GModule struct (and GModule should be renamed as it conflicts with
an interface in GLIB, case folks want to use that library for something).
2) Some commands still don't function with the --interface-description.
3) Some commands spew out extraneous info that gets into the XML
stream, thus making it invalid.
4) The tcltkgrass module interface has some extra capabilities not
directly reflected in the output of --interface-description (file
browsing, color selection, etc.). The "standard option" interface will
help make these recognizable.
5) ???
I think this can all be tackled in 5.1.
BTW: In g51 Tcl/Tk is already generated from options/flags
if parameters are not given:
http://mpa.itc.it/radim/g51/d.vect-gui.jpg
Radim
On Fri, May 17, 2002 at 06:02:11PM +0200, Sergiusz Pawlowicz wrote:
--->[Quoting Glynn Clements <glynn.clements@virgin.net>:]
Ok - I think, that the road to nowhere means we will
write another Tcl/Tk
No.
Until we
finish Grass 5.1 - Tcl/Tk in new version will be much
wider available.
I don't believe it, you overestimate the willingness to change.
BTW: 5.1.x will always be a development series.
The next stable GRASS series will be 5.2.x.
But I am working on Linux - maybe upgrading Tcl/Tk on
other Un*x systems is more complicated...
Even most GNU/Linux users are very conservative.
I am very happy we start i18n work,
and forgive me I insist on it.
We are happy to have i18n work started.
I still think it should be mostly folded into 5.1.x.
But right now it looks like stuff will go into 5.0.1 or 5.0.2,
if it is stable.
This means we have to find an acceptable way to add i18n.
Requireing tcltk81 is not acceptable.
A simple preprocessing step as a crude solution which I already
suggested or a stub function like Glynn suggested is easy enough to do.
So if you really want i18n make sure that we can do it without
breaking tcltk 8.0.x.
Bernhard
On Fri, May 17, 2002 at 06:06:11PM +0200, Radim Blazek wrote:
BTW: In g51 Tcl/Tk is already generated from options/flags
if parameters are not given:
What do you mean by this? 
The interface file are generated?
Install time or runtime?
What are they generated from?
On Fri, May 17, 2002 at 06:28:46PM +0200, Bernhard Reiter wrote:
On Fri, May 17, 2002 at 06:06:11PM +0200, Radim Blazek wrote:
> BTW: In g51 Tcl/Tk is already generated from options/flags
> if parameters are not given:
What do you mean by this?
Radim just left, so I take liberty to answer:
The interface file are generated?
Install time or runtime?
it is generated on runtime.
What are they generated from?
I suggest to study the source code of 5.1
In grass51/lib/gis/parser.c is a new function G_gui() doing the
job.
In fact, my wish is already done. I just forgot that (sorry, Radim!).
Cheers
Markus
On Fri, May 17, 2002 at 06:41:50PM +0200, Markus Neteler wrote:
On Fri, May 17, 2002 at 06:28:46PM +0200, Bernhard Reiter wrote:
> On Fri, May 17, 2002 at 06:06:11PM +0200, Radim Blazek wrote:
> > BTW: In g51 Tcl/Tk is already generated from options/flags
> > if parameters are not given:
> What are they generated from?
I suggest to study the source code of 5.1
In grass51/lib/gis/parser.c is a new function G_gui() doing the
job.
Uh, so we do have tcltk specific code in there.
It's nice as a hack, but wasn't the idea to use the gui and
gui version independent XML interface file?
In fact, my wish is already done. I just forgot that (sorry, Radim!).
Well no, as you've wished for the generation from the interface files.
This seems to be lacking still.
On Friday 17 May 2002 07:09 pm, Bernhard Reiter wrote:
> > > BTW: In g51 Tcl/Tk is already generated from options/flags
> > > if parameters are not given:
> >
> > What are they generated from?
>
> I suggest to study the source code of 5.1
> In grass51/lib/gis/parser.c is a new function G_gui() doing the
> job.
Uh, so we do have tcltk specific code in there.
It's nice as a hack, but wasn't the idea to use the gui and
gui version independent XML interface file?
My idea was to remove necessity of grass/src/tcltkgrass/module/*
files (now about 2000 rows, 20 modules missing, + I guess some
inconsistencies). To insert between G_parser and GUI additional
XML generator and XML parser seemed to me as not necessary, extra
work. But if you write XML parser in Tcl/Tk, we can remove G_gui
of course. Or such parser/GUI generator exists?
But this is not the real problem for GUI generating. Problems
are in missing features for grass options/flags as pointed out
by Eric and in past thread about this issue.
Radim
On Fri, May 17, 2002 at 07:09:52PM +0200, Bernhard Reiter wrote:
On Fri, May 17, 2002 at 06:41:50PM +0200, Markus Neteler wrote:
> On Fri, May 17, 2002 at 06:28:46PM +0200, Bernhard Reiter wrote:
> > On Fri, May 17, 2002 at 06:06:11PM +0200, Radim Blazek wrote:
> > > BTW: In g51 Tcl/Tk is already generated from options/flags
> > > if parameters are not given:
> > What are they generated from?
> I suggest to study the source code of 5.1
> In grass51/lib/gis/parser.c is a new function G_gui() doing the
> job.
Uh, so we do have tcltk specific code in there.
It's nice as a hack, but wasn't the idea to use the gui and
gui version independent XML interface file?
> In fact, my wish is already done. I just forgot that (sorry, Radim!).
Well no, as you've wished for the generation from the interface files.
This seems to be lacking still.
No - of course the interface files should become obsolete. Keeping
them up to date is just a waste of time if the same - generating the
tcl/tk (or whatever) windows automagically.
Markus
On Mon, May 20, 2002 at 09:23:43PM +0200, Markus Neteler wrote:
No - of course the interface files should become obsolete. Keeping
them up to date is just a waste of time if the same - generating the
tcl/tk (or whatever) windows automagically.
The XML files are generated, aren't they?
Creating-more-confusion-g-ly,
Bernhard
Hi,
of course there already exist some XML parsers for tcl.
When I developed the XML interface description, there was
one nice parser, but with some license issues.
A short search brought up
http://www.proprius.co.uk/resources/sxml_home.htm
At least worth a look - there might be more.
I recommend to directly use the xml inteface specification
to keep tcltk-GRASS up-to-date at a far lower price.
Best
Jan
On Mon, May 20, 2002 at 11:35:08AM +0200, Radim Blazek wrote:
On Friday 17 May 2002 07:09 pm, Bernhard Reiter wrote:
> > > > BTW: In g51 Tcl/Tk is already generated from options/flags
> > > > if parameters are not given:
> > >
> > > What are they generated from?
> >
> > I suggest to study the source code of 5.1
> > In grass51/lib/gis/parser.c is a new function G_gui() doing the
> > job.
>
> Uh, so we do have tcltk specific code in there.
> It's nice as a hack, but wasn't the idea to use the gui and
> gui version independent XML interface file?
My idea was to remove necessity of grass/src/tcltkgrass/module/*
files (now about 2000 rows, 20 modules missing, + I guess some
inconsistencies). To insert between G_parser and GUI additional
XML generator and XML parser seemed to me as not necessary, extra
work. But if you write XML parser in Tcl/Tk, we can remove G_gui
of course. Or such parser/GUI generator exists?
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/