RedHat’s Matthias Clasen came up with the idea of caching the MIME information provided by the Shared MIME database (the list of MIME type aliases, subclass information, the glob patterns, the magic patterns and the XML namespaces) in a mmapable file today. With his attempt, there’ll be one cache file (mime.cache) per mime directory, e.g. on most Linux systems, this will be
/usr/local/share/mime/mime.cache/usr/share/mime/mime.cache~/.local/share/mime/mime.cache
while on for example FreeBSD, this will be
/usr/X11R6/share/mime/mime.cache/usr/local/share/mime/mime.cache~/.local/share/mime/mime.cache
(both with default $XDG_DATA_DIRS settings). He also provides patches for both xdgmime (the MIME implementation used by gtk+ and gnome-vfs) and update-mime-database.
The general idea is good, and the implementation looks good too. We should consider using the cache for Thunar as well. My major concern about this currently is the bad data locality with many mime.cache files (which should only happen if the admin is on crack) and the probably reduced performance due to the big endian to little endian conversions (we need a benchmark here to decide if it’s really worth to spend another thought on this conversion). If we’d adopt this idea for Thunar, we could further reduce startup time, as the process would not need to parse the MIME database first, and it would reduce the memory overhead, tho this is less critical in case of Thunar, since all windows (and the desktop background) run in the same process space and thereby share the MIME database.
Anyways, it’s nice to see some useful activity on the xdg mailinglist again, after all this discuss it to death-threads about D-VFS and gconf.
Edit: Additional notes can be found in this mail.
Looks like Thunar does not attract software developers (yet), at least they did not respond to my last mail to thunar-dev. Somehow it looks like we got a bunch of users and hackers hanging around on the mailinglist and waiting for code or mockups to play with, which is fun of course; but we need more dev activitity on the dev mailinglist. ;-)
Some more thoughts on the Thunar architecture:
This diagram illustrates the basic relations within the Thunar backend (and also includes a few entities from the frontent). The Thunar MIME applications/actions handling is pretty much undecided yet (both the backend and the frontend).
As the overall feedback on the Thunar suggestion was very positive, I think we are mostly settled with the user interface now. Only minor changes will happen on the user interface, no more major changes on the UI concept.
So it’s now the time to start to design the basic architecture for Thunar. Work on the MIME system was already started and a few bits and pieces can be found on the Wiki. The interesting part will be to design the ThunarView architecture, that is the way the main view will be designed and connected to the backend(s). My first idea here looked like this:
The idea is to separate the user interface part from the data storage (where storage is the wrong term here, as the data is already stored in the file system, a better term would be data manager). The volume manager is required to properly implement the Trash specification and to list the removable devices in the sidebar (both the shortcuts and the tree). On Linux we may use HAL to implement the volume manager, but HAL won’t be a requirement, esp. since it’s not portable at all, which conflicts with Xfce’s major goals.
This design offers several advantages (yes, it looks obvious, but it’s not; check other file managers and see for yourself): Adding different backends in the future or converting existing backends (e.g. move to D-VFS) will be very easy. Adding new views (like Column View or Tree View) will be very easy (version 1.0 should ship with List View and Icon View). The whole trash related functionality is implemented in one single place (except for the trash_file() function, but this function is more or less easy), which is a very good thing, since the trash spec is tricky and scattering the functionality over the source tree would surely become a maintaince problem over time.
More detailed information about this idea can be found on the Thunar Wiki.
So, I decided that it’s time to sum up the results of two/three weeks of Thunar UI discussion, and hacked it into a Wiki page:
http://thunar.xfce.org/wiki/ui:suggestion-20050320
I think we can all agree on this suggestion, as it provides ease of use and simplicity with the default look (layout 1), but without limiting the user too much (something that has been complained about by Gnome users quite often lately), since the user is free to use a different look and feel (layout 2) or even customize the layout to fit his own needs. This is exactly the kind of flexibility we need for Xfce, and that’s why people love Xfce: Put the user in control, but only to a certain degree. And of course, keep it lightweight and fast.