Design - Initial Considerations

These are initial, rough considerations for the project design.

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.

• file: - Used in the Filesystem branch.
• home: - Used in the Home folder branch.
• removable-media: - Used in the Removable Media branch.
• desktop: - 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).

The application preferences will be handled similar to Terminal, using the advanced attribute system provided by GObject. Thunar should by no chance use MCS!