Re: [AD] SF.net SVN: alleg:[13892] allegro/branches/4.9/src/macosx/system.m

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On November 12, 2010, Elias Pschernig wrote:
> On Fri, 2010-11-12 at 18:59 -0500, Evert Glebbeek wrote:
> > On 12 Nov 2010, at 11:31 , eglebbk@xxxxxxxxxx wrote:
> > > Revision: 13892
> > > 
> > >          http://alleg.svn.sourceforge.net/alleg/?rev=13892&view=rev
> > > 
> > > Author:   eglebbk
> > > Date:     2010-11-12 16:31:08 +0000 (Fri, 12 Nov 2010)
> > > 
> > > Log Message:
> > > -----------
> > > Correctly return standard paths as directories on OS X.
> > 
> > Actually, I may have been a bit rash with this patch. Not all of those
> > should be directories, so I'll go and fix that later tonight (within
> > the next few hours).
> > However, that does raise another "how does this work on other
> > platforms" question.
> > On OS X, for instance, ALLEGRO_SYSTEM_SETTINGS_PATH returns
> > "/Library/Application Support/appname", which would normally be a
> > directory in which the application is expected to keep whatever
> > configuration and optional stuff that doesn't go in the budle but is
> > to be shared with all users. This is what prompted me to make the
> > change (al_create_path -> al_create_path_for_directory) in the first
> > place (this was always what it was intended to be).
> 
> In unix this is used. So the end result is a directory, something like
> "/etc/org_name/app_name/". It might be clearer to use
> al_create_path_for_directory for the "/etc/" entry and not rely on the
> trailing slash.
> 
>          sys_path = al_create_path("/etc/");
>          al_append_path_component(sys_path, al_get_org_name());
>          al_append_path_component(sys_path, al_get_app_name());
> 
> > However, in the UNIX part al_create_path is also used, and a quick
> > look at the code there suggests that the intended behaviour there is
> > to return the path to a configuration file rather than a directory.
> 
> No, I doubt that. ALLEGRO_SYSTEM_SETTINGS_PATH is a read-only location
> though as the above shows - we need to mention that in the docs.
> 
> > So, first question: is this correct? If not, then the UNIX port will
> > need to be fixed in the same way as the OS X port.
> > Second question: what is the "correct" (expected) return value on
> > other platforms?
> > Third question: assuming that there's a difference in terms of whether
> > a particular system path points to a file or a directory depending on
> > the platform (which I suspect), what's the best way to handle this?
> 
> I'm for always using directories (except the .exe).
> 
> > Or, if we go by the current documentation, then all of the
> > ALLEGRO_*_PATH ids should correspond to a directory rather than a file
> > (with the exception of ALLEGRO_EXENAME_PATH) in which case the UNIX
> > and Windows ports should be checked for using
> > al_create_path_for_directory() rather than al_create_path().
> 
> Running ex_get_path displays this here:
> 
> PROGRAM_PATH: /home/elias/prog/allegro/git/build/examples/
> TEMP_PATH: /tmp/
> SYSTEM_DATA_PATH: /usr/share/liballeg.org/ex_get_path/
> SYSTEM_SETTINGS_PATH: /etc/liballeg.org/ex_get_path/
> USER_DATA_PATH: /home/elias/.config/liballeg.org/ex_get_path/
> USER_SETTINGS_PATH: /home/elias/.config/liballeg.org/ex_get_path/
> USER_HOME_PATH: /home/elias/
> EXENAME_PATH: /home/elias/prog/allegro/git/build/examples/ex_get_path
> 
> The documentation could be improved a lot in any case, besides
> mentioning that SYSTEM_DATA_PATH, SYSTEM_SETTINGS_PATH and PROGRAM_PATH
> should be considered read-only (the last one being read-only in Windows
> caused me a lot of trouble once) we might also show an example paths for
> all supported platforms for each.

Hmm, USER_DATA should probably be changed to ~/.local/orgname/appname/

I thought I had done that, maybe I'm confused.

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/