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’m sure there’s a lot of potential for optimization in the new GtkIconView, but since the source file contains about 9000 lines now and internals have changed quite a bit, this would waste a lot of time and energy. And so, I’ll finish the work on the old ExoIconView, which is reasonably fast already, even with very large models.
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).
In addition, there are some problems with the cell renderer text API in gtk 2.4/2.6, which doesn’t include the wrap-mode and wrap-width properties. But these properties are required to layout the text properly. Again, not necessarily hard to work around; if everything else fails, the ExoCellRendererEllipsizedText class will be extended to support the text wrapping properties and will be used as default text renderer.
The more important problem is that my performance patch for the old ExoIconView won’t work with the new GtkIconView class, atleast not without major rework. The patch basicly replaces the GList-based item handling with a faster array based solution, which reduces both heap fragmentation and reduces time spend in malloc and time spend in loops looking up the item for a given index. The next step was to use a static item layout, which makes things like looking up the item for a position or determining the items within a rubberband selection very fast (tho, that was still work-in-progress and didn’t really work). Well, I guess, I’ll first import the new icon view and stuff into libexo and do some testing on it, and then we’ll see how important it is to forward-port the performance patches.
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.
Now, that was not the case. Gtk+ 2.6 API has stabelized and no GtkIconViewItemRenderer. We’ll have to implement our own renderer-based icon view with ExoIconView, which means that once that is done, not only the icon view implementation in libexo will differ from gtk+ (there are some major performance improvements pending for libexo 0.3.1 or 0.3.2), but also will ExoIconView provide the programmer with a completely different interface.
We really need this flexibility for the icon view in thunar, in order to be able to render emblems, etc., in a simple and fast way. The alternatives would be either a full-featured canvas widget (like Nautilus does with EelCanvas) or to pre-generate pixbufs with the embedded emblems in the list model, which would mean unnecessarily creating and copying a lot of pixbuf stuff. Both alternatives are certainly not very well suited for a fast (and lightweight) file manager.
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. :-)
Anyways, I think I caught the basic requirements for Thunar 1.0:
The question that remains is whether the volume manager should be implemented in the Thunar binary or as separate D-BUS system service. There are pros and contras for both solutions. If you feel like you have something to say about this topic, wait for my mail to arrive on thunar-dev. :-)
The prototyping with the interface described by the requirements above was satisfactorily so far. I hacked up a simple interface to the volume manager for the favourites pane and it now shows all removable devices, whose medium status is active, like in the screenshot below:
Hopefully the discussion on the volume manager will come to a useful result soon and work on the trash system design can start.
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).
From the high-level view, the volume manager module looks pretty simple:
The main goal is to provide a small interface, to support many different backends, but still includes all the functionality required for the upper layers. Back in 2003, I rewrote the core of the fstab plugin for xffm with support for many different platforms, so the basic code (which now also includes a few bugfixes) is there. We could also add HAL support later, but since HAL is only supported on Linux and isn’t widely used currently, this has very low priority (maybe even a TODO item for Thunar 2.0).
The important work for now is to define an interface to the volume manager, that allows the trash system to query the list of active trash cans (and also get notified once a new trash can is online) and the favourites view to display the list of removable devices. The favourites view also requires the ability to mount and umount/eject devices.
By the way, I’m looking for a term to describe the “eject/umount” action in the GUI. While “eject” is fine for CDs, it’s simply wrong for other removable media types, such as floppies or usb sticks - imagine an USB slot with the ability to fire off usb sticks. ;-)