[GRASSGUI] graphic overlays

Sun Mar 25 12:43:56 EDT 2007

On 3/25/07, Michael Barton <michael.barton at asu.edu> wrote:
[...]
> This is the same for a GUI--which also augments GRASS commands with a
> graphical and interactive environment. To say that we should not develop a
> modern GUI for displaying GRASS GIS data in a rich, interactive, graphical
> environment simply because it cannot be duplicated from typing textual
> commands seems very restrictive.

Not restrictive, it is demanding.

> Should we drop transparency--which is a
> very useful tool as well as a way to make visually appealing and informative
> maps--simply because it is not easy to do by typing? Should we drop NVIZ
> from GRASS simply because you can't get the same effects by typing on the
> command line?

We shouldn't drop them, but we must strive at making the added
functionality a part of the GRASS system as a whole. I mean, e.g., if
we add mouse-based placement of north arrows, we must strive at
providing similar functionality from the command-line, i.e. a
d.northarrow command whose parameters may be produced by the
interactive version.

This is not very hard to do, as making it in python is a fine first
step. It is just a constraint (and I think a very good one) and
discipline in the way we must structure and think about the "gui"
code.

For instance, in the north arrow matter, it is better to use a python
reader for GRASS' icon/symbol description language and build nice
north arrow in that language than to use, say, SVG astounding
gradient-filled and alpha-blended symbols, which cannot easily be used
by the rest of GRASS code.

> I don't think that would serve the GRASS user community well.

Of course not. IMO the matter under discussion is reusability of
current developments and newer functionality under the original GRASS
philosophy.

BTW, anybody has pointers to a discussion that seems to have arisen
with respect to GRASStep?

Daniel.

