QGIS » QGIS Application

Same problem as the now closed #255?

Replying to [comment:1 g_j_m]:

Same problem as the now closed #255?

I don't think so, it looks like something OSX and file chooser specific...

This is not user error as to the meaning of $GISBASE.
I can't select the $GISBASE dir as it is greyed out.

Hamish

Works for me on Linux. It seems to be OSX specific.
It is using QFileDialog::getExistingDirectory

Troll doc:
"Under Windows and Mac OS X, this static function will use the native
file dialog and not a QFileDialog. On Mac OS X, the dir argument is ignored,
the native dialog always displays the last visited directory."

I have no idea why it should not work on OSX.

Radim

Hint:

The folder is in /Applications/Grass/grass6.app/ but the File Dialog automatically translates the directory name into "grass6" dropping the ".app". (If you look in the Applications folder you just see the program names without .app). I expect this name munging is the root of the problem.

AFAICT there is no way to type $GISBASE by hand in the OSX GUI, you must pick with the mouse.

Is the value stored in a text file (or sqlite db) in ~/.qgis/ or somewhere where I can hack it in manually?

Q: [cc grass-dev] if I symlink $GISBASE to something else not in /Apps/*.app/ then point QGIS to the symlink, will I enter into a world of pain?

Hamish

William Kyngesburye wrote:

A couple notes on the problem.

Hamish wrote:

I am trying to work around this QGIS GRASS-plugin bug:
https://svn.qgis.org/trac/ticket/346

(the OSX file picker won't let me select GISBASE which is within a
subdirectory of /Apps/GRASS.app/; it's greyed out)

Indeed, on OSX you can't navigate into an application package. And,
depending on Finder options, you may or may not see the .app
extension.

If it's a valid GRASS installation and was built against that
particular GRASS, it should work - a unix path can refer to something
inside an app package with no problem. As long as that GRASS is not
moved, Qgis GRASS plugin should find it and not ask for a GISBASE.
Once GRASS is moved, Qgis needs to ask where it now is.

If I start QGIS from the GRASS command line (your 6.2.1 package), then
$GISBASE is already set and the GRASS plugin works, but $GISBASE is not
stored.

If I start QGIS from outside GRASS it asks for GISBASE, but then I run
into the GRASS.app/ selection problem.

Indeed setting $GISBASE as an enviro var before launching QGIS from a
(non-GRASS) Terminal gets it to work.

Also to note WRT hardcoding paths: The first thing I did after
installing your GRASS.app was to rename it GRASS_6.2.1.app. Too many
machines in the student computer lab to keep track of details otherwise.
Also have that in a /Apps/Grass/ folder, as I store PDF instructions
manuals there too.

One solution I can think of, and that I'll probably do with my Qgis
binary in the future, is to package the necessary GRASS libraries and
support in the Qgis app. That way there are no worries of moving
GRASS around and having to set GISBASE, or making sure you have the
right GRASS version. It works for me with my GDAL framework -
currently my Qgis build uses the GRASS libraries I have in my GDAL
framework.

I wonder - are you using the Qgis.org download of Qgis and trying to
use my GRASS.app with it? This email implies that, though your Qgis
bug says Lorenzo's. There may be library version incompatibilities.

I am now working with the 0.8pre2 binary from qgis.org + your 6.2.1
package + your 17 Dec frameworks package.

Earlier I was working with Lorenzo's 6.2.0beta2 package + grasslibs.
These are now outdated & removed.

As for hacking the path, ~/Library/Preferences/org.qgis.qgis.plist.
Don't know the setting name to use, though. Maybe GRASS.GISBASE?

Yes, on the mac it seems to be ~/Library/Preferences/org.qgis.qgis.plist
But it is a binary file I don't know how to modify/browse that?

On linux it is stored in ~/.qt/qgisrc as a simple text file:
[grass]

gisbase=...

so "GRASS.GISBASE" is a good guess.

Or you could try using the GRASS libraries inside my GDAL framework -
you can navigate into a framework package. Or try my Qgis build ^_

In the future perhaps, but for now I would like to help fix this problem
at the root.

-----
William Kyngesburye <kyngchaos at kyngchaos.com>

http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

cheers,
Hamish

[_fwd from the grass-dev mailing list_]

From: William Kyngesburye <kyngchaos at kyngchaos com>

Cc: grass-dev grass.itc it

Subject: Re: [GRASS-dev] running with GISBASE as a symlink?

Date: Mon, 18 Dec 2006

To: Hamish <hamish_nospam yahoo com>

Hamish wrote:

Also to note WRT hardcoding paths: The first thing I did after
installing your GRASS.app was to rename it GRASS_6.2.1.app. Too many
machines in the student computer lab to keep track of details
otherwise.
Also have that in a /Apps/Grass/ folder, as I store PDF instructions
manuals there too.

I was thinking about the qgis.org build of qgis. My guess is that it
was built with Lorenzo's Grass, so that's where Qgis is going to try
by default. Renaming mine to the same as Lorenzo's (as a
possibility) probably wouldn't work because the internals are
organized differently.

As for hacking the path, ~/Library/Preferences/org.qgis.qgis.plist.
Don't know the setting name to use, though. Maybe GRASS.GISBASE?

Yes, on the mac it seems to be ~/Library/Preferences/
org.qgis.qgis.plist
But it is a binary file I don't know how to modify/browse that?

On linux it is stored in ~/.qt/qgisrc as a simple text file:
[grass]
gisbase=...

so "GRASS.GISBASE" is a good guess.

I hadn't noticed that it's a binary plist. I have the Xcode tools
installed, so it opens in Property List Editor. I think there's a
non-Xcode plist editor out there somewhere (shareware/freeware).

Or you could try using the GRASS libraries inside my GDAL framework -
you can navigate into a framework package. Or try my Qgis build ^_

In the future perhaps, but for now I would like to help fix this
problem
at the root.

Well, for workarounds, we can't do much about the OSX limitation
(except maybe the symlink, or the plist hacking). A rebuild of Qgis
to use some other GRASS is another possibility (the internal Grass
library idea would be a good choice).

Since you have my frameworks installed, the GRASS libs inside the
GDAL framework should work - I specifically tweaked that to support
Qgis, in addition to GDAL. This would be a usable short-term
solution, but I'm working on removing external linking to
GDAL.framework internals, and the Qgis-GRASS link is the last one
left. My next Qgis build will have GRASS libs embedded. Don't know
what Qgis.org will do with theirs, if anything.

Now that I think about it, I'm not sure relocating GISBASE will fully
work. When you start Qgis from within GRASS, do the GRASS functions
of the plugin actually work?

The problem I'm thinking of is the actual library links in the Qgis
GRASS plugin. They are hardcoded for the GRASS there were built
with, and I don't see a DYLD_LIBRARY_PATH used in Qgis, like it is in
the GRASS init.sh. Possibly it will work when started from GRASS,
since it might pick up the GRASS environment. But initiated from
Qgis, it doesn't appear to use GISBASE to set DYLD_LIBRARY_PATH, and
so won't find the original GRASS libraries. (did that make sense?)

-----
William Kyngesburye <kyngchaos kyngchaos com>

http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

[_fwd from the grass-dev mailing list_]

From: William Kyngesburye <woklist kyngchaos com>

Cc: GRASS developers list <grass-dev grass.itc it>

Reply-To: William Kyngesburye <kyngchaos kyngchaos com>

Subject: Re: [GRASS-dev] running with GISBASE as a symlink?

Date: Tue, 19 Dec 2006

To: Hamish <hamish_nospam yahoo com>

Oops, used wrong account to send last reply. Anyways, my brain
wouldn't let me sleep on this - I figured out a way to get around the
OSX package limitation:

1. in the Finder, contextual menu on GRASS.app and Show Package Contents

2. command-option-drag the "Contents" folder to the desktop to create
an alias

3. run Qgis and do what you need to do to get it to ask for GISBASE

4. use the alias on the desktop to navigate into the GRASS.app
package! Then you can locate and select your GISBASE.

'night

-----
William Kyngesburye <[email protected]>

http://www.kyngchaos.com/

Ok, I have been trying to get QGIS + GRASS toolbox to work with a full GRASS install. I have not been trying to get QGIS to work with GRASS files included in the QGIS package download.

I took the following to mean that it included the GRASS plugin, not that it included functional copies of the ported modules + minimum framework to allow those to run.

^1 All packages contain GRASS support unless otherwise indicated.

Am I mistaken? Does the qgis.org 0.8pre2 OSX build include parts of grass? I see libgrass_* in lib/grass/, and plugin bits in share/qgis/grass/.

If QGIS supplies enough GRASS to be self-contained, then presumably GISBASE becomes /Apps/qgis.app/something/? At which point it should be changed to automatically pick the internal (relative) location instead of prompting for an external GISBASE.

If not, why is QGIS distributing lib/grass/libgrass*.dylib?

some more tests:

• creating a shorcut on the desktop to GRASS.app/Resources/ then pointing QGIS's GISBASE file dialog to that gets you started, but it fails when you try and run a module (eg v.buffer)

• v.buffer works ok if QGIS was started from the GRASS terminal prompt.

• work-around idea: add 'export GISBASE="/Apps/GRASS.app/..."' to .bash_profile (no luck running a module)

When QGIS is started from outside GRASS, at the terminal:

$ GISBASE=/Apps/GRASS.app/.../Resources  /Apps/qgis.app/.../qgis

I open a GRASS mapset from the plugin menu, but when I click on a module I get this error:

Warning:
 Cannot read module description (v.to.rast)
 Unexpected end of file
 at line 1 column 1

sometimes when reclosing mapset I get this error:
Cannot close mapset. Cannot remove map set lock: /.../$MAPSET/.gislock

and in the term window:
dyld: Library not loaded: /usr/local/grass-6.2.1/lib/libgrass_gproj.dylib
Referenced from: /Apps/GRASS.app/.../r.in.gdal
Reason: image not found

I've never had GRASS in /usr/local/ on that machine...

I tried setting "export LD_LIBRARY_PATH=$GISBASE/lib", no luck.

When QGIS was started from within GRASS, it works fine and automatically picks up the current mapset.

Hamish

From: William Kyngesburye <kyngchaos kyngchaos com>

Cc: grass-dev grass.itc it

Subject: Re: [GRASS-dev] running with GISBASE as a symlink?

Date: Wed, 20 Dec 2006

To: Hamish <hamish_nospam yahoo com>

On Dec 19, 2006, at 10:27 PM, Hamish wrote:

I took the following to mean that it included the GRASS plugin, not
that
it included functional copies of the ported modules + minimum
framework to
allow those to run.

1 All packages contain GRASS support unless otherwise indicated.

I took a look at the qgis.org Qgis, and it appears to me like the
grass libs in the package are just for library linking for the GRASS
plugin/provider. A couple things that are normally found in the
GRASS etc folder are missing for QGis to consider this a "GISBASE".

some more tests:

• creating a shorcut on the desktop to GRASS.app/Resources/ then
  pointing
  QGIS's GISBASE file dialog to that gets you started, but it fails
  when you
  try and run a module (eg v.buffer)

Might be the DYLD_LIBRARY_PATH problem again. Or PATH missing the
GRASS bin and scripts folders.

• v.buffer works ok if QGIS was started from the GRASS terminal
  prompt.

sometimes when reclosing mapset I get this error:
Cannot close mapset. Cannot remove map set lock: /.../
$MAPSET/.gislock

and in the term window:
dyld: Library not loaded: /usr/local/grass-6.2.1/lib/
libgrass_gproj.dylib
Referenced from: /Apps/GRASS.app/.../r.in.gdal
Reason: image not found

I've never had GRASS in /usr/local/ on that machine...

That would be the DYLD_LIBRARY_PATH problem. Without the full GRASS
environment, GRASS commands can't find the GRASS libraries - it's
trying the original build location. Perhaps Qgis needs to do more
environment setup, like GRASS does in init.sh?

I tried setting "export LD_LIBRARY_PATH=$GISBASE/lib", no luck.

DYLD_LIBRARY_PATH

Looking at the grass init.sh, there are a few environment variables
that Qgis might need to set, if it doesn't already, based on GISBASE,
or that you could try from the Terminal as a test:

PATH, to find the GRASS module executables and scripts

DYLD_LIBRARY_PATH, for the libraries

ETC, for support for some modules

-----
William Kyngesburye <kyngchaos kyngchaos com>

http://www.kyngchaos.com/

Moved to milestone 0.8.2 since we wont be fixing any further issues before the 0.8.1 release

Milestone Version 0.8.2 deleted