On Aug 5, 4:35 pm, "Hamish Allan" <[EMAIL PROTECTED]> wrote:
> But the two separate codebases cover much of the same functionality --

Not really. See below.

> building resource headers, handling dot-underscore files, etc. The

The volicon module (per-volume custom icon) is extremely simple. Its
functionality is "hardcoded" in that it takes a given icon file as a
mount-time argument and forwards its data when it's requested. It's
not building any resource headers on the fly--it uses a constant
"volume has custom icon" bit blob and that's it.

Even if I implemented a wrapper function in the library to ask for
icon data given a file, your file system still has to look at the
path, figure out which icon data to use (and where it comes from--it
can't be as simple as in the volume icon case), and return that data.
It's still not going to be automagical or as straightforward as you
might be expecting. Moreover, the Finder info etc. can affect many
things besides custom icons--you wouldn't want an "icon" module to
deal with all these things. If it doesn't deal with other things, it
would need to somehow "unionize" data from multiple sources when a
"._" file is requested.

Anyway, there are other, more pressing things to do, so maybe in the
future.

FUSEObjC is still a "demo" API--hopefully over time it will improve in
flexibility, features, and ease of use.

Amit


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"macfuse-devel" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/macfuse-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to