Problem with X11 version of GnuCash on MacOSX

[Geert Janssens]

Mike,

I looks like my response sounded more negatively than I intended. I had a feeling there was 
something not quite right, but I have a hard time pointing it out properly.

Your solution isn't bad at all. I do consider MacPorts a different platform from OSX/Quarz just 
like I consider MingW and Cygwin on Windows different platforms. But I guess this doesn't 
matter.

You make a valid point that users may have reasons unknown to us to override the default 
XDG_DATA_DIRS. My doubt here is if GnuCash should cater for it, especially at compile time. We 
do already take runtime exceptions into consideration by wrapping the XDG_DATA_DIRS 
environment variable. That's what the X Free Desktop specification prescribes.

But again I'm only pointing at a subtle conceptual issue, which in itself can be ignored from now 
on. I can understand you don't want to set the environment variable in your runtime 
environment, nor wrap gnucash with a launcher script.

By thinking and talking about this, I found another issue with the current code: discoverability. 
To know you can override the data dir default at compile time, you will need to read the code. 
You can know this is possible only through a comment and the added variable in the makefile .

You already hinted at using a configure parameter. I think that's the proper fix and if done right 
can make the solution even more universal.

Suppose you create a configure parameter --with-default-xdg-data-dirs=....

If not explicitly set, the default value for this parameter could be "/usr/local/share;/usr/share". In 
the makefile, the hard-coded paths can be replaced with the configure time parameter.

So if the configure parameter is not set, the line that gets added to the environment file ends in 
"/usr/local/share;/usr/share". If you set the parameter to "/opt/local/share", the environment line 
will end in that.

What do you think of this ?

Geert

On Tuesday 22 October 2013 12:09:59 Mike Alexander wrote:
> --On October 22, 2013 11:26:33 AM +0200 Geert Janssens
> 
> <janssens-geert at telenet.be> wrote:
> > I have been pondering this for a while. I don't really like this fix
> > conceptually. It's MacPorts that deviates from the X Free Desktop
> > standard and I don't like it that this exception in one platform
> > only
> > results in changed code on all other platforms.
> > 
> > A better solution would be to detect the MacPorts platform at
> > configure  time, and set a proper conditional based on this, which
> > is
> > then used in  the makefile to do some MacPorts specific overrides.
> > That makes it  easier for other developers to understand as well
> > which particular  change is for that platform only.
> > 
> > But while thinking this alternative approach through, I concluded
> > that  it may even make the issue more complicated. So for now I have
> > chosen to  elaborate the comment in the makefile a bit to clarify
> > *why* the compile  time value of XDG_DATA_DIRS was added.
> 
> I didn't think I was putting in a special case for MacPorts.  Instead
> I thought of it as letting people configure a special value for the
> data directory search path for whatever reason.  If you would rather
> do it with a configure option that would be ok too (maybe better),
> but this seemed reasonable and easier.  Either way, it's essentially
> a configure option that lets you specify the directory search path. 
> Is that so unreasonable?  True, it's MacPorts that triggered the
> need, but it's not really specific to MacPorts.
> 
> Auto detecting MacPorts won't be easy since it can be installed
> anywhere.  I personally have two copies installed in different places.
> One is in the normal /opt/local directory while I also have another
> version installed elsewhere for testing.  You also need to think of
> other ways that these files might be installed in non standard
> locations.  Are you also going to put in special cases for Fink and
> Homebrew?  I happen to prefer MacPorts, but both of those have
> followers too (maybe not Fink, I haven't heard much about it
> recently, but certainly Homebrew does).  I don't know where they
> install this stuff.  Of course it's also possible for someone to
> install it by hand anywhere they want to.
> 
>         Mike