Month: December 2005

You may have read my recent blog entry dealing with a patch adding recursive permission caps to Nautilus. I got some very helpful comments which pointed out why the last approach failed.
The combo box that was added to the permissions grid was too confusing for newbies. It doesn’t mean anything to them. For nerds however, it doesn’t provide enough caps because they want to edit the permissions of files and folders at the same time (cf. chmod -R +rX). So obviously – although usability experts usually don’t like the idea – a basic/advanced mode separation was needed. This was also necessary because for common computer users only binaries can be executed, and they don’t easily grasp that the x flag for a directory means listability, while not providing this implementation detail to experienced users will confuse those.

So how would the new approach look like? This might be very disappointing for those of you expecting a creative approach, but I simply replicated the GUI concept from MacOS that was also adopted by KDE. For reducing the complexity of the involved GUI descriptions, one cannot select files and folders at the same time and edit their permissions. It will simply cause too much headache, because “Read” means rx for directories and r for files, which is the reason why in basic mode, there is no “Execute” terminology used for directory permissions. Furthermore, un advanced mode it would cause many strings like “Apply foo to the selected files and the files in the selected folders and their subfolders”, requiring the user to scan the help text again and again to get what he is actually doing.

Note that the screenshots shown in this entry are not HIG-compliant, because the dialog helpers weren’t modified to respect it. I’ve filed a bug report against this issue which has some screenshots and is waiting for your usability-related comments.

Use case 1: Joe Doe downloads a binary and wants to make it executable.

He brings up the “Access Rights” tabs and sees the following:

He then clicks the first “Access” combo box, and selects “Read, Execute” or “Read, Write, Execute” from the list.

Note that if a particular permission combination (like wx) is not available, the combo box has no preselected entry, and allows you to set the permissions to any of the “sane” permission combinations in the combo. When modifying folder permissions in basic mode, you’re asked for confirmation (and are offered cancellation, recursive application and toplevel application). For the sake of sanity, +X is always added to “Read”/”Write” folder permissions, but it is taken care to not mess up with the +x flag of the files in the folder while still setting them [+-][rw] as desired.

Use case 2: Foo (too lazy to open a shell and use chmod) wants to apply g+rX to a directory hierarchy.

He brings up the “Access Rights” tabs and sees basically the same as Joe Doe:

“What the hell”, he thinks. This dialog doesn’t offer anything! Goddamnit, the GNOME morons even removed the last useful feature from GNOME.
He is pissed off by the fact that the combo box just offers the crap it offered to Joe Doe – but wait, it even offers *less*. Just three shitty items, and where is my +X?

OK, so he toggles the “Details” button expecting that he’ll soon use apt-get to remove that crappy GNOME shit from his and all his clients’ computers.

Hah, now THAT’S what I call a chmod GUI. While he is a bit disappointed that they didn’t yet figure out how to properly do keynav (more buttons than possible accels) and that he has to press “Execute” and “Read” twice in the folder section and additionally “Read” once in the file section, he does it.

Next, he presses OK – and voila – g+rX is done.

Note that the file details dialog looks like the folder section of the folder dialog of the folder details dialog, and error handling is still not yet done. The patch also lacks some cleanup, but it’s too late for that.

I know, nowadays people demand ACLs, sudo caps when there are unresolvable permission problems and such, but I really think we’re making some decent progress.

Comments are again welcome, and don’t forget to grab the patch and play with it.

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.

thos: IIRC, a compositing manager together with the XComposite extension is in fact required for having a semi-transparent (thus arbitrarily-shaped) window.

There is another X extension available allowing arbitrarily shaped windows without any semi-transparency (each pixel is either displayed or omitted). It uses a bitmap, i.e. you explicitly set which pixels to display and which to “carve out”. It probably takes care of that by sending expose events to the underlying windows, and overlaying the results afterwards. This would still mean on-screen drawing, though, compared to off-screen XComposite drawing.

On a sidenote: I think the problem with XComposite is that even if the library is loaded, there is no guarantee that the underlying graphics hardware supports it, and that the user gets semi-transparent output.

