Re: [Nautilus-list] Icon directory contents caching

[Darin Adler <darin bentspoon com>]

on 10/7/01 2:31 PM, Alex Larsson at alexl redhat com wrote:

> I would personally appreciate a separation of the
> icon-choosing parts of it (mapping icon name or mimetype + size +
> current theme -> icon pixmap filename) from the in-core pixbuf caching.

That's a great idea.

The code is already careful to keep what *I* call the icon choosing part
(mapping the MIME type and other file attributes to the appropriate icon
name and emblem names) from the pixbuf fetching part.

But it doesn't try to keep the image file selecting part separate from the
pixbuf caching. There are really two steps here. One step is finding the
correct directory to read the file from. Then there's choosing the
appropriate image based on the size of icon you are trying to generate.

It would not be too difficult for me to separate these stages more. In fact,
I'd like to do it right away, but I worry that it would be a pain to merge
with your changes. What do you think?

> The mapping part could even be put in a library such as libgnome so that
> other apps could get the same icons without having the dependency on
> NautilusFile etc.

Here, I think you are mixing up things up a bit. The mapping part is the
part that depends on NautilusFile. The pixbuf caching is actually pretty
Nautilus-independent.

I know that other libraries would like to share the icon mapping, and this
is a high priority for the future. But I think that making the mapping part
independent of NautilusFile while keeping the features it currently has is
going to be a bit tricky.

> Even if this were not done i'd love it if the code was made clearer, and
> even more so if the method to look up an icon was clearly documented.

I'd like that too. It doesn't seem too difficult to reverse-engineer the
rules about the method to look up an icon, which is the approach I'd take.

    -- Darin