Re: [AD] al_create_native_file_dialog

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 20, 2011, Elias Pschernig wrote:
> 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.

Uh, its not a string. Its a delimiter. Unless you want to be able to join 
paths using multiple chars? But that doesn't really make any sense.

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx