[GRASS-dev] GUI platforms

Tue May 23 00:02:01 EDT 2006

Trevor,

Thanks for the feedback. My answers below.

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

> From: Trevor Wiens <twiens at interbaun.com>
> Date: Mon, 22 May 2006 21:45:08 -0600
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass developers list <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] GUI platforms
> 
> On Mon, 22 May 2006 14:32:08 -0700
> Michael Barton <michael.barton at asu.edu> wrote:
> 
>> The recent discussion over where to head in terms of GUI platforms for GRASS
>> is very useful. Here are some suggestions about how to proceed and structure
>> this important design decision. Please feel free to suggest or amend.
>> 
>> Primary functions of the GRASS GUI:
>> 
>> 1. Provide a GUI interface for GRASS program modules. This includes simple
>> dialogs and more complex modules like v.digit that also require
>> visualization
> 
> Do you envision something that would be a plugin replacement for
> g.parser that would possibly allow for more interactive dialogues, but
> would allow existing modules to work without modification. If so I
> think this would be ideal, but not being familiar with that code I
> don't know what is possible.

I'm talking about functionality at a conceptual level, not implementation.
How to do this might vary depending on the platform chosen. Since (I think)
g.parser is specific to TclTk, a new version would need to be written that
is not--either in the GUI platform or in GRASS functions/libraries.

> 
>> 2. Provide a CLI interface for GRASS program modules
> 
> Do we need to drop bash? If so a lot of existing modules and add on's
> will go away or need to be ported for 6.3. Or do we envision providing
> something like a language based shell (eg Python) as well as bash for
> 6.3 to allow for transition and dropping shell programming for 6.4 or
> 6.5 (I now way out in the future, but worth thinking about so we don't
> make short term decisions that limit that vision).

We should NOT drop Bash--or any other scripting language currently use. The
point here is if we don't require X11, you can't depend on a terminal being
there (e.g., in Windows or Mac). So the GUI should include a command line
interface to make sure that it will be possible to issue grass commands and
run any script whether GRASS is launched from a terminal or not. We've
already done that to a large extent--initially with my command console and
now with Cedric's gronsole. You can enter any command there that the shell
will accept, as well as GRASS commands.

> 
>> 3. Manage graphical display/visualization for GRASS geospatial
>> data--particularly raster and vector files, but also including display
>> enhancements like profiles, scales, text, grids, etc. This also includes
>> 2.5-3D display handled by NVIZ and output of graphical displays to files for
>> inclusion in other applications.
>> 4. Manage non-graphic output from GRASS commands--normally as text.
> 
> For example something that will parse text and convert it to a gui
> format?

That would be nice. But again, this is a function of not being able to
depend on the presence of an X11 terminal. So text output from commands will
need to end up somewhere. Currently it goes either to the module dialog
output tab window or to the gronsole (primarily for display-related
commands). In whatever manner, the GUI needs to handle output from GRASS
commands in a consistent (and hopefully elegant) manner.

> 
>> 5. Provide an interface for interactive attribute management for vector
>> data. This is not currently handled in the GUI, but could be.
> 
> Yes, this would be highly desirable.

I agree. If we were sticking with TclTk, I think I almost have the knowledge
to create this.

> 
>> 
>> Some questions to ask about GUI platforms (not necessarily in order of
>> priority):
>> 
>> 1. Is it open source and compatible with GRASS's GPL license?
>> 2. How well can it accomplish the GUI functions? Most especially important
>> is how it can handle the display/visualization management since GRASS's
>> modular structure makes creating an interface to most commands relatively
>> straightforward (digitizing and georeferencing being notable exceptions).
>> 3. How well can it create a consistent and platform-appropriate interface
>> across the many OS platforms on which GRASS runs? Ideally, we should only
>> have to code the GUI once in order to deploy it across multiple platforms.
>> In order for GRASS to be used easily on these platforms, how well can it do
>> this without relying on X11?
>> 4. How easily can it be used by GRASS's volunteer developer community, most
>> of whom are researchers? This is important for both development and longer
>> term maintenance.
>> 5. Does it require any special tools for development that might be of
>> limited availability? Are open source development tools available for all
>> platforms on which it runs?
>> 6. Does it require any special packages to run that would significantly add
>> to GRASS's overhead or make installation more difficult?
> 
> I think the opposite is a better way to think about this, can we in
> fact lighten the load. The fewer dependencies possible without giving up
> functionality is highly desirable from a maintenance and distribution
> point of view.

Again, I agree. However, I have to say that compared with other GIS's of
comparable ability, GRASS's footprint is pretty small--even if you include
all related libraries.

> 
>> 7. How well and easily can it create a GUI that is easy to use--for both
>> newcomers and experienced GRASS users--and visually appealing?
> 
> 8. Does the platform under consideration create another potential
> rewrite down the road. Right now we are talking about a complete
> rewrite, because of the limitations of Tcl/Tk. I don't think we want to
> find ourselves in this situation again any time soon, so if we come
> down to two or three options and find that one will work for now, but
> may limit us in the future, we probably want to remove it from
> consideration.

Absolutely. TclTk has been with GRASS for about a decade. This is pretty
good. If any new GUI platform lasts this long, it will be great.

> 
>> 
>> Suggestions for the next steps:
>> 
>> 1. Given comments over the past few months, it seems that developers and
>> users are generally satisfied with the design direction GRASS has taken.
>> Unless there strong arguments to the contrary, I suggest that we 'freeze'
>> this for GRASS 6.2 and simply work on bugs (tweaks, error trapping, fixing
>> region issues, finding and fixing other errors). I can try working on an
>> ipoints replacement if the general freeze for 6.2 drags on for awhile, but
>> am hesitant to put an inordinate amount of work into it if we are going to
>> change to a new platform soon. There are some other design issues that are
>> very much worth considering (e.g., replacing some or most of the menu
>> hierarchy with a toolbox approach, offering multiple display modes,
>> integrating 2D and 3D visualization in some way, creating an interface for
>> vector attribute management), but which can be left to 6.3.
>> 
>> 2. Continue discussions as needed on GUI platforms. Once the 6.2 freeze is
>> in, take a vote on which platform to use. It would really help if people who
>> have some familiarity with whichever platform we choose are willing to help
>> start porting the GUI to that platform.
> 
> I like the idea of taking some time to think about this as I am finding
> I am continuing to learn about different options as this discussion
> unfolds.

No need to delay this unnecessarily. The sooner we decide on a platform and
get started, the sooner we can get to GRASS 7 :)

Nonetheless, this is a big decision and we should not rush into it.

Cheers
Michael

> 
>> 
>> 3. Start GUI development for 6.3 in the new platform. Revisit existing
>> design issues so that they can be addressed in the new platform.
>> 
>> 
> 
> Thanks Michael. 
> 
> T
> -- 
> Trevor Wiens 
> twiens at interbaun.com
> 
> The significant problems that we face cannot be solved at the same
> level of thinking we were at when we created them.
> (Albert Einstein)