I sat back and did nothing for some time, and things got clearer.
My first approach failed because it didn’t break with our old permissions GUI semantics, my second approach failed because its advanced mode was totally hosed, not being compliant with our UnixPowerForDesktop project. No advanced user would ever be willing to poke around with a few fiddly buttons to get a “+rwX”. Besides, the dropdowns were to cluttered.
I invested some hours to refurbish my second patch, and I hope the result of my work will convince both, the advanced users who know precisely how chmod and the UNIX permissions work, and the beginners who want to make a downloaded script executable, or share a file with somebody else.
The basic mode was shamelessly stolen from Thunar. Those guys really had some very good interface ideas, if you’re interested in file management usability, make sure to check out their home page. We may even steal even more of the ideas, like a simple dropdown for MIME type associations.
On a sidenote: The “inventor” of the dropdown permission box widget arrangement was – as far as I know – Apple, so don’t sue us you brave Thunar developers :).
I just split out the executable toggle button into three separate buttons, because it may not be to uncommon to demand a very special executability triple for a file, like ??x??x??-, for instance for some script.
The advanced mode is chmod. You have a little entry, you enter your desired mode and we use chmod’s parser to convert it into some permission modification blob we just throw at each of the modified files. This transfers the well-known and beloved chmod semantics for any of your GnomeVFS-browsable remote shares.
Use case 1:
Joe downloaded a script and wants to make it executable.
Use case 2:
Jimmy doesn’t want to share a whole directory with the other users, like he did before.
Now, this is a directory, so what about recursion? As he clicks “None”, a dialog pops up asking for confirmation and explaining the options. I’m not sure on the wording, as you may have guessed from the previous text I’m not a native English speaker. Feedback highly appreciated! I also made sure to forgive the user – when clicking the [X] icon, the action is cancelled, without cluttering the button arrangement, thus being a “Yes/No” decision with cancellation point.
Jimmy reads the text carefully, and confirms.
Use case 3:
Some random *NIX admin stumbles across Nautilus and wants to try out its permission GUI. Having read that GNOME is really the crap, he tries it out anyway.
“Holy crap” he thinks when seeing the GUI, it’s not even suitable for chmodding my files. Where did -R go?. He’s frustrated, but clicks the “Details” button. His input focus is immediately taken to the chmod entry. As he enters text, the crappy GUI is desensitized to denote that he now has full control over the permissions.
He enters his chmod command, and presses enter (whether an apply button should be added isn’t decided, but usability in a keynav sense often means reduction to something shell-alike).
Look, this question isn’t as stupid and cryptic as the first one :).
The patch is available in bugzilla, hopefully we’ll get something similar into Nautilus 2.15, maybe we’ll even stuff the views with some accelerators for reaching the chmod entry with two key presses.
Sorry, no ACL GUI yet, but it’s on the TODO list.