Compatibility issues
stevo t
I'm just getting on the tagging bandwagon for a basic home brew font-
management solution...I figured tag folders could act like collections
(eg sans serif, or a project-specific set) of font files, which could
then easily be copied over to the ~/Library/Fonts folder and activated/
deactivated by font book.
But, the reason for this message is to ask about how tagfolders
implements the OpenMeta standard. I can apply tags with it just fine
(they show up in spotlight), but when it come to removing those tags,
a couple of the apps I've tried for viewing and editing them (tagger:
http://hasseg.org/tagger/ and tagit: http://www.ironicsoftware.com/tagit/index.html)
don't seem to register the tags (despite them showing up in spotlight
results just fine), they just show the file as untagged. Furthermore,
if I go on to apply a tag with one of these apps it nukes the original
tag-folder tag.
Actually, I just checked out the openmeta CLI and the quicksilver plug-
in (which I believe is just a front to the CLI), and along with tagit
and tagger they all play nicely...tag folders, it seems is the odd one
out.
Just interested really!
Steve
Jon Stovell
Jon
Jeff Horn
Can we "uninstall" tag folders in some meaningful way that deletes any
cruft that would remain? If so, we could just use the installation
procedure you've already developed in tandem with an uninstaller,
instead of using the installer to "update" the package.
A curious user,
Jeff
--
Jeffrey Horn
PhD Student in Economics
George Mason University
stevo t
Did I pick up correctly from the thread you linked to that OpenMeta
3.0 is perhaps less controversial in where it's storing the tag data?
I read some fairly heated articles about the dangers associated with
extended attributes (like the potential for apple to overwrite them at
will), which I picked up on in your post...as someone with no previous-
and-now-inoperable tags to be concerned about, this would be
reassuring for the future.
However, I'm sorry it seems that consequently you've got a struggle on
your hands updating things for those who got on board before 3.0. I'll
thank you on behalf of those guys for trying to find a way out of the
apparently fairly naff situation you and your software were put in!
Steve
On Feb 17, 5:12 pm, Jon Stovell <jonstov...@gmail.com> wrote:
> Hi Steve,
>
> The reason for this behaviour is that the current release of Tag Folders does not use version 3.0 of OpenMeta. Version 3.0 made some significant under-the-hood changes to how OpenMeta attributes are named and indexed by Spotlight.
>
> Unfortunately, the changes break Tag Folders (and indeed, any Smart Folders that search for tags using the proper "Tags is/begins with/ends with/matches/contains 'tagtext'" syntax instead of the simplistic—and often inaccurate—"Items matching text 'tag:tagtext'" syntax). You can get some more info on the exact nature of the problem athttp://groups.google.com/group/openmeta/browse_thread/thread/2aa3d284....
>
> I have developed a version of Tag Folders that uses OpenMeta 3.0, but getting the installer to update everything properly has turned out to be more difficult than expected. Until I can get those bugs fixed, I won't be able to release a new version of Tag Folders that is compliant with OpenMeta 3.0.
>
> Jon
>
> On 2010-02-13, at 3:09 PM, stevo t wrote:
>
> > Hi there,
>
> > I'm just getting on the tagging bandwagon for a basic home brew font-
> > management solution...I figured tag folders could act like collections
> > (eg sans serif, or a project-specific set) of font files, which could
> > then easily be copied over to the ~/Library/Fonts folder and activated/
> > deactivated by font book.
>
> > But, the reason for this message is to ask about how tagfolders
> > implements the OpenMeta standard. I can apply tags with it just fine
> > (they show up in spotlight), but when it come to removing those tags,
> > a couple of the apps I've tried for viewing and editing them (tagger:
> >http://hasseg.org/tagger/and tagit:http://www.ironicsoftware.com/tagit/index.html)
Jon Stovell
Unfortunately, no. The file at issue is OpenMetaSpotlight.mdimporter, which is typically installed in /Library/Spotlight. Removing anything else would have no effect. The maddening part is that there is no predicable effect to be had from removing, overwriting, or replacing and reimporting this file either!
From what I can tell, this is due to the convergence of two factors at work with OpenMetaSpotlight.mdimporter. First, unlike many other mdimporters, OpenMetaSpotlight.mdimporter does not specify any particular file types that it works with. This makes sense for OpenMeta, because it actually handles all file types. Second, the means by which a new version of an mdimporter is usually processed is simply by telling Spotlight to reimport the files that that mdimporter handles. In the process of reimporting them, the new schema in the mdimporter is sucked into Spotlight. But because OpenMetaSpotlight.mdimporter does not define any actual file types to work with, the reimport procedure does nothing, and so Spotlight's internal schema doesn't update.
Now, from what I can tell, Spotlight does seem to have a fallback system here, such that every once in a while it makes sure its internal schema matches up with whatever is sitting in the various mdimporter files. But this happens in its own sweet time, and is neither predictable nor very consistent.
Jon
Jeff Horn
Thanks for the quick response. I'm no programmer, but I was able to
follow most of what you said. It sounds like Spotlight's architecture
is what is posing the problem here.
It's probably a nightmare to program around such erratic behavior,
especially since the contingent processes are
unreliable/unpredictable.
Here's hoping for a better Spotlight in the next OS release!
Best,
Jeff