I sat down yesterday and figured out how to implement recursive permission changes in Nautilus. The result of my work can be found in the Bugzilla, it wasn’t much work after all. The whole NautilusDirectory machinery was really well thought-out, kudos to its designers.
It’s not yet entirely decided how to do error handling, in theory we could use a cancel/retry dialog, but I think it isn’t too common to have a folder you own with many files you don’t own, and without a file operation sudo framework you’re always forced to do a sudo chmod to continue.
I’m really looking forward to usability-related comments.
Oh, and I know that the dialog doesn’t conform to the HIG, I’ll cook a patch for that issue soon.
Update
Be sure to also check out the comments , many people made very helpful suggestions. I disagree with some of the comments that an explicit “Apply” button buys us much.
It rather turns out that the whole current “Permissions” tab approach is rather unintuitive due to UNIX permission obfuscation. I’ve also found a Thunar file manager wiki page containing an insigthful comparison of different UNIX permissions GUI approaches, and I think the KDE/Apple approach is really better than the others. Maybe we should adopt it and explicitly ask the user whether he wants to apply the changes to the directory contents when changing some permissions. We should probably not mess with the “x” part of permissions at all when changing directory permissions. If people did -x, they did it for a distinct reason, and an admin’s approach to file management can obviously never be mapped to a GUI.
What a coincidence, prefisely two days ago I was reviewing Nautilus for the Guadalinex user guide I’m writing and I was lacking the recursive option. Great!
In regard of usability, I would put it at the bottom of the Read/Write/Execute cell, down of the Others row without separation line in between. Then separation line and Special flags etc without any change.
I think it’s clearer this way.
Forgot to say: Nautilus is one of my best desktop friends. Perhaps because I’m an unpretencious average user resisting to open a terminal as much as possible. 🙂
asdf:
> if it was that well thought-out, then why is nautilus sill a pile of useless shit ?
We’re really working hard to improve the Nautilus user experience. However, we just need more developers to satisfy your needs and to gain more momentum. Feel free to point out what you still need to achieve your daily work, and feel encouraged to join discussions on the mailing list and file bugs against Nautilus.
This is one of those cases where the policy of ‘no OK buttons’ is very short sighted.
When do the recursive changes get implemented? When the checkbox is clicked? What happens then if you tick then untick that box? Something being a checkbox doesn’t imply to the user that something irreversable will be executed on a click.
Do the changes get implemented when the user hits the ‘close’ button? If so, then it’s not really just a close button, is it? Clicking it causes actions to be executed by gnome.
You see, just from looking at it, as a potential user, it’s giving me no clues about how it actually behaves.
I agree with the last poster (Robert).
What I think is needed in this case is the return of the good old Apply-button. It should probably be accompanied by a note saying that changes only apply after you press the Apply button.
Nice to have this option. Maybe the word recursively could be changed to something easier to understand. KDE uses the label “Apply changes to all subfolders and their contents” (they don’t have an option to select folders/files/both)
What about making only two checkbox options like
Apply changes to:
[ ] All subfolders
[ ] All files in this folder and its subfolders
Aside from the fact the pref is in a weird moon-language, Windows XP does this with a far more sensible dialogue box on closing the pref panel which eliminates concerns with exactly when the recursive changes take place. I’d opt for that, if only because adding any more widgets to that panel would be horrible.
– Chris
Great work on Nautilus. It’s a pleasure to use and getting better with every release.
Since you asked for UI feedback: in my opinion, the permissions tab has always been a bit too complicated for a non-technie user.
The obvious offenders are the “Special flags” section and the “Text view” and “Number view” items. If you’re unsure about this, just imagine your mom trying to decide whether a file should be “Sticky”. And when is the right time for your mom to choose “Set User ID”?
But also, the big grid of Read/Write/Execute permissions means very little to normal people. “Do I want to execute my spreadsheet?” Why would someone want to make their own file not readable to themselves? Or writable but not readable? Maybe on servers, but on the desktop..?
First, we could think about translating from techie speak to human:
-Read means View
-Write means Change/Modify (and Delete, technically, but that’s just a type of modification, no worse than filling a word doc with gibberish)
-Execute means “run as a program”
I made a mockup of a new simplified GUI that I think covers all *normal* use-cases:
http://linuxadvocate.org/images/unlinked/nautilus_permissions_tab_mockup.png
I made this many months ago, so it doesn’t take into account recursion, but I think the design would accomodate it.
If some users demand a UNIX-like permissions dialog, perhaps we need two views: “simple” and “advanced”. With “simple” being the default, of course.
I have to agree with all Ian said above. I’ve got exactly the same feelings regarding the permissions tab; i’ve always found it too complicated.
I think the KDE folks have got this right this time, Gnome should try and get some ideas from there.
Thanks for all your feedback!
The real permissions with UNIX permissions is that they are very unintuitive, if not obscure, because “Execute” has a different meaning for folders than it has for files.
For files, the meaning matches of read/write/execute matches your intuition, but for folders, read means “contents may be listed” and execute means “may appear as a UNIX path element”. For instance, files and folders inside a folder which is not readable but executable may be accessed, but only if you know the precise name. This semantic obfuscation really makes it hard to build a GUI.
Ian:
I think your approach is really interesting. I still have no clue whether it is possible to satisfy our power user’s needs with this. I don’t want to lose that idea, maybe you could attach it the referenced bug report?
Jure:
> Maybe the word recursively could be changed to something easier to understand.
Yes, I agree with that. I’m not a native English speaker, and it is obvious that these strings should be revised. I wasn’t totally sure on the GUI part yet (see below), so I just didn’t care.
Chris, Sergej, Robert: The Bugzilla entry also contains some discussion on whether the permission changes should be instant-apply or not. Maybe you can add your comments there?
> just from looking at it, as a potential user, it’s giving me no clues about how it actually behaves”
I very much agree with that. As I stated above, the whole UNIX file/folder permissions must really be grasped before they can be used for advanced justifications. Using an apply button is not really a solution to the fundamental problem of obscureness. The current GUI isn’t very intuitive either. A confirmation dialog just won’t help users who don’t know what they are doing.
I really think Ian got the right approach, we have to replace those funky obscure buttons by something more intuitive, and maybe provide an advanced mode for the chmod-aware people out there.
Nice stuff! I would make just one observation, however: under Unix, +x is very much needed on directories. However, it is undesirable to make _everything_ recursively +x. I find myself doing chmod -R a+rX on things; the capital X only affects directories. It’s a common use case, and might deserve something a little easier than two applications of the permissions box.
genneth:
> I find myself doing chmod -R a+rX on things; the capital X only affects directories.
Why do you have to set +X? Isn’t that set by default? Is it very common to have an umask > 0022?
My vote goes for taking this off the tab itself and replacing it with a human readable description on the basic tab with a “Change” button so we can have a proper apply/cancel dialog.
Also instead of a checkbox at the bottom I think a select box with:
Applies to: {“this directory”, “this directory and its contents”, “all folders in this directory”}
Bonus points?: ctl+l allows you to just type in 7-5-5-return and press enter and see all the correct boxes checked?
–Rob
I think some friendly buttons(or something) with labels like “set private access” and “allow public access” would be good in aiding the unaware people (wrt the mockup), but making the grid vanish is not a good idea in my opinion.
As stated, the unix permissions are way beyond the ability of explaining it in one dialog in their complexity. More often than not, they are also very uninteresting to the common user.
The only cases I could imagine anyone “normal” touching the settings are the two above and the CDROM read-only syndrome which in fact is more a setup problem than a use-case.
The mockup posted, even though very friendly-looking, will in fact only change the focus of the confusion. Previously it was the novice users, now it is the one’s that know the permission system and go there to set it to some value. The mockup offers no clear indication of what exactly will happen to the permissions. What’s the relation with the “All users can” and “Users in this group can”? Are they g+ and + thus overlapping? Will setting “all users” affect the group too? If so, why is it separate setting (making it disconnected) instead of grouped with the others (which takes us back to the old grid with less options and more space wasted).
Templates (the buttons I referred to in the beginning) would help the novices, keeping the grid would help the knowledgeable. Mixing will confuse both most likely.
X does not apply only to directories, here’s what the chmod man page says:
“execute only if the file is a directory or already has execute permission for some user (X)”
X is probably the best way to set the execute bit correctly, if the nautilus GUI does not provide an equivalent, it will just mangle the execute permissions…
m:
> X is probably the best way to set the execute bit correctly
Yeah, my point is that – unless the user specified something special – +X is already used for directories. Thus, not touching it in basic mode seemed to be the most reasonable thing to do.
Christian: this about this problem: I have a directory that has
the permissions for go —— and I want to recursively give
access to the files there to g and o. I don’t want .c files to get the x bit
set, but I want the binaries/scripts to get the x bit set (and obviously the subdirs need x).
With chmod you can do this by: chmod -R go+rX DIRECTORY
How about replacing the entire thing with something that works with ACL’s, most distros are shipping now days with ACL aware filesystems.
m:
> So enabling read or read/write permissions for a particular directory should also set +X on it, also when applied recursively, right?
Here’s a usability comment:
“Apply changes recursively” only means something to you if you’re experienced with the command line. Most users aren’t going to understand what that means. I’d change it to “Apply changes to subitems.” Unless someone can come up with something even more clear 🙂
Check out some good, modern Christian music, songs with punch that reflect Christ’s power: http://www.mixposure.com/song.php?songid=14027.
Comment added. A button with a label which doesn’t use the dreaded “recursion” is significantly less dangerous and a bit more obvious than a tickbox with a two-word explanation for an action which is usually irreversible.
– Chris
Check out some good, modern Christian music, songs with punch that reflect Christ’s power: http://www.mixposure.com/song.php?songid=14027.
It definitly needs some kind of approval button, like apply or ok. Also i agree with the ACL comment. It should support ACL. Maybe you could put it in an Advanced tab.
“This semantic obfuscation really makes it hard to build a GUI.”
Can’t the permissions dialog behave differently for files and folders? The structure may be the same, but the meaning isn’t, so why display the exact same dialog?
As for the KDE/Apple approach, make sure not to drop the sticky/suid/sgid options. If I can’t set the basic options for a file, then the dialog is useless.
Christian: Well, it depends on how you want the GUI to work.
If you want to be able to do something like: “add read permissions
to this directory for group” then you’d need to add +X.
But as far as I can tell the GUI is designed now to offer the equivalent
of the “=” operator for chmod. Can an equivalent of “-” be
provided too?
m:
> Can an equivalent of “-” be provided too?
Here we go:
http://blogs.gnome.org/view/cneumair/2005/12/28/0
For recursive application of settings, do the check boxes use a tri-state logic (set bit, do not set bit, leave untouched = check box grayed out)? It is not very cler from the pics.
Without that, it is completely worthless to a pro-user…