[GRASS-dev] d.m/d.gis mysteries..
mlennert at club.worldonline.be
Mon Oct 30 05:07:36 EST 2006
Please understand that I am in complete awe in front of what you have
done in so short time. Gis.m is really great and the fact that it does
not depend on xmonitors is a very important step to pushing GRASS even
further. (In addition, it has finally opened the way for me to slowly
impose GRASS on my windows-addicted colleagues.)
So, please don't take any of this as a critique of your work, but rather
as a discussion whether there is a way to satisfy Maciej's desires. And
I completely agree with your point that if this really itches him that
much, than maybe he should think about learning tcltk and finding a
solution. Or maybe learn C and see how d.zoom does it to see if this can
be applied to gis.m...
I absolutely think that gis.m is ready for production. And I agree that
we should discontinue d.m after 6.2.
We could maybe somewhere in the doc include a hint that if one wants
really precise region settings than this has to be done with g.region
and not with zooming.
Michael Barton wrote:
> Three years ago, I had no idea that TclTk even existed, much less had any
> idea of what it did or how to create an interface in the language. Although
> computer-saavy and a GIS user, I had virtually no programming experience
> beyond database application development in xbase.
> I had just started working with GRASS after doing GIS in other platforms for
> many years. I wrote Markus Neteler an email saying how impressed I was with
> GRASS, but noting that the interface was problematic because many commands
> were missing, others were duplicated, and the whole menu system was rather
> confusingly arranged.
> He wrote me back a brief and polite reply, pointing out that this was an
> open source project that depended on volunteers to make it work. He then
> suggested that if I thought the GUI should be better, perhaps I should
> volunteer to do something about it. I mulled this over for several months,
> but eventually tried to follow Markus' advice.
> As many have noted, d.zoom has a number of complications because of the way
> it changes the computational region. Some like it's mouse interface while
> others find it confusing. It's written in C, so I have no idea how it
> There are much more serious issues about continuing to require a xmonitor
> interface for further developing a GRASS GUI and porting it to Windows. So I
> took up the challenge to rewrite the whole interface so that it no longer
> depended on x11. This has come to about 18,000 lines of code. I am aware of
> my limitations as a programmer and grateful for the help I've received, but
> have pretty much done this on my own though painful hours of trial and
> D.m will be preserved in GRASS 6.2, and 6.2 will be available for an unknown
> time into the future (GRASS 4.x is still archived and available for
> downloads). So you can simply use the old interface if you prefer it.
> However, I simply do not have time to actively maintain d.m, gis.m, and
> develop wxPython.
> I'll reiterate what Markus told me three years ago. I'm doing all that I can
> with the skills, resources, and time at my disposal. If this is very
> important to you, then the best thing you can do is to learn TclTk
> programming and work to improve it.
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>> From: Maciej Sieczka <tutey at o2.pl>
>> Date: Sun, 29 Oct 2006 19:16:28 +0100
>> To: Michael Barton <michael.barton at asu.edu>
>> Cc: Moritz Lennert <mlennert at club.worldonline.be>, Hamish
>> <hamish_nospam at yahoo.com>, <grass-dev at grass.itc.it>
>> Subject: Re: [GRASS-dev] d.m/d.gis mysteries..
>> Michael, and All,
>> Please don't take it as an offence, but I must not agree. GRASS is not
>> "a drawing program". Region settings is one the most crucial things
>> about GRASS. Somehow d.zoom is pretty much reliable in regard to what
>> you see vs actuall region settings, while gis.m is not. In gis.m I
>> never know whether WISIWIG. So either gis.m zoom tools are at least
>> that good, or don't call it a stable, reliable replacement for d.zoom
>> (which it aspires to be, obvioulsy).
More information about the grass-dev