what's going on in r39326

[hamish-2]

hi,

can someone please explain to me what is happening in this change?
I don't understand what it does.

https://trac.osgeo.org/grass/changeset/39326



thanks,
Hamish
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Maris Nartiss]

You need more comments to such small code ammount?
Reason: launch Your file manager (Dolphin, Konqueror, Nautilus etc.),
navigate to /usr/bin/ and click on grass65 to start GRASS. Before this
patch gis.m was starting fine without any terminal (xterm), still
after exiting from gis.m, init.sh doesn't clean up - leves .lock's
etc. This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.
test -t 0 - check if stdin is connected to terminal
xdg-terminal - utility from Portland project that should start user's
preffered terminal (xdg-utils CVS only. Present on Debian and iirc
Fedora)
exec xterm -e - execute xterm and launch provided programm in xterm.
-e is supported by most (if not all) xterm like terminals (konsole,
gnome-terminal et.al). If user has set GRASS_XTERM in his gisrc file,
then it replaces xterm.

I hope now You understand how insignificant this change is, as
"normal" users don't play around with their file browsers.

Maris.


2009/9/29, Hamish <[hidden email]>:

> hi,
>
> can someone please explain to me what is happening in this change?
> I don't understand what it does.
>
> https://trac.osgeo.org/grass/changeset/39326
>
>
>
> thanks,
> Hamish
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/9/29 Maris Nartiss <[hidden email]>:
> You need more comments to such small code ammount?

[...]

probably Hamish is not alone who appreciated more comments, at least also me;-)

Thanks for clarification, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Benjamin Ducke]

Come on now, Maris, be fair. We all know shell code
gets more cryptic the shorter it is ;)

But does that mean there is no longer any way to start
GRASS without also launching a terminal emulator?
Personally, I don't mind (and neither will probably anyone
who uses a Unix system). However, I was under the impression
that it was desirable to have a way to start GRASS
with no terminal attached, especially for Windows users.

Plus, one of the long-term goals for GRASS was to drop
all dependencies on bash. I don't know in how far an
enforced terminal window agrees with that.

The problem with init.sh remains, of course. But surely
that could be handled by an exit function in gis.m?

But maybe I am thinking in the wrong direction here...

Ben

----- Original Message -----
From: "Maris Nartiss" <[hidden email]>
To: "Hamish" <[hidden email]>
Cc: "grass-dev" <[hidden email]>
Sent: Tuesday, September 29, 2009 9:04:57 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [GRASS-dev] what's going on in r39326

You need more comments to such small code ammount?
Reason: launch Your file manager (Dolphin, Konqueror, Nautilus etc.),
navigate to /usr/bin/ and click on grass65 to start GRASS. Before this
patch gis.m was starting fine without any terminal (xterm), still
after exiting from gis.m, init.sh doesn't clean up - leves .lock's
etc. This patch just launches somekind of interactive terminal/konsole
if there isn't one. It should not affect anyone who is launching GRASS
in "normal" way - from terminal/console or by shortcut that starts
some console.
test -t 0 - check if stdin is connected to terminal
xdg-terminal - utility from Portland project that should start user's
preffered terminal (xdg-utils CVS only. Present on Debian and iirc
Fedora)
exec xterm -e - execute xterm and launch provided programm in xterm.
-e is supported by most (if not all) xterm like terminals (konsole,
gnome-terminal et.al). If user has set GRASS_XTERM in his gisrc file,
then it replaces xterm.

I hope now You understand how insignificant this change is, as
"normal" users don't play around with their file browsers.

Maris.


2009/9/29, Hamish <[hidden email]>:

> hi,
>
> can someone please explain to me what is happening in this change?
> I don't understand what it does.
>
> https://trac.osgeo.org/grass/changeset/39326
>
>
>
> thanks,
> Hamish
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev



