Re: [Nautilus-list] Icon directory contents caching

[Alex Larsson <alexl redhat com>]

On Sun, 7 Oct 2001, Darin Adler wrote:

> 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?

Go ahead. I can merge my stuff without much problems. It is not much work.
 
> > 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.

Ah, i wrote this without actually looking at the code. Sorry.
 
> 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.

Yeah. The next best thing would be to document it and reimplement a 
"simpler" version outside of nautilus then.
 
> > 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.

I'll take a shot at this on monday.

/ Alex