| Re: [AD] 5.0.0 final release plan |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On January 3, 2011, Matthew Leverton wrote:
> On Mon, Jan 3, 2011 at 7:19 PM, Thomas Fjellstrom
>
> <tfjellstrom@xxxxxxxxxx> wrote:
> > So what we have now, except you're renaming SYSTEM_DATA to
> > BUNDLED_DATA... I suppose that makes sense.
>
> Well, I'd look at it this way:
>
> 1) Rename PROGRAM_PATH to BUNDLED_DATA, and on OS X, dynamically
> detect if in an app bundle, and adjust accordingly. Update
> documentation to make it clear that this should be considered
> read-only.
>
> If the user *really* wants the real program path, they can get that
> from EXENAME. I see no need for the average Allegro program to access
> the real program path. The dynamic BUNDLED_DATA path is likely the
> only thing anybody will need. Omitting the true program path will
> discourage people from erroneously using it when they really wanted
> BUNDLED_DATA.
>
> 2) Remove SYSTEM_DATA_PATH and SYSTEM_SETTINGS_PATH.
>
> The rationale is basically what torhu said about them not being both
> straightforward on all platforms and useful to the average Allegro
> program. These folders are going to be read-only, which means they
> have to be created at time of installation. And there's no guarantee
> that the chosen installation folders will actually be what Allegro
> assumes those locations *should* be.
>
> So if you're creating an installable package that moves files around
> in different locations, then you already have to take extra steps to
> make sure the installation paths match what Allegro expects. So I
> think it would actually be easier to not rely on what Allegro reports,
> but instead implement something on your own.
>
> 3) Make USER_HOME consistent, and add USER_DOCUMENTS
It all makes sense. And I suppose if you really want access to system settings
on unix you can just look up /etc. Since it doesn't map that well to windows
(system settings in windows is really the registry, and we can't access that
in the same way), it may not be a good idea to have the option.
> --
> Matthew Leverton
>
> ---------------------------------------------------------------------------
> --- Learn how Oracle Real Application Clusters (RAC) One Node allows
> customers to consolidate database storage, standardize their database
> environment, and, should the need arise, upgrade to a full multi-node
> Oracle RAC database without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx