Re: [AD] al_create_native_file_dialog

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Thu, 2011-01-20 at 21:37 -0600, Matthew Leverton wrote:
> Is there a reason why al_create_native_file_dialog() takes an
> ALLEGRO_PATH instead of a const char*? I didn't go through the entire
> API, but that's the only place I can think of that works that way.
> 
> I think generally speaking, every API call*** should take a const
> char* as a source parameter, simply because it's annoying to have to
> create and destroy a path when you're working with c-strings. I don't
> mind if a function returns an ALLEGRO_PATH.
> 
> [*** The obvious exception being the ALLEGRO_PATH routines themselves.]
> 

Makes sense to me to change it. I think when
al_create_native_file_dialog was written the filesystem/path APIs
weren't quite finalized and one of the ideas was to use ALLEGRO_PATH
everywhere. But it turned out to be done differently.

> On a related note, is the second parameter to al_path_cstr() ever
> _really_ useful? It would be less of a mouthful to use if it was only
> one parameter. There could always be a second function
> al_path_delim_cstr() if it was useful.
> 
> i.e.,  al_path_cstr(path) could be implemented as
> al_path_delim_cstr(path, ALLEGRO_NATIVE_PATH_SEP);
> 
> Not that I really care much... just a minor annoyance.
> 

I completely agree - I find it quite annoying having to specify a path
separator. Also, I think al_path_delim_cstr should take a char*
parameter not a char. Even if it can only be "/" and "\" using a char
parameter for a string just feels wrong.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>