[GRASS-dev] d.m/d.gis mysteries..

[Moritz Lennert]

Maciej,

In no way was what I wrote intended as a personal attack. If this is how
it came across, I sincerely apologize.

Up to now you are the only one who has raised this issue as a problem.
Maybe this is because you are the only one conscious of it and many people
are actually misusing gis.m thinking that they get a precision which they
are actually not getting. Maybe it is because those who need such level of
precision have the habit of going through g.region. Or maybe it is because
those who need it are working on the command line and so don't use gis.m.
I don't know the reasons...

So, the first question to be asked is: does everyone agree that this is a
bug ? If yes, then I agree completely that this needs to be fixed. But as
always developer time is limited...and there are other bugs in GRASS which
those who have the skills find more important.

The current situation definitely is not easy as we are in a transition
phase between gui's with a very important step being gis.m, but at the
same time this is already poised to be replaced. This makes the issue more
difficult, as Michael has to deal with three different GUIs at the same
time, and it is not always clear which of these should be the priority.

I am willing to help you try to identify whether there are possible
solutions to the issue in gis.m, but definitely not before next week and
as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
for a bug fix release.

Moritz

On Mon, October 30, 2006 13:54, Maciej Sieczka wrote:
> Dear Moritz,
>
> Moritz Lennert wrote:
>> a discussion whether there is a way to satisfy Maciej's desires
>
> Can I kindly ask you to reconsider this, and having done that, rephrase
> it in a way which does not ridicule me? Because, as I understand what
> you are suggesting, you mean that I'm expecting or demanding something
> just to satisfy my egoistic needs, for no practical benefit to other
> GRASS users. While actually I'm pointing out an important defect in
> gis.m, which concerns any GRASS user.
>
> Why I think it is an important issue: gis.m allows for changing the
> current GRASS region to match the current display and to make the
> display match the current region settings. Since these 2 operations are
> implemented, they should work correctly, as you would expect it. Since
> they don't work correctly - it is a bug.
>
>> And I completely agree with your point that if this really itches him
>> that much,
>
> Again, it is not about me not liking something, whatever you mean to
> make people think about it by your unfair comments.
>
>> 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...
>
> If I had time I would have done this. What did you think?
>
> I haven't criticized Michael or you as a person. Actually I haven't
> said a single "personal" word. I criticized a defect in the software.
> And I don't appreciate that you are trying to reduce the discussion to
> the level of my person, insulting me with innuendos.
>
>> I absolutely think that gis.m is ready for production. And I agree that
>> we should discontinue d.m after 6.2.
>
> ... if the bug in gis.m is fixed.
>
>> 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.
>
> ... keeping in mind this is not a fix.
>
> We can't deny a bug, only because nobody (yes, including me) is able to
> fix it.
>
> Kind Regards,
> Maciek
>