Re: [AD] Re: file_select_ex patch

[Chris <chris.kcat@xxxxxxxxxx>]

On Friday 16 September 2005 08:17 am, Michal Molhanec wrote:
> anyway, I'm strictly against the original patch for DOS/Windows
> platforms as readonly flag for directories on them is meaningless so no
> behaviour should be based on it

Just because DOS/Windows as an OS doesn't implement proper read-only directory 
behavior doesn't mean a program shouldn't respect the flag. If DOS/Windows 
didn't intend for directories to be read-only, they wouldn't have allowed the 
flag for it to be set for them.

This same argument could apply to hidden directories, too. You can make it so 
hidden directories are always visible (making the flag useless), and there 
could be non-hidden files and directories within that hidden directory.. so 
why shouldn't it be shown even with -h? Because the directory is marked +h, 
and the hidden attribute was specificly unset, meaning you don't want to see 
hidden files and directories.. so why shouldn't the same apply to read-only 
directories?

And as I also said on IRC, who is going to use -r anyway? GTK/Qt/Windows apps 
don't even hide read-only files for 'save as...' dialogs. They let you pick 
them, and if the operation can't be done it throws an error. And if even 
still, the directory is still accessible.. just type it in manually on the 
path and hit enter (just like hidden directories). Just if you do, be 
prepared for a whole lot of nothing because more than likely there's nothing 
in there that isn't read-only.

> the /home directory usually is read-only, but of course
> the file selector should show it

But there's only one directory in /home that'll be writeable to you. Your own, 
which you can get to via $HOME. And also as I said before, I was planning on 
using the drive area that DOS/Windows has in the file selector for a common 
directories section.. eg $HOME, $HOME/Desktop, /, etc.. so you can easilly 
get to it if you happen to not be there already.