AUG
9
2006

Better media and IO-slave integration (+patches)

In this fairly long article I discuss my attempt to simplify file and device management in KDE, while avoiding some of the draw backs of the current media:/ io-slave.

The Challenge

About a year ago I expressed concern about all of the extra io-slaves that have appeared in KDE. The intention of the new slaves was very important (e.g. better file and media management) but the implementation could be better, IMO. The problem as I saw it is that wholesale replacing the unix file system heirachy with a new but incompatible heirachy (e.g. system:/) comes at a price which is too high. The user gets a usable heirachy for dealing with files, but this heirachy doesn't work in non-KDE applications. Give a system:/ URL to apache or gedit for example, and they will give you an error message.

It could be argued that the file heirachy is an implementation detail. But unlike implementation details like tracks and sectors on disk, the file heirachy is also the language that programs *and* users use when talking about the location of data stored on disk. It is not a detail that can be easily concealed.

This "problem" has been hanging around in the back of my brain ever since. In the last week or so the urge became too great and I had to see what really could be done about it. It is easy to guess and talk about what should be done to improve usability in an aspect of KDE, but guess-work is not the same as having a prototype in front of you that you can try out. Time to warm up that compiler.

Put simply, the goal of this investigation is to try to answer the question:

"What can we do today to make file management more usable in KDE while at the same time preserving integration with other non-KDE applications?"

The Results

First what everyone wants to know first, the results, and then late a technical explaination.

This is in a nutshell what I was able to come up with after a few evenings working, configuring and patching my "test" installation. It is our old friend konqueror operating as a file manager showing my hard disk. Things to notice:

  1. Only the /home and /media directories are shown in the file system root. These are the only two directories in the root that a typical user really needs to deal with. The other standard directories are hidden.
  2. The URL in the location bar is the standard unix path and most importantly, the paths here will be understood by any program on the system.
  3. My home directory automatically has a house icon, and the home directories of any other users on the system are hidden.
  4. Hard disks and removable media also have the correct icons just like in the standard media kio-slave. The icons have the same functionality as the icons in media:/. The context menu for these icons show the expected "Safely Remove", "Unmount" etc options.
  5. The name of the sidebar folder is the name of this computer and some of the of the other redundant sidebar folders have been removed.

This setup integrates the functionality of media:/ into konqueror's view of the file system, only shows the directories that the user is interested while still maintaining compatibility with existing software.

Everything that is hidden here can be shown using the "Show Hidden Files" menu item in Konqueror by the way.

What I did (technical)

There are quite a few things going on to get this result.

  1. Added support to the file:/ kio-slave for ".hidden" files. This makes it possible to hide arbitrary files in konqueror even though they don't start with a period (".") character. A ".hidden" is a file literally called .hidden, which contains a list of file and directory names which should not be shown in the GUI. This is the technique that Mac OS X uses to hide the unix directories in the root. Incidentally, the GNOME file manager Nautilus has supported this for quite some time too. oh, I of course put a .hidden file in my root directory. ;)
  2. Integrated most of the functionality of the media io-slave into the standard file io-slave. What this means is that the file io-slave now passes on the extra meta-data about mounted devices on to Konqueror (or the Open file dialog for example). Using this meta-data Konqueror then knows when to show an icon of the hard disk instead of a blue folder. The context menus also depend on this meta-data in order to offer the right menu items like "Safely Remove" or "Unmount".
  3. Added extra functionality to Konqueror to hide other people's home directories under /home, and to show a picture of a house for my home directory ($HOME).
  4. Fixed KDE bug 101636, now konqueror shows the correct icon in the sidebar all of the time. A small cosmetic fix. It bugged me, ok.
  5. Configuration changes in Konqueror. I removed the bookmarks sidebar and Home folder (Konqueror already has a Bookmarks menu), and changed the icon for the Root Folder to something more pleasant, like a computer. I also changed the label to match the computer's. (In this case "dappertest").

Conclusion

I'm rather happy with the result and I'll probably set this up on my "real" machine. It makes it possible to vastly simpilify file management in Konqueror. Using only one hierarchy you can easily get to your home directory, other hard drives, removable media and the standand unix filesystem itself if you want to.

Complexity and an overabundance of things and buttons and options is a common criticism of KDE. And I feel that this can help combat the problem.

TODO

  • The media notifier popup still opens things under system:/ instead of using the real mount point.
  • It would be nice if I have the history sidebar only show up in Konqueror's web browser profile.

Here are the patches that I'm using:

kdelibs (3.5.4) - http://www.simonzone.com/software/kdelibs_file_cc.diff
kdelibs (3.5.4) - http://www.simonzone.com/software/kdelibs_file_h.diff
kdebase (3.5.4) - http://www.simonzone.com/software/kdebase_mounthelper.diff

Comments

Great! How about a Kubuntu deb? ;-)

If you're simply pointing users at /media rather than the media:/ kio-slave and getting the same nice functionality, why does the kio-slave not do the same all along? Your solution makes so much more sense that I wonder why the media:/ and system:/ and home:/ slaves were ever implemented that way (which all bug me and confuse my family and friends who use Kubuntu)?


By Tom Chance at Wed, 08/09/2006 - 20:17

As for making ioslaves more portable for non kde apps, there is the kio fuse gateway.


By oneeyedelf1 at Wed, 08/09/2006 - 20:34

I really like what you did. This would be a great option for KDE.

A few suggestions:
- will there be an option to show the other user folders again?
- will there be an option to create a "shared documents" folder so users at the same computer can exchange files that way?
- will there be an option to show the entire file system, or a different tab for that?

Ever since I've used MacOS X I've come to understand you don't need those /etc /dev and /usr files in the file manager. If, and only if, you really use those, you're likely using them from the Terminal.

An interesting observation of Mac OS X: because they've hidden the files, application developers will avoid those folders too. Applications become more user friendly this way.

For special resources Mac OS X does have a ~/Library and /Library folder. When you're looking for wallpapers, they're in something like a /Library/wallpapers folder, not some deep hidden /opt/kde/share/wallpapers directory. This is something I that needs to be addressed with this new layout. ;-)


By vdboor at Wed, 08/09/2006 - 21:25

I can understand hiding system folders and files from "normal" (==dumb??) users, but hiding other users homedirectories is in my opinion wrong and adds this need to create a "shared documents" folder.

Otherwise these patches are very wellcome!

By the way the shared folder thing should not be coded into the GUI because it can be very easily created in the Unix filesystem as a link to a folder where everybody has read and write rights.


By sars at Thu, 08/10/2006 - 06:07

I think the final solution(tm) would be displaying only the other users' home that the current user has right to access, so the ones that clicking on them would only make an error window appear will be hidden, the others will be shown.


By mart at Thu, 08/10/2006 - 08:37

Excellent work! Like so many others here, I'm uncomfortable with the system:/, media:/, and home:/ IO slaves. I would have to agree with sars, that hiding everyone else's home folders is a bad idea. I think of it this way: You only want to hide from the users what they neither know or care about. If Joe User has a machine with accounts for himself and his wife (Mary User) he knows that the computer has storage media, his files, and her files.

If he cares about her files they should be easy for him to find, right there below his own home directory. Even if he doesn't care about his Mary's files, he still knows they exist and there's nothing to be gained from hiding them. Unlike the /opt, /usr, /var, /etc directories, /home/mary is pretty easy to understand, so there's little chance of confusing Joe. It's meaning is obvious provided one knows what "home" means and that's a pretty easy topic to grasp.

For the same reasons, I have to disagree with mart. If you were looking for someone elses files which of the following would be more confusing? Not being able to find the directory anywhere in the "entire" file hiarchy, or plainly seeing the folder and being told the that you don't have permission when you try to open it.

I think this work has some real promise. This kind of work is extremely tricky because so many of these things are dependent issues outside of KDE's control. But your solution is extremely flexible and could easily be made compatible with both different distributions and even different desktop environments. Maybe you should look into writing up a spec for freedesktop.org.


By Parker Coates at Sat, 08/12/2006 - 03:03

I love this idea. It seems so much cleaner and easier to deal with than the current mess that is media:/. This way, distros themselves can choose which files and directories they want to show, so KDE is imposing fewer policy decisions.

Also, I expect my local filesystem to work reasonably consistently, and media:/ fails at that. /mnt/cdrom should always be /mnt/cdrom, and symlinks ... well, see bug 117704. With media:/, they're just plain broken.

If I could find a way to get KDE 3.5 to stop using media:/ completely (that doesn't require messing with Gentoo ebuilds and the like), I would do it. But I can live with it for now if KDE 4 will be better.


By des at Wed, 08/09/2006 - 21:56

A little implementation detail

I think that enabling hiding of .foo files and hidden system directories should be separate, as I might want to see the system files without cluttering my home directory with config files.


By squarrier at Wed, 08/09/2006 - 22:43

I wholeheartedly agree.


By hads at Thu, 08/10/2006 - 22:09

The media:/ and system:/ slaves have never quite cut it for me. I use non-kde apps too often, and kmplayer seems to choke on them for some reason in any case.

Would the /media directory recognize network shares if I were to mount them in there? For example would a smbfs share set up in fstab and mounted to /media allow me to mount and unmmount the share with a right click, or automount with a double-click?

I guess the biggest drawback I can think of is the lack of friendly volume names (e.g. "hda2" instead of "65G Hard Disk" or whatever).

Cheers,

L.


By ltmon at Wed, 08/09/2006 - 23:11

Pages