Re: [AD] Re: file_select_ex patch

[Chris <chris.kcat@xxxxxxxxxx>]

On Monday 19 September 2005 03:25 am, Elias Pschernig wrote:
> About changing the meaning of the flags, your code really is
> cleaner, but after having looked at / with our patch and -r, I really
> think very confusing for end users.

Which is why -r isn't normally used for file selecting. If you want access to 
read-only files and folders, even if it's just to browse through, you 
wouldn't want to hide them.

And really, you can say the same thing about -d. That would hide all 
directories from view, making it very hard for users to browse. Even though 
you maybe just didn't want them to select directories, they can no longer 
browse easilly. So should -d be modified to show directories still? No. You 
just wouldn't use -d, just like you wouldn't use -r.

> > is clicked, and makes selecting a directory and clicking Ok return TRUE
> > (why would Ok'ing a dir return FALSE, anyway?)
>
> Yes, that makes no sense. Returning the directory also would make no
> sense though..

Not really. You could want to select a directory. And as I gave an example 
before on IRC, if you have a default filename to save, you could allows users 
to select a directory and use that default filename, or select an alternate 
filename and use the alternate.

> I completely agree that the current file selector is flawed, but
> changing the meaning of flags like you proposed, or allowing to return
> directories, won't make it any better.

Well, the directory can be returned anyway. That's always been the case, and 
still is. Just that before it returned FALSE even if you clicked Ok (which is 
against the docs). As for the flags, even you agreed hidden directories 
should be hidden by default. So with that change, and keeping in line with 
the docs, the only way to show hidden directories would be to show only 
directories.

> - Add a mode where you can select directories instead of files

Use +d. Double clicking the directory will still open it (just like every 
other file selector), but you can click Ok to return it.

> - Separate navigation from file selection.

I'm not sure what you mean here. If you're referring to my comment on IRC 
about having the path seperate from the selected file, it is done that way, 
at least partly. It wouldn't take much at all to add another DIALOG field for 
the filename, to split the preselected filename from the user's path (if 
present), and to remerge them after the dialog closes. Beyond that, using the 
click message for the file listing object to alter the filename field and it 
would be the same, behavior-wise.

But that would make browsing for directories a bit more cumbersome, as the 
dialog box would need to be modified when searching for just directories (to 
not show the filename area). Doable, and kinda simply if oyu don't mind two 
dialog arrays, but it'd take a bit of time.

> Ideas how
> it could be done can be found in the Qt, GTK and Wx file selectors, all
> do it in a more logical way than we.. but I don't think it's something
> very important.

I do. There is no univeral API for selecting files, let alone one that's 
gauranteed to work without problems with an Allegro program active 
(especially fullscreen.. *cough*DirectX*cough*), and it's a very useful 
feature to have.