For instance, some people demanded semi-transparent drag icons for Nautilus, but it turned out that finding out whether compositing is actually done is nontrivial. I made a proposal on the xdg freedesktop.org mailing list for finding out whether a compositing manager is actually running, but nobody has proposed a freedesktop spec yet.

We didn’t have any shared-mime-info release for some time, with the last one dating back to March 2005. Much work has been accomplished recently, though. Debian patches were pushed upstream, and – which is really nice – we finally found a solution for the long-standing issue of multiple MIME types per extension, causing media container b0rkage. This rectifies a new release within the next few weeks.

Let me go a bit into detail on the “multiple MIME types per extension” issue:
Some of you might already have noticed that when Nautilus determines the contents of a file to be different from the extension, and you select it, it is suddently changing its icon, getting resorted when you sort by MIME type etc. This inter alia used to be a widespread phenomenom for windows media files, and constantly happened for all of them.

In terms of MIME handling, media “containers” are quiet evil.

You often have multiple media streams encapsulated into one file/stream (this is called “multiplexing”). The enclosing stream/file is called container. When naively looking at the container’s file extension, it is not possible to tell what the contents is. Since nowadays there are many media container formats available, like Ogg or ASF, it is cruicial to deal properly with those encapsulated streams, and give the user the possibility to associate audio players with encapsulated audio, and video players with encapsulated video.

To make the situation worse, mistakes were made when determining MIME types for containers. For instance, all Ogg files are meant to have the MIME type “application/ogg”, according to the IANA. This is a very bad idea, for the bad user experience pointed out in the last paragraph.

Summing up the above, the MIME container analysis revealed two major attach points:

a) never ever determine the MIME type of a container without peeking its contents
b) we need more MIME types

a) was resolved to 98% by Matthias Clasen who improved the xdgmime API to include support for this. Because the container concept can’t simply be mapped to mime type definitions, he took a different approach: He hacked support for N:M relations between filename glob patterns (“*.ogg”) and MIME types into xdgmime, adding API for querying whether multiple MIME types for a particular glob pattern exist. Thus, xdgmime can now can query whether multiple MIME types exist for a particular passed-in file name, and find out whether peeking its contents is always required, telling its client that the actual MIME type is unknown. The last 2% were slight adaptions of helpers exported in the API to actually make GnomeVFS semantics work correctly with it, which was my contribution.

Note that these changes can also be extremely important useful for other use-cases, like the file extension “*.pot” being assigned to translation templates and powerpoint presentations.

b) for Ogg, the task was quiet straightforward:
“application/ogg” is used for “*.ogg” and its magic matchlet (the sniffing information) matches against all Ogg files.
The trick is now to define new MIME types for the encapsulated streams, all of which also match “*.ogg”, the Ogg magic matchlet mentioned above, and an additional stream type-specific magic matchlet:
“audio/x-vorbis” maps to “Ogg Vorbis audio”
“audio/x-oggflac” maps to “Ogg FLAC audio”
“audio/x-speex” maps to “Ogg Speex audio”
“video/x-theora” maps to “Ogg Theora video”

additionally, we have a “OGM video” MIME type matching “*.ogm”, which contents-wise matches a modified version of the Ogg magic matchlet. It is a bit legacy, considering that this was mainly added because the crappy Windows MIME system doesn’t allow any contents sniffing, and is used to identify Ogg videos.

All of the mentioned stream types are registered as sub-types of “application/ogg”, so that old MIME associations are not broken and apps operating on the container itself still work as expected.

a) and b) were resolved today for Ogg, b) hasn’t been resolved for ASF yet, but I’m quiet optimistic that it will make it into the next shared-mime-info release as well.

This is really a major progress in xdgmime/shared-mime-info, and should convince the KDE guys to take a close look at the bundle for KDE 4, although I can’t tell how editor-friendly the shared-mime-info file structure is. I doubt they’ll tell users that MIME associations are the distributors job and they should just file bugs if something goes wrong, like we did. MIME type editing will probably still be possible in KDE 4. If the MIME editor friendlyness of the structure is bad, take it as a revenge for the over-complex arcane XML-based menu system we adopted ;).
Congrats to KDE 3.5, btw.

Update

Peter Bowen points out that a MIME naming following the XML naming spec (“video/x-foo+ogg”) would be more convinient. I agree and changed it accordingly.