Re: [AD] Re: file_select_ex patch

[Chris <chris.kcat@xxxxxxxxxx>]

On Saturday 17 September 2005 10:08 am, Michal Molhanec wrote:
> I said that I copy some app in some directory from CD (so both app and
> the dir is RO) and run the app and it will create (succesfully under
> Win) files in the RO dir. This is simple scenario how to get RW files in
> RO dirs.

Which only works because Windows doesn't prevent creating files in read-only 
dir's, like common logic suggests it should. As I said, do not assume files 
and folders copied from somewhere else will be inherently writeable to you. 
Do that same thing in Linux/OSX/Unix, and it'll fail miserably.

> But if I specify -r I want to see RO dirs because I've read Allegro
> documentation and I know that it applies only on files.

Technically. However, reading the docs on the function show just how confusing 
the behavior is (and just imagine how the underlying code must be to 
incorperate such an illogical setup). According to the docs, none of the 
h/r/a/s flags are applied to directories, unless you also specify +d or -d.. 
however, this would effectively limit you to only being able to filter 
hidden/system/read-only/archive directories if you *only* show directories. 
AFAIK nobody here has a problem with hiding/showing hidden (or even system) 
directories with just -h/-s or +h/+s by default. I can't see very many 
programs breaking because of this, and it's a change for the better. 
Therefore, the docs are going to need to be changed anyway, so you can't say 
"because the docs say so".

IMO, this (not filtering directories by defualt) was a major oversight and 
should be fixed ASAP, to a) fix it before more programs rely on the 
broken/bad behavior (in fact, I'd assume most programs rely on proper 
behavior, but chaulk it up to "bad design" that it doesn't), and b) to behave 
closer with how other existing file select dialogs work. There's a reason 
they don't hide read-only files when doing a save-as operation. Because that 
would make browsing through a bit harder from it having removed read-only 
directories too (as it should.. you can't/shouldn't create files in a 
read-only dir).

> I still think that my previous suggestion "why don't you extend the
> syntax, e.g. ";/-r/-r" would mean non-readonly files and non-readonly
> directories etc." it's solution which will satisfy everybody

Not really. Because r (just like s, a and h) should apply to files *and* 
folders by default. The code is fairly simplified now that I made 
file_select_ex just do a single call to for_each_file_ex, passing the 
inclusion/exclusion attributes given in the extention string, instead of 
calling for_each_file_ex in one of two different ways depending is -d or +d 
is specified, and having for_each_file_ex's callback do manual attribute 
filtering in one of those ways instead of just letting for_each_file_ex do it 
itself. The code is happier and cleaner this way, follows common logic, and 
follows the behavior of other existing file select dialogs.