> Michael
>
>
> On 3/25/07 12:52 AM, "Martin Landa" <landa.martin at gmail.com> wrote:
>
> > Hi,
> >
> > just *note* -- from my point of view it would be nice to design new
> > GUI only as an interface (without any extra functionality). User can
> > choose between CLI or GUI. But the functionality (including
> > decorations) would be almost identical (i.e. accessible via GUI or
> > CLI). E.g. I don't like that the user can set transparency level of
> > raster layers via GUI in the current GIS Manager but not via CLI (I
> > mean using directly d.rast).
> >
> > Martin
> >
> > 2007/3/25, Michael Barton <michael.barton at asu.edu>:
> >>
> >> On 3/24/07 8:25 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:
> >>
> >>>
> >>> Michael Barton wrote:
> >>>
> >>>>>> I want to suggest that most or all graphic overlays be done via wxPython
> >>>>>> rather than using GRASS d.* commands.
> >>>>>>
> >>>>>> These are: north arrow, scale, grid (and geodetic lines maybe), and text.
> >>>>>> We¹ll need someone to design some nice (and GRASS distinctive) north
> >>>>>> arrows
> >>>>>> and scales.
> >>>>>>
> >>>>>> I suggest that these be accessed through an item or items (popup checkbox
> >>>>>> menu?) on the map display tool bar, rather than having them added as
> >>>>>> layers.
> >>>>>> They should be able to be turned on and off of course, as well as being
> >>>>>> positioned with a mouse (the latter will be much easier if they are
> >>>>>> wxPython
> >>>>>> graphic objects). Each will need it¹s own dialog with options, but that
> >>>>>> shouldn¹t be too difficult to do.
> >>>>>>
> >>>>>> Vector labels could go either way<as something done from the map display
> >>>>>> tool bar or as an independent layer.
> >>>>>>
> >>>>>> Other opinions?
> >>>>>
> >>>>> I suggest that this is implemented in such a way that the user can
> >>>>> easily choose to use the equivalent d.* commands instead, so that the
> >>>>> display contents can be exported as a script which can be used outside
> >>>>> of the GUI (i.e. with an X/PNG monitor).
> >>>>
> >>>> This kind of negates the idea (I thought you were promoting too) of using
> >>>> native GUI functions for all 'decorations'.
> >>>
> >>> FWIW, I don't support requiring the GUI in order to render anything
> >>> which might reasonably appear on a printed map (labels, scale bar,
> >>> legend etc).
> >>
> >> I don't think we should necessarily limit the GUI to only being able to do
> >> what plain GRASS command modules can do. The programming that goes into the
> >> GUI is value added to anyone who uses this. Underneath, it is still just
> >> running GRASS modules. So anyone who wants to script as creatively can get
> >> the same results. But that doesn't mean that simply running a series of
> >> GRASS commands will necessarily achieve the same result. Especially for
> >> graphic rendering, a good GUI may well be able to some things that GRASS
> >> outside the GUI cannot do. I don't see this as an issue. If people want to
> >> use the features of the GUI they can. If they don't want to they don't have
> >> to. If they want to recreate the GUI coding in another platform, that's fine
> >> too. But a bash shell script may not be able to achieve what can be done in
> >> a wxPython script.
> >>
> >>>
> >>> These should all be achievable using d.* commands, and the GUI should
> >>> provide a convenient interface to those commands (e.g. using the mouse
> >>> to identify coordinates for placement).
> >>
> >> This is fine as far as it goes. d.grid is fairly complete as is. However,
> >> d.barscale is very limited in its style of north arrows and scales. And
> >> there is no way to adjust the size of either. If someone wants to program in
> >> a bunch of arrow and scale styles, along with ways of setting scale
> >> parameters and arrow sizes, that's fine. But it may well be much easier to
> >> to do this in the GUI than in a C module. I don't advocate getting rid of
> >> d.barscale. But I don't think the GUI should be limited by its restrictions.
> >> d.text is similarly limited. You can do quite a bit more with text in the
> >> GUI, and do so more easily (e.g., built in font-setting dialogs that are
> >> appropriate to whatever platform it's run on). For all of these, interactive
> >> placing and moving with a mouse is difficult if we only use the d.* command
> >> modules. While I can click and send coordinates to d.barscale (like we can
> >> do in the TclTk GUI), I don't know how I could grab a north arrow with a
> >> mouse and drag it to reposition it in another locale on the screen using
> >> d.barscale. However, I can do that with wxPython generated graphics.
> >>
> >>>
> >>>> It's not hard to add a layer
> >>>> managers for d.grid, d.text, d.scalebar, etc. But it could clutter up the
> >>>> main control more.
> >>>>
> >>>> What if we could make it scriptable using wxPython graphic elements?
> >>>
> >>> I'm not entirely sure what you mean by that.
> >>>
> >>> But, essentially, I feel that it should be possible to save the
> >>> contents of the display as a script which will work on a system with
> >>> only core GRASS modules (no Python, no X server; can you render
> >>> wxPython graphics into an image file on a system with no X server?).
> >>
> >> NVIZ can be scripted, but you can't render an NVIZ image without NVIZ. I
> >> don't see that as a problem. If you want to render a 2.5D or 4D image, you
> >> need NVIZ. There is no way to render this using plain vanilla GRASS
> >> commands. I wouldn't want to not have this tool simply because we couldn't
> >> render its images with plain command line C modules.
> >>
> >> I'm a very big advocate of GRASS's scripting potential. I've written a
> >> number of scripts. And this scriptability is what makes it possible to wrap
> >> the commands in a nice GUI. But as you've pointed out, there are limitations
> >> to graphic output rendering from command-line modules alone. Continued
> >> improvements to ps.map may be a way to achieve this. Perhaps it could be
> >> made to render to a PNG or PPM file as well as a postscript one. Just some
> >> thoughts.
> >>
> >> Michael
> >>
> >> __________________________________________
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> grassgui mailing list
> >> grassgui at grass.itc.it
> >> http://grass.itc.it/mailman/listinfo/grassgui
> >>
> >
>
> __________________________________________
> 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
>
>
>
> _______________________________________________
> grassgui mailing list
> grassgui at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassgui
>

-- 
-- Daniel Calvelo Aros