------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Tue, Sep 29, 2009 at 9:04 PM, Maris Nartiss <[hidden email]> wrote:
> This patch just launches somekind of interactive terminal/konsole
> if there isn't one. It should not affect anyone who is launching GRASS
> in "normal" way - from terminal/console or by shortcut that starts
> some console.

Well, but how about the batch mode? I cannot dig into your code right
now to understand if that's broken now... I am using scripts to launch
GRASS batch jobs. That continues to work? I hope so :)

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Maris Nartiss]

Hello everyone.
I was not expecting so much communication for such little change. I
must blame my language sk33lz as I'm not able to explain what it does
;)

First - Markus - only way how to really check wheither batch jobs are
broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
env variable You should be just fine.

Second - what was broken, still is broken. GRASS still fails to launch
with tcsh and other sh/bash incompatible shells (grep export
lib/init/* |  wc -l).

Third - Benjamin - "Code that was hard to write should be hard to
read" ;) There has never been a way how to start GRASS by its launch
script without terminal. BATCH_JOB thing is a just hack-in to get
around init.sh legacy design. I seriously doubt that Windows users are
using sh to launch GRASS (especially /bin/sh), still, if they do, they
need a terminal. Normaly this change should affect only careless Linux
users.
This change is commited to 6.5 and probably after testing should go to
6.4. In GRASS 7 we can do what we want.
I have old patches lying around in GForge that where providing GUI
cleanup on shell exit and gis.m option to terminate GRASS session. I
will try to get tem into 6.5 asap.

Those, who don't get reason of this change, please, perform following
steps in GRASS 6.4:
1) Start file browser;
2) Navigate to grass64 executable file (/usr/bin/grass64);
3) Launch it;
4) Start GRASS (this will fail if default GUI is text);
5) Close GUI;
6) ps fax | grep -C 3 sh
Steps 1, 2 and 3 can be replaced with ALT+F2 grass64 <ENTER>
Notice - in step 6 You will see Init.sh process that avaits user
input, still it's stdin and stdout are not connected to any terminal.
Now it's impossible to cleanly terminate GRASS - only kill and then
manually clean up.

I hope now I have adressed everyones concerns. If something doesn't
work as it should because of this commit, then report it as a bug :)

Maris.


2009/9/29, Markus Neteler <[hidden email]>:

> On Tue, Sep 29, 2009 at 9:04 PM, Maris Nartiss <[hidden email]> wrote:
>> This patch just launches somekind of interactive terminal/konsole
>> if there isn't one. It should not affect anyone who is launching GRASS
>> in "normal" way - from terminal/console or by shortcut that starts
>> some console.
>
> Well, but how about the batch mode? I cannot dig into your code right
> now to understand if that's broken now... I am using scripts to launch
> GRASS batch jobs. That continues to work? I hope so :)
>
> Markus
>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Paul Kelly]

Hello all,
If I understand correctly, the patch is attempting to solve two separate
issues:

1) When starting GRASS by double-clicking on the grass64.sh icon, the user
doesn't get a terminal window in which to enter GRASS commands.

2) GRASS doesn't exit properly because the Init.sh runs in the background
waiting for user input that never arrives.

Point (1) seems to me just an issue of user preference. I would be wary of
anything that assumes the user is wrong, or the user doesn't know what
they want, which this fix seems to do. Perhaps they only want the GUI and
don't want a terminal window to pop up?

Regarding point (2), why not just launch the GUI in the foreground instead
of the background? When it exits, control will be returned to Init.sh
which can then clean up and exit. The check for whether there is no
terminal attached could be used to force GUI rather than text mode.

What do you think?

Paul
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

Hi Maris,

On Wed, Sep 30, 2009 at 9:59 AM, Maris Nartiss <[hidden email]> wrote:
> Hello everyone.
> I was not expecting so much communication for such little change. I
> must blame my language sk33lz as I'm not able to explain what it does
> ;)
>
> First - Markus - only way how to really check wheither batch jobs are
> broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
> env variable You should be just fine.

Well, I don't think that the concept could be to accept breakage of
existing things to fix another issue. In general, it should be task
of the person who makes the change to assure that functionality
close-by (same file) remains. At least as much as possible.

In any case, I'll test myself as well since the GRASS_BATCH_JOB
functionality is essential for my daily GIS work.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Maris Nartiss]

<rant>
It's impossible for single person who spends only hes free time for
development to check all possible scenarious on all possible
hardware/software versions. If code looks sane, we need to assume that
it works unless somebody provides evidence that it doesn't work. I
don't have a Mac (I saw one last year when we had guest lecturer from
Germany), nor grid running supercomputer, neither I run GRASS on
windows. Neither I can imagine any (abusive) way how GRASS is run or
used. Sorry. I have to relay on other GRASS developers who run such
software to test various GRASS parts. Linux developers break GRASS on
Mac. Mac developers break GRASS on Linux. Both break GRASS on Windows.
That's how GRASS development is going already for long time and I
don't see how it could be changed in nearerst future (unless somebody
get's paid for developing and testing everyting on anything). Unless
GRASS gets paid full time developer team, we have to accept, that
development branches (trunk, devel) migh be broken time to time and
that we (developers, users) have to keep an eye on any new bugs
introduced by ourselfs or others.
</rant>

As I wrote - if GRASS_BATCH_JOB is set, everything *should* be fine. I
tested on my Gentoo Linux box and GRASS was able to run from cron when
GRASS_BATCH_JOB was set. Still I can *not* give any guarantee that it
may not be broken on some rare system. Starting GRASS without
GRASS_BATCH_JOB by it's startup script (grassxy + init.sh) is abuse
and should be eliminated.

As for launching plain GUI without terminal - IMHO we should not
change this within 6.x timeframe. As I wrote - GRASS 7 is open for new
ideas.

As all of You like shell code ;-)  I commited anotherone snippet. Feel
free to discuss :P
https://trac.osgeo.org/grass/changeset/39350
(Not tested on Mac or Windows. wxGUI should be unaffected, still not
tested as wxGUI doesn't work on my Linux box at all (6.4, 6.5, 7).
wxGUI devs - what's happening if user closes terminal before closing
wxGUI? IMHO wxGUI also should be cleaned up in case of exit from GRASS
and also should provide a way how to terminate not only GUI but also
whole GRASS session.)

Maris (just freaking out).

PS. Now I understand why GRASS has issues. Such huge discussion for
small change and no serious feedback for large and serious changes as
per r39323 :(

2009/9/30, Markus Neteler <[hidden email]>:

> Hi Maris,
>
> On Wed, Sep 30, 2009 at 9:59 AM, Maris Nartiss <[hidden email]> wrote:
>> Hello everyone.
>> I was not expecting so much communication for such little change. I
>> must blame my language sk33lz as I'm not able to explain what it does
>> ;)
>>
>> First - Markus - only way how to really check wheither batch jobs are
>> broken is to test that. Theoretically if You have set GRASS_BATCH_JOB
>> env variable You should be just fine.
>
> Well, I don't think that the concept could be to accept breakage of
> existing things to fix another issue. In general, it should be task
> of the person who makes the change to assure that functionality
> close-by (same file) remains. At least as much as possible.
>
> In any case, I'll test myself as well since the GRASS_BATCH_JOB
> functionality is essential for my daily GIS work.
>
> Markus
>

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Wed, Sep 30, 2009 at 1:10 PM, Maris Nartiss <[hidden email]> wrote:
...
> PS. Now I understand why GRASS has issues. Such huge discussion for
> small change and no serious feedback for large and serious changes as
> per r39323 :(

Look: only on request you explained the change which can break
things five minutes before the final release. That's the "problem".
Of course it applies to all developers that review is needed and
should not end in a flame war.
Discussion is *not* an issue. It's called peer review instead.

Let's keep calm... :)

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Benjamin Ducke]

I think we have to acknowledge, though, that GRASS development
can get quite frustrating at this point. And think what we can do to
improve  the situation. If a dedicated developer turns away
from GRASS because it's no fun anymore, then we all lose.

There are many aspects to GRASS development right now, maybe too many
for a single developer to keep track of. A while ago, there was a
posting on this mailing list asking whether it would be possible to
separate the wxPython and GUI development out into an individual project.
Maybe that would be a start?

Getting back to the functional aspects, I would be in favour of
implementing behaviour like Paul suggested a moment ago:

"Regarding point (2), why not just launch the GUI in the foreground
instead of the background? When it exits, control will be returned
to Init.sh which can then clean up and exit. The check for whether
there is no terminal attached could be used to force GUI rather than
text mode."


Ben

Markus Neteler wrote:

> On Wed, Sep 30, 2009 at 1:10 PM, Maris Nartiss <[hidden email]> wrote:
> ...
>> PS. Now I understand why GRASS has issues. Such huge discussion for
>> small change and no serious feedback for large and serious changes as
>> per r39323 :(
>
> Look: only on request you explained the change which can break
> things five minutes before the final release. That's the "problem".
> Of course it applies to all developers that review is needed and
> should not end in a flame war.
> Discussion is *not* an issue. It's called peer review instead.
>
> Let's keep calm... :)
>
> Markus
> _______________________________________________
> grass-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: [phone] (switchboard)
Tel: [phone] (direct)
Fax :[phone]
[hidden email]




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

thanks all for the clarifications. The bit which was missing
for me was finding context for it due to the "why".


Paul Kelly wrote:
> If I understand correctly, the patch is attempting to solve
> two separate issues:
>
> 1) When starting GRASS by double-clicking on the grass64.sh
> icon, the user doesn't get a terminal window in which to
> enter GRASS commands.

this should be handled by ticking the "run in terminal" box
when setting up the launcher.


In the latest Debian package we have set 'needs="text"' in the
menu entry:
 http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.menu

(just added in svn65 source gui/icons/, other branches soon)


and "Terminal=True" in the desktop icon setup:
 http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.desktop

(already in source in gui/icons/)


and to complete the offerings a "x-grass" script for starting
grass in a terminal without needing to set it up as above.
for now it exits with error if it can't get a terminal.
 http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/x-grass

(this was debian bug#503371)


maybe those help.
IMO the packaging is the correct place to set this stuff up.


As mentioned by others there are valid times when you don't
want a terminal. (the WinGrass installers don't open terminals
unless you ask for them) [note some .sh replaced by .bat there]


> 2) GRASS doesn't exit properly because the Init.sh runs in
> the background waiting for user input that never arrives.

the above should take care of that. At least from the GRASS
desktop icon the last thing I see is "cleaning up temp files.."

veering off-topic:
IMO it is a mistake to have shutting down the GUI try to close
down the terminal as well. If GUI is started from the terminal
with g.gui this is definitely not what you want.


Paul:
> Point (1) seems to me just an issue of user preference. I
> would be wary of anything that assumes the user is wrong, or
> the user doesn't know what they want, which this fix seems
> to do. Perhaps they only want the GUI and don't want a
> terminal window to pop up?

I agree

> Regarding point (2), why not just launch the GUI in the
> foreground instead of the background? When it exits, control
> will be returned to Init.sh which can then clean up and
> exit. The check for whether there is no terminal attached
> could be used to force GUI rather than text mode.

fyi in 6.5 and 7 g.gui now backgrounds the gui, but the init.sh
and AFAIK guis themselves do not. (I think gis.m used to)


thanks,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Maris wrote:
> > PS. Now I understand why GRASS has issues. Such huge
> > discussion for small change and no serious feedback for
> > large and serious changes as per r39323 :(

this is known as the bike-shed problem, and is not unique to
GRASS, or even software. see
  http://en.wikipedia.org/wiki/Bike_shed
  http://bikeshed.com/


in this case I like to keep my head around everything that
Init.sh does, and saw something I couldn't follow. Education
and communication is universally good. Any modification to
the critical main startup script is by definition serious.



MN:
> change which can break things five minutes before the final
> release.

In Maris's defence, this change was only in 6.5. (?right?)


regards,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Maris Nartiss]

This is hottest topic of the month! Will I get extra geek points for
starting it?

2009/9/30, Hamish <[hidden email]>:
> thanks all for the clarifications. The bit which was missing
> for me was finding context for it due to the "why".
>
Yeah. Sorry. GRASS startup is a bit of code and a lot of black magick ;)

>
> Paul Kelly wrote:
>> If I understand correctly, the patch is attempting to solve
>> two separate issues:
>>
>> 1) When starting GRASS by double-clicking on the grass64.sh
>> icon, the user doesn't get a terminal window in which to
>> enter GRASS commands.
>
> this should be handled by ticking the "run in terminal" box
> when setting up the launcher.
>

Doesn't apply.
>
> In the latest Debian package we have set 'needs="text"' in the
> menu entry:
> http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.menu
>
> (just added in svn65 source gui/icons/, other branches soon)
>
Doesn't apply.
>
> and "Terminal=True" in the desktop icon setup:
> http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/grass.desktop
>
> (already in source in gui/icons/)
>
Doesn't apply.
>
> and to complete the offerings a "x-grass" script for starting
> grass in a terminal without needing to set it up as above.
> for now it exits with error if it can't get a terminal.
>  http://svn.debian.org/viewsvn/pkg-grass/packages/grass/trunk/debian/x-grass
>
> (this was debian bug#503371)
>
GRASS 6.5 should now work without any Debian-specific workarounds in
more universal way (non-hardcoded paths, xdg-utils from Portland
project).
>
> maybe those help.
> IMO the packaging is the correct place to set this stuff up.
>
This patch addresses those users who for some reason are NOT using
packagers provided way of running GRASS.
Consider following scenarios that now work correctly:
Joe The Averageuser compiles GRASS on Slackware (good old times) and
creates symlink on his Desktop to /usr/bin/grasXY
Jane The Poweruser uses KDE run quicklauncher to start grassXY (thus
NOT using any .desktop files with proper terminal=required
mumbo-jumbo).
>
> As mentioned by others there are valid times when you don't
> want a terminal. (the WinGrass installers don't open terminals
> unless you ask for them) [note some .sh replaced by .bat there]
>
Valid time users use valid approaches. If something works by accident,
it shouldn't be considered a norm.
>
>> 2) GRASS doesn't exit properly because the Init.sh runs in
>> the background waiting for user input that never arrives.
>
> the above should take care of that. At least from the GRASS
> desktop icon the last thing I see is "cleaning up temp files.."

You can't see anything without a terminal.
>
> veering off-topic:
> IMO it is a mistake to have shutting down the GUI try to close
> down the terminal as well. If GUI is started from the terminal
> with g.gui this is definitely not what you want.
>
As GRASS 6.x consists of CLI part (terminal) and GUI *on top of it*, I
agree. My commits don't change GRASS 6.x components (CLI+GUI).  If we
are dropping CLI (terminal) in GRASS 7, then startup parts and GUI
should be build there (trunk) around new paradigm but, please, do not
change 6.x version.
Still in r39350 I have added gis.m option to terminate GRASS session
besides usual exit gis.m option. It's a bit of kludge as gis.m is not
tightly coupled with other GRASS parts (Init.sh). It migh require
aditional hacking on Mac and Windows to provide equivalent
functionality there (no idea). Still it's better than nothing.
>
> Paul:
>> Point (1) seems to me just an issue of user preference. I
>> would be wary of anything that assumes the user is wrong, or
>> the user doesn't know what they want, which this fix seems
>> to do. Perhaps they only want the GUI and don't want a
>> terminal window to pop up?
>
> I agree
GRASS 6.x paradigm is CLI + GUI. It's how it is designed and most of
existing tutorials also assume presence of terminal that provides CLI.

>
>> Regarding point (2), why not just launch the GUI in the
>> foreground instead of the background? When it exits, control
>> will be returned to Init.sh which can then clean up and
>> exit. The check for whether there is no terminal attached
>> could be used to force GUI rather than text mode.
>
> fyi in 6.5 and 7 g.gui now backgrounds the gui, but the init.sh
> and AFAIK guis themselves do not. (I think gis.m used to)
>

If GUI doesn't release terminal after startup in GRASS 6 (on Linux),
it should be considered a bug and should be fixed. gis.m does this,
can't test wxgui, as it's still broken on Linux.
>
> thanks,
> Hamish
>

All of You have three options:
fix code/report bug/revert

Can we move on?
Maris.
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

no time for a full reply now but,

the .desktop and .menu are not entirely specific to Debian and
are provided as uninstalled templates as a convenience to the
source code user, if only for inspiration. If they were to be
added to the Makefiles they would be renamed *.in and have paths
filled in at build time.

Maris wrote:
> Consider following scenarios that now work correctly:
> Joe The Averageuser compiles GRASS on Slackware (good old
> times) and creates symlink on his Desktop to /usr/bin/grasXY

Joe as a slackware user should know better than to do that
with a terminal app.

> Jane The Poweruser uses KDE run quicklauncher to start
> grassXY (thus NOT using any .desktop files with proper
> terminal=required mumbo-jumbo).

Jane as a power-user should know that she has to tick the
"Terminal required" box in the quicklauncher setup. She
doesn't have to know about the internals of the quicklauncher
mechanism.


> Valid time users use valid approaches. If something works
> by accident, it shouldn't be considered a norm.

I don't really understand your meaning, but current GRASS 6.x
on MS-Windows without a terminal is no accident. It's the result
of a lot of hard work.


Hamish:
> > veering off-topic:
> > IMO it is a mistake to have shutting down the GUI try
> > to close down the terminal as well.

fwiw I wrote that before I noticed your latest commit, and was
speaking about automatic shutdown on exit, not user-chosen.

I don't want to tell folks what to work on, but as mentioned
in the nviz email, at some point we should stop adding new
features to the tcltk stuff and focus development in trunk on
wx things. [this one had been discussed in the ML and trackers,
and so was already in the pipeline so isn't exactly "new"]


regards,
Hamish




_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Ciao tutti,

2009/9/30 Maris Nartiss <[hidden email]>:

[...]

> (Not tested on Mac or Windows. wxGUI should be unaffected, still not
> tested as wxGUI doesn't work on my Linux box at all (6.4, 6.5, 7).
> wxGUI devs - what's happening if user closes terminal before closing
> wxGUI? IMHO wxGUI also should be cleaned up in case of exit from GRASS
> and also should provide a way how to terminate not only GUI but also
> whole GRASS session.)

simply wxGUI remains broken, please fill ticket for that. Personally
no time to fix it.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn Clements]

Maris Nartiss wrote:

> I hope now You understand how insignificant this change is, as
> "normal" users don't play around with their file browsers.

Actually, it's quite fundamental. The split between the grassXX script
and Init.sh is quite deliberate; the grassXX script sets GISBASE then
invokes Init.sh, and that's all it does. Everything which can go into
Init.sh does so.

Obviously, setting GISBASE can't go into Init.sh, because $GISBASE is
needed to locate Init.sh. The whole point of the split is so that
Init.sh doesn't contain any hard-coded paths. The one and only
hard-coded path (GISBASE) goes into the grassXX script, and everything
else goes into Init.sh.

Unless someone has beaten me to it, I will revert r39326.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev