Copyright © 2004, 2005 os-cillation
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. The complete license text is available from the Free Software Foundation.
January 2005
Table of Contents
Mimimum set of goals
The user interface must be intuitive even for average computer users.
The user interface must be clean, which means for example, the right-click menu should only contain the basic operations for a file manager, and should not be cluttered with confusing and useless options such as Create tarball or Create ISO.
Just like Terminal, the file manager should feature a high degree of maintainability, using OO design techniques and GObject implementation features. Maintainability goes over Performance.
This point goes hand in hand with the maintainability. Minimum required platforms are GNU/Linux (esp. Xfld), FreeBSD, NetBSD and Solaris.
File manager should be fully standard compliant. It doesn't buy us anything if we invent our own wheels.
File manager needs to be fast (startup time, directory load time, responsiveness). Fitness for the LiveCD scenario (see Terminal and xfdesktop-ng for examples how to achieve this).
The file manager needs to be fully accessible using Assitive Technologies.
Target version is 0.13.
Target version is 0.6.
Target version is 0.9.4. Use XfceDesktopEntry? Use XdgDesktopCache?
XfceIconTheme seems to be too slow (improve it? talk to Brian Tarricone), while GtkIconTheme in 2.5 offers a very good performance, but no XDG basedir support.
New target version is 0.7.0. Sample implementation exists for 0.6.0 exists in filer repository (without thumbnail repository support).
The implementation should be threaded, not a separate D-BUS service. Will this work with GObject 2.4? Yes, checked Nautilus, they generate thumbnails in threads as well. Still, I think the GObject thread-safety fix didn't make it into 2.4.
One thread per filer store or one thread for all thumbnails?
Internal represenation of file locations should be "file://" URIs.
Maybe for a version 2.0. The first-time code should consistently use URIs (libexo has already ExoUri, although its probably not the perfect implementation), so that at a later time its still possible to add remote file system support.
Version 1.0 should not feature any complex plugin system (at best, no plugin system at all). This includes inline editors, web browsers, full window previews, and the like.
Based on the current research, it looks like the best user interface for a file manager seems to be an icon or list view, with an optional tree view pane. The tree view pane must be connected to the icon/list view and show only directories and devices (unlike xffm). The tree view pane should feature exactly 3 independent root elements: Home directory (or Desktop), Filesystem and Removable Media (only if supported removable media devices are detected).
There are several possible ways to handle the desktop. It can be one of the special folders below the users home directory (popular locations are ~/Desktop or ~/.gnome-desktop/), it can be a virtual folder similar to a union mounted file system or it can be the home directory.
The desktop always confuses users, esp. if its a hidden or virtual folder. So the only real alternatives are ~/Desktop/ and $HOME. Both have advantages and drawbacks. For the $HOME-solution, there's an article available here that describes how to use the home directory as desktop with Nautilus and explains possible advantages of this approach. We have to decide whether we want to use ~/Desktop/ or $HOME, and we should definetly implement only one of those.
If ~/Desktop/ is used, the tree view pane should probably contain an additional root element, named Desktop (and the Desktop folder should always a specific icon in the home directory listing).
The advantage of using ~/Desktop/ would be that its compatible with other software (e.g. Gtk+, Gnome, KDE), that also refers to ~/Desktop/ as Desktop and so users do not need to distinguish.
A lot of users complained about the missing location bar in the spatial nautilus and in the new GtkFileChooser, while others claim that this is a major user interface improvement. If the file manager includes a location bar, it will be optional and disabled by default.
As an alternative to the location bar, there should be an Open Location dialog (using Ctrl-L as default modifier to be compatible with GtkFileChooser) that allows selecting a directory to open, featuring automatic path completion, pretty similar to GtkFileChooser.
The file manager should include optional toolbars (disabled by default?) based on the toolbars framework in libexo. The default toolbar should be clean, e.g. there is really no need for a Logout in a file manager.
A perfect solution would be to have the Location bar (if any) as pluggable toolbar item (libexo supports that).
The menu bar needs to be well-structured and intuitive. First menu should be File with the file management related tasks (some of them also show up in the right-click menu), and additional items like the Open Location and Quit buttons. Other toplevel menus are the Edit and the View menus.
The user interface should feature an Up in the Go menu (and in the toolbar).
Next and Back seems to be common as well. In fact, Finder provides only these means of navigation, and no Up button at all. More research required.
Avoid exposing the implementation internals to the user interface. For example, use the term Removable media to refer to (a subset) of the fstab entries, rather than using the term Fstab in the user interface. Many users do not know (and do not care) about /etc/vfstab or /etc/fstab.
Avoid so-called unbreak my software-options, and any other kind of useless option. The perfect world "just works"; but, since we don't live in a perfect world, we need a few basic options. Still, "just works" is the way to go.
Accessibility is an important point today, which unfortunately gets ignored too often. Terminal is a good example how to make an application accessible (actually the ExoIconBar is currently the only part that is missing AT support). For filer, the ExoIconView class needs to be made accessible as well, and the whole interface - esp. the dialogs - needs to be designed with accessibility in mind.
The MIME system uses the Shared MIME Database to determine a MIME type for a given file (use stat()-Infos to recognize special inode/* types). If a file fails the MIME database detection, and the first 256 bytes are valid UTF-8, the file is text/plain, else the file is application/octect-stream.
Every file has a primary MIME type, determined using the Shared MIME Database (with the given fallbacks on text/plain and application/octet-stream). In addition to the primary type, every file can have any number of additional MIME types (subclassing). Also, every file has an implicit type of application/octet-stream (probably even support application/x-extension-<EXTENSION>).
The MIME applications for a single file are determined using all attached MIME-types. Again, there'll be a primary MIME application, and probably several secondary methods, that will be presented as Open With choices in the File menu and the right-click menu.
The user should be able to specify the primary MIME application for a given MIME-type. From the user interface view, the current approach in Nautilus looks very sane, although it still exposes the implementation details (the MIME handling) to the user interface. More research is required in this area.
Use different URIs to refer to files, depending on the tree view context.
Used in the Filesystem branch.
Used in the Home folder branch.
Used in the Removable Media branch.
Used in the Desktop branch (if any).
This approach makes the overall design and the implementation more logical. For a user, it is confusing, if he is currently acting in the Home folder branch, presses Up and is placed in the Filesystem branch, in a directory /export/home or /home. New users don't understand that, because they don't care. Implicit jumping between branches even confuses advanced users because you have to realize the new context first, before you can continue. So, its better to not be able to press Up in branch root folders, and the URI scheme mentioned above helps to implement this cleanly.
Thumbnails should be created in a separate thread. At best one thread per file view. The thumbnail spec should be implemented 100%.
The file manager should, just like Terminal, handle all directory views in a single instance, using D-BUS for the required IPC. The file manager should additionally provide a simple D-BUS service to allow other applications to copy/move/delete files and directories and it should offer a replacement for xfrun4, where the window manager would basicly just send a D-BUS method to the file manager and the file manager opens the Run program dialog (Note: if the file manager is moved to Xfce, there should be a fallback in case the file manager is not running). This offers several advantages, esp. since the file manager knows about MIME-types and MIME-applications, it can simply open files from the Run program dialog.
Reducing the number of instances will reduce the overall resource overhead of the file manager, and make sure that common data is really shared among different file manager views.
A special case of this rule is the desktop, which will also run in the file manager instance, but will be an optional service. Parts of xfdesktop can be easily merged into the file manager, so we don't need to reinvent the wheel. Afterwards, xfdesktop will be obsolete for Xfld, and we should move the menu code into a separate module - xfld-menu or something like that. (Talk to Xfce developers about this, in case the file manager gets used by Xfce as well).
The file manager needs to maintain different kinds of icons, atleast Thumbnails and MIME type icons. These icons can change at any time, in case of a thumbnail, the original image could be changed, and in case of a MIME type icon, the icon theme could change. In addition the file manager might need to render emblems on top of these icons.
There should be a base class FilerIcon for all kinds of icons, which provides the change notification, the embedding, and the scaling of icons. Additionally, it could implement some kind of caching for the icons, if necessary (e.g. MIME type icons would benefit from caching).
Filer data will be presented by implementing the GtkTreeModel. On-top of this, there will be the ExoIconView and the GtkTreeView (as list view). The optional tree view pane needs a tree model backend as well, and we need a unified design for the backend code.
Its very important to reduce disk seeks (notably stat()s and file content accesses). For the MIME detection, the file manager should probably even skip the magic-detection and use only the glob-detection (problem here, is that we need to grab the first 256 bytes anyways to detect if the file in question is a text file, as the fallback).
Fortunately, the Shared MIME Database Specification is well-thought, so there's enough room for optimization on the implementors side. The most important point is to optimize the common case - the glob-detection - as much as possible. The most common case of a glob is *.EXT, an extension with 3 ASCII characters. Here the comparison can be speed up using a 32bit integer for the comparison instead of performing a comparison by character.
The filer repository contains samples of other optimizations.
ExoIconView can be optimized to avoid the time-consuming relayout calls. This requires changing most of the internals (sample code exists).
Testing releases should happen regularly, atleast once per week during the beta stages. Afterwards, stable releases will happen with every new Xfld release (approx. every 7 to 10 months).
The current schedule for the 1.0 release, which should be ready by the time that Xfld 0.3/1.0 is released (depends on Xfce 4.4.0 progress).
Research in the area of file managers; try to figure out the problems of other file managers, so that we don't repeat them.
Decide on the basic user interface (prototype required?).
Finish the overall design, and write some sample code to do performance measuring on the critical parts (MIME-detection and the like).
Implement the code, adjusting the design on-the-fly if necessary.
Experiment with the user interface.
Final check on the user interface.
User interface/string freeze. Translation and user documentation process starts now.
Beta stage, write test cases for the code. Bugfixing/stabilizing the code.
Release candidates. Final fixes.
Documentation/translation freeze.
Release version 1.0.0, together with Xfld 0.3/1.0.
The final steps for the 1.0 release heavily depend on the Xfce dudes, and their 4.4.0 release. But will be no problem with coordination if Benedikt Meurer handles the 4.4.0 release again.