Postponed all work on the icon view for now, and been working on the volume manager and the trash implementation for the last 2 days. As initially planned, the ThunarFile class is now an abstract base class and the ThunarFolder class will be turned into an interface or an abstract base class as well. In addition, the ThunarFile class won't export the associated ThunarVfsInfo (which is now only associated with ThunarLocalFile instances). This way we don't limit ourselves to file implementations, which are more or less based on stat(2) directly. For example, there will be virtual files, like the trash can itself, and forward files like the trashed files. You could even imagine another class that handles locations other than file:// and trash:// using GnomeVFS, to provide support for network file systems and such. But that is an optional gimmick and not important right now.
A friend of mine pointed me to an interesting article today, which on first sight looked like just another useless Linux vs. BSD article, esp. since it quotes Theo De Raadt, who was never known for being very objective. But De Raadt points out some real problems with the Linux development model (everybody that has ever worked on the kernel or a non-trivial driver will be aware of these problems). Unfortunately, De Raadt's diction is very bad, as usual, and so it's unlikely that any of the Linux guys will pay much attention.
It's been very quiet in the Xfce community lately. The traffic on thunar-dev and xfce4-dev is amazingly low. I'm currently the only one to work on Thunar, tho Alexander, Jean-Francois and Brian have expressly declared their interest to help earlier. In addition the Thunar website project seems to be fast asleep.
I refactored the new GtkIconView into an ExoIconView implementation, added the required magic to ExoCellRendererEllipsizedText and did some testing. The result was disappointing: It is very slow for large models (1000 items and above), esp. in resizing and rubberbanding, even on a fast machine (with Render hw accel). I imagine that it would be frustrating to use Thunar with this icon view on a slightly slower machine. Besides that it contains some tricky rendering bugs (one of which looks pretty similar to a bug I've also in my own experimental icon view, where the focus rect is not cleared properly sometimes).
I just updated my gtk+ sandbox and, wow, the new GtkIconView in gtk 2.8 does exactly what is required (atleast from a first look), without breaking the API, thanks to RedHat's Matthias Clasen. The new icon view uses cairo for rendering, which of course leads to flickering and rendering errors if combined with the good old way of rendering things in GDK, since the cell renderers in a Gtk+ 2.4/2.6 installation still use plain Xlib functions (through the GDK wrappers). But this is more or less easy to fix, as we can use GDK functions instead of cairo functions (probably Xrender for the rubberband... tho, unfortunately the most interesting function in GDK here isn't public).
One of the first things that perplexed me when I looked at GtkIconView (back in the gtk 2.5 days) was "why the hell is there no GtkIconViewItemRenderer?". I guess somebody was worried about performance and therefore the renderer was hardcoded into the first icon view implementations (which is of course not very flexible and can lead to weird work-arounds on the model side). Unfortunately, I hoped that over the time somebody else would notice the problem and magically fix it for the stable 2.6 icon view.
I tried to come up with the basic requirements for the volume manager interface and did some prototyping with the BSD implementation. My mail to thunar-dev, which summarizes the results of my current research, is still pending - I guess I shouldn't attach source code to mails. :-)
After spending some time improving the ThunarVfsURI internals (handling schemes other than file://, performance improvements and the like), I took the time to refine the basic requirements for the volume manager. The volume manager provides core functionality required for the trash system to work (esp. since my current plan for 1.0 excludes trashing to the "home trash" as fallback).
I have a more or less working prototype for the ThunarFavourites module now (well, it currently works a little bit different from the shortcuts list in GtkFileChooser, but I'm not going to care for that now). You can add favourites using DnD from every DragSource that supports text/uri-list (e.g. from the location buttons or another file manager such as Nautilus), or reorder favourites internally. There's no way to remove favourites currently (except editing ~/.gtk-bookmarks manually of course), but that's not important for now. All the low-level stuff in ThunarFavouritesModel is connected properly now. So the next step is to add some more stuff to the ThunarIconView GUI, and then I'll be ready to continue work on the low-level stuff, esp. the VFS Monitor and the trash system (unfortunately nobody volunteered to help with the trash system).
os-cillation is looking for a Perl guru to take part in a bigger project. So, in case you are looking for an interesting job and live in Siegen, Germany (or near to Siegen), send a mail to info@os-cillation.com.