On Jun 11, 2011, at 7:06 PM, jp63 wrote:
> Yup, I had heard there was some need for it so I thought I'd try and
> contribute.
Holy crap! Way to jump into the deep end. :) I was going to do this but haven’t
started yet. The idea of it intimidates me (and I wrote the plug-in development
reference).
I think that plug-in does things that no other plug-in does, so you won’t find
it all documented in the reference.
> The theory behind me doing this was to test whether the iTunes library had
> been modified and only rescan it if it had been modified. Do you think
> there's a better way using the Quicksilver catalog date?
Like Patrick said, there’s no need to check this in `objectsForEntry`. The
return value of `indexIsValidFromDate:forEntry:` will determine whether or not
`objectForEntry` gets called at all, so it can be just an unconditional
scanner. The date passed in represents the last time Quicksilver updated this
entry. You would then compare that to some other date that you got by examining
the iTunes catalog.
> Do you think this is more efficient than simply storing the previously
> modified date and doing a string comparison?
Quicksilver is already storing the date (as an NSDate). I don’t know which is
faster between a date comparison and a sting comparison but I doubt that it
makes a difference, so I would go with the established method. (Makes it easier
for others to figure out what’s going on later.)
> I also have one more question. I'm having trouble adding objects to the
> catalog. I don't believe objectsForEntry: is being called (I added a
> notification for debugging).
You probably need a “dummy” version of `indexIsValidFromDate:forEntry:` that
returns YES unconditionally. That’ll cause a rescan every 10 minutes (or
whatever your interval is) but during testing, that should be fine. You can
make it smarter later. (Actually, that method does nothing more than return YES
or NO unconditionally in a lot of released plug-ins I’m afraid. Don’t do that.)
You also need to solve a mystery here. (One of those things unprecedented in
other plug-ins.) Artists and Albums appear to be indexed by Quicksilver, but
they are not in the main catalog (nor would I want them to be). So you’ll need
to figure out what the “Search Artists” trigger is actually searching. I have
no idea how it does this. (The trigger, I’m sure, just calls Browse Artists ⇥
Search Contents, but where are the contents?)
> In the plist, I added the type to QSRegistration > QSTypeDefinitions and
> QSObjectHandlers. Do I need to add it somewhere else?
We don’t have the old code, but we have the old plist. My plan was to just take
that, make some minor adjustments, and fill in the blanks.
On Jun 11, 2011, at 9:04 PM, Patrick Robertson wrote:
> As for your question: Quicksilver needs some way of knowing when/why you want
> to call the objectsForEntry method. The two cases are when you right arrow
> into an object, or when you enable a Catalog item in the Catalog Preferences.
One minor clarification to this. Right-arrowing into something actually calls
`loadChildrenForObject`, not `objectsForEntry`. There are a lot of plug-ins
where it just does something like this:
- (BOOL)loadChildrenForObject:(QSObject *)object{
[object setChildren:[self objectsForEntry:nil]];
return TRUE;
}
But that’s not always the case (and probably won’t be for iTunes). Also, if
`objectsForEntry` knows how to get the children, it probably already has so
they’re in the catalog already. In that case, it’s probably much much faster to
pull them from there (using QSLib) than to rescan them from the original source.
So let us know if you have any more questions. (It would probably be better to
ask on the dev list. [email protected])
--
Rob McBroom
<http://www.skurfer.com/>
