You can pick any new feature you want, as long as it is this one

This last week I’ve been working on the icon and thumbnail handling on the nautilus gio-branch. gnome-vfs doesn’t really handle icons at all in the API, so all the code related to selecting and rendering icons for files was done entirely in nautilus. The way this was done was also a bit weird compared to how other things worked.

Nautilus has this abstraction called NautilusFile that contains all the information we know about the file. You can request for it to load specific information, and to get notified when it changes. However, icons were not handled by this. Instead there is a class called NautilusIconFactory that lets you map from file to icon (and incidentally handle things like icon caching, loading thumbnails, etc). Sometimes the icons can change though, like when the icon theme is changed, so all consumers had to also watch the icons_changes signal on the icon factory (in addition to the changed signal on the NautilusFile).

gio adds support for icons (and to some extents thumbnails) directly in the vfs. In the normal case we decide what icon to use for a file in the same way (based on the mimetype). However, this happens in the gio backend, so if the backend has special needs for icons it can do whatever it wants.

This is great stuff and will allow backends to be more expressive, and applications need less code to handle icons. It does however mean that the code in Nautilus doesn’t really match the new APIs. So, since I had to completely restructure the code anyway, its with great pleasure I can announce that since yesterday NautilusIconFactory has been removed from the gio-branch, and the new icon and thumbnailing code is integrated with the NautilusFile object in a much saner way.

Most of this work is just changes needed to work with gio rather than new features. I did however add one new feature. If you resize icons so that they are larger that the thumbnail generated for them (i.e. 128 pixels) they look very blurry. I’ve seen a lot of people with such scaled up pictures of pets or loved ones on the desktop, and it looks quite ugly. So, I made the thumbnail loader try to use the file itself as thumbnail if the icon is scaled above 128 pixels:


Wax On!


Wax Off!

None of this work significantly brings down the number of gnome-vfs calls in nautilus mentioned in my last blog. We’re now down from 803 to 510 compared to 531 in last entry. I think I will need to convert the GnomeVFSVolumeManager calls to gio now, as that will bite of a large chunk of this.

6 Responses to “You can pick any new feature you want, as long as it is this one”

  1. Mathieu Laurent says:

    Great feature !

  2. Mati says:

    Nice to see this work :)

    Now that backend for Nautilus is changing, is there any chance to correct GUI too?
    Like pressing right key at the last item in a row doesn’t move to next line (I don’t know if it’s bug #43285)?

    Thanks,
    Mati

  3. Jon Cooper says:

    Excellent news – this restructuring of Nautilus will lead to stability improvements when just dealing with files, but at the same time lead to a reduction of code across the platform… it really is surprising how much effort goes into thumbnailing and MIME sniffing in applications :)

    Keep up the great work – I look forward to a stable release of NautilusNG ;)

  4. Sven says:

    I hope that you are trying to read the 256×256 thumbnail from the “large” folder before you actually load the image file. But I guess you just skipped that detail in your blog entry…

  5. alexl says:

    sven: I don’t atm, since gnome doesn’t generate that normally. However, it could easily be added.