Re: Accessing preferences from one application in another

[Vadim Zeitlin]

On Thu, 16 May 2013 03:35:09 -0700 (PDT) ___matthieu___ wrote:

> There is a GUI application (subclass of wxApp) that creates preferences and
> there is command line tool (subclass of wxAppConsole) that needs to access
> these preferences.

This is a not very typical case. I'm afraid wxStandardPaths doesn't
provide any convenient way to handle it.

> - If I print the preferences path in the GUI application, I get
> $HOME/Library/Preferences/appname Preferences
> - If I print the preferences path in the CLI tool, I get $HOME/appname
> Preferences
...
> Is this the normal behavior ?

Yes. Non-GUI applications use standard Unix conventions while GUI ones
uses OS X-specific conventions under OS X.

> Is there any way to have the path be the same so that I can access them
> whatever the base class ?

If you want to keep the file under ~/Library/Preferences (which is
probably a good idea as this is what Apple recommends), you'll have to hard
code this path in your non-GUI code, I'm afraid.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[___matthieu___]

On 16 mai, 13:39, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Thu, 16 May 2013 03:35:09 -0700 (PDT) ___matthieu___ wrote:
>
> > There is a GUI application (subclass of wxApp) that creates preferences and
> > there is command line tool (subclass of wxAppConsole) that needs to access
> > these preferences.
>
>  This is a not very typical case. I'm afraid wxStandardPaths doesn't
> provide any convenient way to handle it.
>
>
>
> > - If I print the preferences path in the GUI application, I get
> > $HOME/Library/Preferences/appname Preferences
> > - If I print the preferences path in the CLI tool, I get $HOME/appname
> > Preferences
> ...
> > Is this the normal behavior ?
>
>  Yes. Non-GUI applications use standard Unix conventions while GUI ones
> uses OS X-specific conventions under OS X.

Too bad. It seems version version 2.8.12 did not show this
behaviour
and the file in ~/Library/Preferences was used whatever the base
class.

> > Is there any way to have the path be the same so that I can access them
> > whatever the base class ?
>
>  If you want to keep the file under ~/Library/Preferences (which is
> probably a good idea as this is what Apple recommends), you'll have to hard
> code this path in your non-GUI code, I'm afraid.

Is there any way to know what change introduced/corrected the way
stdpaths works ?
The diff between 2.8.12 and the svn codebase is rather huge and I'd
like to know
if there is another way than hard coding the path (even though it is
a small and
rather stable hard-coded path)

Thanks for your time,

Matthieu

[Vadim Zeitlin]

On Thu, 16 May 2013 06:59:11 -0700 (PDT) ___matthieu___ wrote:

> Is there any way to know what change introduced/corrected the way
> stdpaths works ?

I don't remember this off hand, of course, but I think you should be able
to find it relatively easily by using "git log include/wx/stdpaths.h" to
view the candidate commits.

However, putting aside the issue of interoperability with the GUI aside, I
think the current situation is really better as it's unexpected for a
normal, console application to use these Mac-specific paths IMO.

BTW, another idea: perhaps you could build your console application as a
GUI one, i.e. using wxCore, but simply avoid showing any GUI from it?

[___matthieu___]

On 16 mai, 16:05, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Thu, 16 May 2013 06:59:11 -0700 (PDT) ___matthieu___ wrote:
>
> > Is there any way to know what change introduced/corrected the way
> > stdpaths works ?
>
>  I don't remember this off hand, of course, but I think you should be able
> to find it relatively easily by using "git log include/wx/stdpaths.h" to
> view the candidate commits.

I'll take a look, thanks.

>  However, putting aside the issue of interoperability with the GUI aside, I
> think the current situation is really better as it's unexpected for a
> normal, console application to use these Mac-specific paths IMO.
>
>  BTW, another idea: perhaps you could build your console application as a
> GUI one, i.e. using wxCore, but simply avoid showing any GUI from it?

It seems the most simple solution. I'l see that with the project
manager.

Thanks a lot.

[___matthieu___]

Hi,

On 16 mai, 13:39, Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Thu, 16 May 2013 03:35:09 -0700 (PDT) ___matthieu___ wrote:
>
> > There is a GUI application (subclass of wxApp) that creates preferences and
> > there is command line tool (subclass of wxAppConsole) that needs to access
> > these preferences.
>
>  This is a not very typical case. I'm afraid wxStandardPaths doesn't
> provide any convenient way to handle it.
>
>
>
> > - If I print the preferences path in the GUI application, I get
> > $HOME/Library/Preferences/appname Preferences
> > - If I print the preferences path in the CLI tool, I get $HOME/appname
> > Preferences
> ...
> > Is this the normal behavior ?
>
>  Yes. Non-GUI applications use standard Unix conventions while GUI ones
> uses OS X-specific conventions under OS X.

Something bothers me about that :
If it is a non-GUI application, then the path should be
"$HOME/.appname";
here, the path it returns me is "$HOME/appname Preferences".
It seems to be a mix between the new path and the old filename.

Regards,

Matthieu

[Vadim Zeitlin]

On Fri, 17 May 2013 00:42:50 -0700 (PDT) ___matthieu___ wrote:

> >  Yes. Non-GUI applications use standard Unix conventions while GUI ones
> > uses OS X-specific conventions under OS X.
>
> Something bothers me about that :
> If it is a non-GUI application, then the path should be
> "$HOME/.appname";
> here, the path it returns me is "$HOME/appname Preferences".
> It seems to be a mix between the new path and the old filename.

Ugh, indeed, " Preferences" is added unconditionally under Mac, even in
wxBase code. This should indeed be fixed. The trouble is that we don't have
any way to virtualize this currently (i.e. make it work differently in
wxBase and wxCore), we probably need to extend wxStandardPaths and add some
GetConfigFileExtension() or BuildConfigFileFromBaseName() method to it.

And, of course, ideally we should be using preferences files in the GUI
apps and not wxFileConfig at all...

[___matthieu___]

On 17 mai, 13:48, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Fri, 17 May 2013 00:42:50 -0700 (PDT) ___matthieu___ wrote:
>
> > >  Yes. Non-GUI applications use standard Unix conventions while GUI ones
> > > uses OS X-specific conventions under OS X.
>
> >   Something bothers me about that :
> >   If it is a non-GUI application, then the path should be
> > "$HOME/.appname";
> >   here, the path it returns me is "$HOME/appname Preferences".
> >   It seems to be a mix between the new path and the old filename.
>
>  Ugh, indeed, " Preferences" is added unconditionally under Mac, even in
> wxBase code. This should indeed be fixed. The trouble is that we don't have
> any way to virtualize this currently (i.e. make it work differently in
> wxBase and wxCore), we probably need to extend wxStandardPaths and add some
> GetConfigFileExtension() or BuildConfigFileFromBaseName() method to it.
>
>  And, of course, ideally we should be using preferences files in the GUI
> apps and not wxFileConfig at all...

Should I open a ticket for this issue ?

Regards,

Matthieu

[Vadim Zeitlin]

Yes, we really should fix this soon to prevent breaking people programs
by not finding their configuration files any more later, so please do. Any
patches actually implementing this change would be very welcome too, as
usual.