Gregory Maxwell wrote:
I really dislike the current GTK+ file selector, even ignoring its poor performance on big directories. But I disliked all other renditions to some degree or another as well. I've always chalked it up to taste and thus never complained. Why not make the file selector another app entirely? This would make it easier for there to be alternatives, plus it might fit in nicely with SElinux. (i.e. the app could be prevented from having FS access outside it's own files, but still have the ability to open user files since the file selector could be trusted to only open files the user actually selected, or only write to names the user selected).
I think the current selector is horrible. The two things that bother me (and that seem to bother a lot of other people) are slow read times for large directories, and that it doesn't provide a quick and easy way to type in a path and filename. Being able to type the path in is such a simple provision, I don't see why it isn't in the dialog. I could live with the poor speeds if I could simply type in an absolute name and not have to worry about browsing or pulling up another dialog. I like the bookmark capability, but it could be expanded and improved upon. I personally think that the KDE dialog has it about right. As for making it a separate program, I don't think that is really practical. It would (should) not help any with SELinux. The dialog returns only a filename, it is not its place to actually load or save a file. That is something that only the calling application should do. Trying to change that fundamental idea would be foolish and very problematic. Being able to change dialogs would be nice, but I think that it would be best implemented as 'profiles' or 'interfaces' for one piece of dialog software, not by splitting the function to multiple programs. -- Patrick "The N-Man" Barnes nman64@xxxxxxxxx www.n-man.com --
Attachment:
signature.asc
Description: OpenPGP digital signature