[GRASS-dev] backgrounding wxGUI, defaults for 6.x

GRASS GRASS developer
1

Hi,

Is it possible to have g.gui detach the GUI from the terminal prompt?
That is typically what you'd want to happen. ^Z + bg are redundant
keystrokes / cumulatively lost moments. The man pages shouldn't have
to suggest to do "g.gui $GUI &". g.gui isn't the program, it's just
the launcher.

I am trying 6.5 with default wx on Debian/Etch which has no wx2.8 in it.

"g.gui" fails cleanly enough with an error message that there is no wx,
but it feels sort of like a "what now?" situation. ("g.gui --ui" isn't
exactly an obvious solution, maybe put that in the init.sh startup help)

at least the module GUIs are still tcl/tk so you can use them.

if we set the default wx now we are in practice making wxwidgets a
mandatory dependency for that release. (not technically, but it can
seem that way)

Probably wx2.8 has made it into most systems these days; I'm just
wondering how best to facilitate the fail-safe mode.

Hamish

2

Hello,
I still think that setting inmature GUI as default one isn't the best
idea. On my ~amd64 box I'm unable to start wxgui with g.gui (no
error), launch from init.sh almost works (just tested - recent svn up
has fixed some actions with NULL/NotAnObject). New wxgui will be
really good UI, still right now I still preffer old gis.m.

Sorry for rant,
Maris.

2009/9/22, Hamish <hamish_b@yahoo.com>:

Hi,

Is it possible to have g.gui detach the GUI from the terminal prompt?
That is typically what you'd want to happen. ^Z + bg are redundant
keystrokes / cumulatively lost moments. The man pages shouldn't have
to suggest to do "g.gui $GUI &". g.gui isn't the program, it's just
the launcher.

I am trying 6.5 with default wx on Debian/Etch which has no wx2.8 in it.

"g.gui" fails cleanly enough with an error message that there is no wx,
but it feels sort of like a "what now?" situation. ("g.gui --ui" isn't
exactly an obvious solution, maybe put that in the init.sh startup help)

at least the module GUIs are still tcl/tk so you can use them.

if we set the default wx now we are in practice making wxwidgets a
mandatory dependency for that release. (not technically, but it can
seem that way)

Probably wx2.8 has made it into most systems these days; I'm just
wondering how best to facilitate the fail-safe mode.

Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

Hamish wrote:

Is it possible to have g.gui detach the GUI from the terminal prompt?
That is typically what you'd want to happen. ^Z + bg are redundant
keystrokes / cumulatively lost moments. The man pages shouldn't have
to suggest to do "g.gui $GUI &". g.gui isn't the program, it's just
the launcher.

Change g.gui to use G_spawn_ex() with SF_BACKGROUND.

--
Glynn Clements <glynn@gclements.plus.com>

4

Hamish wrote:

> Is it possible to have g.gui detach the GUI from the terminal prompt?

Glynn:

Change g.gui to use G_spawn_ex() with SF_BACKGROUND.

excellent. please review r39283; AFAICT this is the first use of that
signal in the code.

After about 10 seconds of testing I discovered that it would be useful to
add a G_sleep(3) as well.

which then makes me wonder why it takes so long to start up, even
the second time in a row, when it should all still be cached, it is
seemingly not so fast on an otherwise fast computer.

hmmm,

svn/grass65$ find | grep '\.pyc$'
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/globalvar.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/images/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/icons/__init__.pyc
./swig/python/NumPtr.pyc
./swig/python/python_grass6.pyc

shouldn't wxgui.py byte-compile itself into wxgui.pyc the first time
it is run? (as this is portable and after installation the user might
not have permissions to write the file, so should a 'python wxgui.py
--test' or something be added to the Makefile to get the .pyc built/
installed?)

see swig/python/README item #4.

Hamish

5

Hamish wrote:

After about 10 seconds of testing I discovered that it would be useful to
add a G_sleep(3) as well.

For what reason? To give the GUI time to show itself?

which then makes me wonder why it takes so long to start up, even
the second time in a row, when it should all still be cached, it is
seemingly not so fast on an otherwise fast computer.

What do you mean by "start up"? The time until the windows appear?

I added some debug statements to the top levels of wxgui.py, to see
where the delays appear. The break down is ~0.6 seconds for the import
statements, ~0.2 seconds to create and show the splash screen, ~1.5
seconds for the call to GMFrame() in GMApp.OnInit(), resulting in ~2.3
seconds in total for the startup (i.e. until app.MainLoop() is
called).

FWIW, I don't normally see the splash screen; changing the wx.Yield()
call to wx.SafeYield() causes it to appear consistently. Using
wx.SafeYield() is probably a good idea for reasons of robustness;
recall the problems caused by calling "update" in gis.m (progress bar)
and NVIZ (Save Max. Res. PPM).

hmmm,

svn/grass65$ find | grep '\.pyc$'
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/globalvar.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/images/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/icons/__init__.pyc
./swig/python/NumPtr.pyc
./swig/python/python_grass6.pyc

shouldn't wxgui.py byte-compile itself into wxgui.pyc the first time
it is run?

Modules which are imported should byte-compile themselves, provided
that the permissions allow it. But Python files which are run as
__main__ (i.e. "scripts") aren't byte-compiled.

(as this is portable and after installation the user might
not have permissions to write the file, so should a 'python wxgui.py
--test' or something be added to the Makefile to get the .pyc built/
installed?)

Python.make has the following pattern rule:

  %.pyc: %.py
    $(PYTHON) -m py_compile $<

So you should be able to use:

  $(MAKE) $(ETCDIR)/wxgui.pyc

to generate a .pyc file during the build process.

--
Glynn Clements <glynn@gclements.plus.com>