[GRASS-dev] Re: g.gui

[Martin Landa]

Hi,

2008/2/13, Hamish <hamish_b at yahoo.com>:
> > > 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.

I am quite sure there are more users which prefer CLI. Even me before
I was involved in GUI development I used only CLI in GRASS:-)

What about changing -u flag to 'Modify default GUI setting', so
GRASS_GUI would be touched only if -u is given.

> 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/

ok, I should study the code a little bit more:-)

> 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?

Suggestions are always welcomed...

> > > 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

'project' would be good or e.g. 'workspace' (it is called in GUI
'workspace file'). I am not sure if 'workspace' makes sense here,
maybe calling it 'project' is better, suggestions?

> >>>>>    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.

BTW, are we going to backport g.gui to 6.3?, maybe not. For now maybe
renaming wxgui to g.wxgui make sense (at least for 6.3.0).

Martin

-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *