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

[Michał Cichoń <michcic@xxxxxxxxxx>]

Is the ALLEGRO_PATH a path to the file or directory? I think both.

More proper names for _PATH variables are:
ALLEGRO_TEMP_DIR_PATH
ALLEGRO_DATA_DIR_PATH
ALLEGRO_SYSTEM_SETTINGS_DIR_PATH
ALLEGRO_USER_DATA_DIR_PATH
ALLEGRO_USER_SETTINGS_DIR_PATH
ALLEGRO_USER_HOME_DIR_PATH
ALLEGRO_EXENAME_PATH

Suffixing with _DIR_PATH should solve all doubts.

Also ALLEGRO_APPLICATION_PATH is suits better than ALLEGRO_EXENAME_PATH IMHO.


On 13 November 2010 01:58, Thomas Fjellstrom
<tfjellstrom@xxxxxxxxxx> wrote:
> 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
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>



-- 
thedmd, Michał Cichoń
Artifex Mundi
michcic@xxxxxxxxxx
http://www.artifexmundi.com