[GRASS-user] grass70 and display monitor

On Dec 18, 2009, at 3:45 AM, grass-user-request@lists.osgeo.org wrote:

Date: Thu, 17 Dec 2009 23:21:18 +0100
From: ??? ??? <nikos.alexandris@felis.uni-freiburg.de>
Subject: Re: [GRASS-user] grass70 and display monitor
To: Glynn Clements <glynn@gclements.plus.com>
Cc: GRASS user list <grass-user@lists.osgeo.org>
Message-ID: <1261088478.7528.2.camel@vertical>
Content-Type: text/plain; charset="UTF-8"

On Thu, 2009-12-03 at 18:59 +0000, Glynn Clements wrote:

Vincent Bain wrote:

May I be considered bothersome, but was it really impossible to achieve
(like in grass65) the development of a wxGUI (which I really enjoy too)
while keeping the complete set of "historical" command line
environment ?

Very little is actually impossible, but the disadvantages (in terms of
both effort and detriment to the end product) far outweigh the
advantages.

I loved the "d.mon & co" tools ;-). But I understand that they had to be
dropped. Is there already something in the wiki (with respect to grass70
and interactive d.* tools)?

Thanks, Nikos

Nikos,

Rather than trying to have primitive interaction built in to different display modules, they all now work as true command line tools where you type a command with arguments and get a result. All d.* modules that worked as command line tools before (e.g., d.rast, d.vect) still work that way. See further explanations at <http://lists.osgeo.org/pipermail/grass-user/2009-December/053520.html&gt;

For d.* modules that had some kind of primitive GUI built into the module, they have either been switched to true command-line tools or are dropped from GRASS 7 until they are rewritten to that standard.

Instead of trying to build interaction into each module, they all can now work with an independent GUI layer on top of the modules. This is what it is for. The current GUI will do all of the interaction of prior d.* modules with built-in GUI with the exception of a few modules (notably r.digit [super primitive and not really needed with vdigit and v.to.rast], i.class, and i.ortho.photo) and more.

So you can do what you did before in a nicer environment.

Michael

Nikos:

May I be considered bothersome, but was it really impossible to
achieve (like in grass65) the development of a wxGUI
(which I really enjoy too) while keeping the complete set of
"historical" command line environment ?

Glynn:

Very little is actually impossible, but the disadvantages (in terms of
both effort and detriment to the end product) far outweigh the
advantages.

Rest assured that when all the dust has settled from the new GUI work,
if there remains demand for control from the (bash) command line, it
will be provided in some form or another. this is free software after
all and itches do get scratched.

To echo Glynn, I can guarantee that the "complete set" of d.* will not
survive, and that it is extremely unlikely that there will be any
competing menu driven GUIs.

I do expect that some purposefully simple PPM image monitor window will
happen one day. Don't expect it to be very interactive or stateful, or
even more than just an official addon.

Hamish

# Small correction (just for the records :-p) #

Vincent:

>> May I be considered bothersome, but was it really impossible to
>> achieve (like in grass65) the development of a wxGUI
>> (which I really enjoy too) while keeping the complete set of
>> "historical" command line environment ?

Glynn:
> Very little is actually impossible, but the disadvantages (in terms of
> both effort and detriment to the end product) far outweigh the
> advantages.

Rest assured that when all the dust has settled from the new GUI work,
if there remains demand for control from the (bash) command line, it
will be provided in some form or another. this is free software after
all and itches do get scratched.

To echo Glynn, I can guarantee that the "complete set" of d.* will not
survive, and that it is extremely unlikely that there will be any
competing menu driven GUIs.

I do expect that some purposefully simple PPM image monitor window will
happen one day. Don't expect it to be very interactive or stateful, or
even more than just an official addon.

Hamish

On Fri, 2009-12-18 at 08:53 -0700, Michael Barton wrote:

On Dec 18, 2009, at 3:45 AM, grass-user-request@lists.osgeo.org wrote:

> Date: Thu, 17 Dec 2009 23:21:18 +0100
> From: ??? ??? <nikos.alexandris@felis.uni-freiburg.de>
> Subject: Re: [GRASS-user] grass70 and display monitor
> To: Glynn Clements <glynn@gclements.plus.com>
> Cc: GRASS user list <grass-user@lists.osgeo.org>
> Message-ID: <1261088478.7528.2.camel@vertical>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2009-12-03 at 18:59 +0000, Glynn Clements wrote:
>> Vincent Bain wrote:
>>
>>> May I be considered bothersome, but was it really impossible to achieve
>>> (like in grass65) the development of a wxGUI (which I really enjoy too)
>>> while keeping the complete set of "historical" command line
>>> environment ?
>>
>> Very little is actually impossible, but the disadvantages (in terms of
>> both effort and detriment to the end product) far outweigh the
>> advantages.
>
> I loved the "d.mon & co" tools ;-). But I understand that they had to be
> dropped. Is there already something in the wiki (with respect to grass70
> and interactive d.* tools)?
>
> Thanks, Nikos

Nikos,

Rather than trying to have primitive interaction built in to different display modules, they all now work as true command line tools where you type a command with arguments and get a result. All d.* modules that worked as command line tools before (e.g., d.rast, d.vect) still work that way. See further explanations at <http://lists.osgeo.org/pipermail/grass-user/2009-December/053520.html&gt;

For d.* modules that had some kind of primitive GUI built into the module, they have either been switched to true command-line tools or are dropped from GRASS 7 until they are rewritten to that standard.

Instead of trying to build interaction into each module, they all can now work with an independent GUI layer on top of the modules. This is what it is for. The current GUI will do all of the interaction of prior d.* modules with built-in GUI with the exception of a few modules (notably r.digit [super primitive and not really needed with vdigit and v.to.rast], i.class, and i.ortho.photo) and more.

So you can do what you did before in a nicer environment.

Michael,

I did read (almost all of) your posts WRT to grass70 and d.*zzz.
However, I want to say that, honestly, I appreciate the time you invest
for clarifications (again).

It's one of those things that gives the community a meaning and
personally it makes me feel being a part of it.

Thank You, Nikos