[GRASS-dev] Re: g.gui

[Hamish]

> > I am not sure of what the logic is supposed to be if the current
> > GRASS_GUI setting was "text" or unset? Why bother with that at all?
> > The type= answer has to be one of the GUIs.
> > Note that strcmp() returns 0 if the strings are the same.
> 
> The initial idea was to set type->answer to "tcltk" when GRASS_GUI is
> unset or is "text".

That is ok if it's unset; if it is "text" there are two cases:
1) power user working from the command line (me)
2) confused new user, user with broken X, advanced user doing tests

In case 1 I don't want that reset, but I can use the -u flag.
Sometimes I use grass remotely over ssh without an X-mon (batch
processing, travelling, ..). I'm pretty sure Markus does this too.
A user not familiar with g.gisenv could get locked out when they try to
restart and it's locked in tcltk mode?? (not sure if that could really
happen, but it is something to think about)

For case 2 you probably do want to reset it back to something sane.

 
> > Also that calls G_store() before G_parser(), and G_store() calls
> > G_malloc() which can call G_fatal_error(), which must not be called
> > before G_parser() has been called.
> 
> Can you explain in detail why G_fatal_error() cannot be called before
> G_parser()?

Search the archives for "G_parser+Glynn" and you'll find a few (dozen).
;)

here's the one which made it into the G_parser() Doxygen comments:
  http://article.gmane.org/gmane.comp.gis.grass.devel/12461/


I don't know if G__getenv() is ok to use or not, you'd have to pour
through it [G_getl2() ...] and/or ask on the mailing list. Perhaps
Glynn's tools/sql.sh helps explore what it needs?


> > is type= the best word to use as the option name?
> >   gui=? start=? (like d.mon)   launch=?  ???= ?
> 
> 'type' refers to GUI type meaning, it is not the best. I would be
> happy to change it to something better then 'type'.

I don't really have a better solution, just that type= feels wrong.
Ask on grass-dev for suggestions?


> > Can the wxgui startup take a saved project file as a command line
> > option like d.m and gis.m? (dmrc=)
> 
> yes, it is possible

ok, I think we should rename the option though. "dmrc" goes back to d.m
and stands for 'display manager run commands', in the traditional sense
like a .bashrc script containing UNIX commands. Our .grassrc6 file
often confuses people who try to put .grass.bashrc commands in it, and
that filename is scheduled to be changed to something better in GRASS
7.

state=? (like nviz)  project=?   ???
  again, I don't have any very good ideas, maybe ask on grass-dev


>>>>>    5. copy wxgui script to $GISBASE/etc/wxpython (not to
>>>>> $GISBASE/scripts)
> > >
> > > I think we can do this step too (before 6.3.0/1), just to test
> > > now g.gui module.
> >
> > Thinking again about what to name that- as it is a grass program
> > shouldn't we try for some "g.module" style name?  {m|d|g}.wxgui?
> 
> g.wxgui would be maybe better then wxgui. Anyway I would prefer not
> to copy this script to $(ETC)/scripts in the future, and to launch
> wxGUI only via g.gui module.

I think that launching only via g.gui is fine. Power users can always
call $GISBASE/etc/wx/wxgui if they like, but "g.gui" is so easy I don't
know why they would.  If we put it in $ETC it wouldn't need to conform
to the g.* style.



Hamish



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs