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:
- 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.
- 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.
- My home directory automatically has a house icon, and the home directories of any other users on the system are hidden.
- 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.
- 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.
- 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.
- 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".
- 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).
- 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.
- 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
Syndicate Blogs
One problem
I just thought of a possible problem with this implementation. Mountpoints are still shown, even when the media isn't present. Imagine the following not-so-hypothetical situation...
I have an external harddrive that I mount at /media/external. I'm doing some work and think that I'd better save it to said harddrive. I forget that the drive isn't plugged in and save it to /media/external. No error is generated so I think all went well. The next day I want to continue work on that file, so I plug in and mount my drive. This of course hides the "local" contents of /media/external. Consequently I can't find my file anywhere, assume it's gone forever and probably curse Linux/Unix/BSD for being so unstable.
The media:/ IO slave doesn't have this problem, because if deals with devices while you must deal with directories. I realise your solution changes the icon of a mountpoint if the device isn't available, but is that enough of a deterent? Maybe they should be hidden instead. Or, maybe they could be made read only if the device isn't present. Or maybe just a warning dialog is needed to warn people trying to access empty mountpoints.
I hate to sound so critical, because I think what you've done is a major accomplishment. Congratulations.
Re: One problem
Yes, I noticed this problem with my cdrom mount point. Hopefully we can find a solution.
Thanks for being critical *and* *constructive* at the same time.
This kind of input is very valuable.
--
Simon
Solving URL issues
I agree that using home:/ and system:/ URLs is very troublesome for non-KDE apps (and some KDE apps too, which assume direct access to files).
But I think the right solution is to provide way to map these (pseudo-local) URLs to physical names, for example home:/file maps to /home/user/file. This could be done by some KIO protocol function.
And the long-term way to go is integrating KIO with Fuse
No, thank you!
I'm sorry, but I am the only one who thinks this is a step back? Why don't I get access to the whole file hierarchy, but instead are expected to navigate using physical devices again? Are we back to some old version of Windows?!
One of the things I really like about *nix is that I get one integrated file hierachy. No messing about with questions if something is on the C or the D drive and a new drive can be mounted where I need the space in the hierarchy. Excellent. Your patches throw all of that out. Sure, I understand that it is "only skindeep" on a technical level, but it is what you bring users into contact with. Furthermore, the fact that you get "unfriendly" names for your devices again only makes this worse. I don't want to know that my USB stick is on /dev/sda1 and just get that name, I rather like the fact that it pops up as "Kingston".
I think you have two conflicting goals, and the endresult ends up not satisfying either. On the one hand, you seem keen on simplifying the file hierarchy for (fresh?) end users by hiding a lot of stuff. Then, on the other hand, you want to expose the real paths of files so one can easier use them in other (CLI?) applications, arguably an activity for more advanced users. So, on the one hand you don't want to expose users to the whole directory tree, and on the other hand you do expose them to real paths with the argument that you may need them in other software that doesn't support KDE's kioslaves niceties. If users are exposed to the full file system in these other programs anyway, don't you think it is only confusing to hide it in KDE by default?
Presumably some of your
Presumably some of your objections can be satisfied fairly easily? For example:
- Make sure that devices show up with the "friendly names" in greyed, bracketed text after the mount point name. If distributions could provide better mount point names then this would be even better!
- If users have manually mounted devices in other places on the filesystem, such as mounting a hardrive at "/backup", just edit the .hidden file to make that show up. If you don't know how to do that, you're unlikely to be putting your devices anywhere on the filesystem other than in the default /media, in which case Simon Edward's solution causes you no problems
Also, although you're right that non-KDE applications will still show the full filesystem hierarchy, they will at least show the CDROM and other devices in the same place. So it's closer to a solution, and provides a nice idea for Gtk/GNOME to implement without needing to copy the media:/ and system:/ and home:/ kio-slaves.
There is always a "Hmmm..." :)
http://accentsolution.com/kde/konqueror.png
1. Expecting the Bookmarks menu to be there always is a bit too optimistic.
Bookmarks tab was in Mac version of IE for ages, and is very much loved by many, mostly because we can just drag things in it. Also, menu seems to go the way of Dodo in MS products...
2. If you are hiding the others' home folders anyway, what is the point showing /home with only one folder inside? Straight user's home folder always seemed to work fine.
3. Many koodos on picking $HOME and media as the only important parts of fs. That's a "right way" TM
GOOD work!
This problem bothered me for very long long time!
NOW,you do a useful work for KDE!
I hope this can be patched to next KDE version
# extra functionality to Konqueror to hide other people's home
And what, if you want to access other peoples home, because they share data with you by giving access to a subdirectory of their home directory? This is not helpful, but removes functionality.
Re: extra functionality to Konqueror to hide other people's home
Other people's home directories can be shown by selecting "Show Hidden Files" on Konqueror's View menu. Once you've navigated into someone else's home directory you can turn "Show Hidden Files" off again to hide all of the .* config files. You won't get automatically booted out of that home directory or anything.
Or the other person emails you the path of something in their home directory. You can drop that path/link into konqueror and it will still work as expected.
All of this "hiding" stuff is only skin deep and only affects the user interface and not the underlying operating system.
--
Simon
Love the idea...
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.