I found that QS maintains a list of types for objects, it might be nice to have something like that : Currently a catalog in Qatapult can only return one type of data. QS catalogs can return various types : as a example a contact might return a 'phone number','an address', etc.. all of them correctly typed. I could be very nice for declarating actions. That will also maintain types more homogeneous.
-ecaradec
I used to think of QS' object/type idea as something like -- each type for a given object representing a different "view" or "perspective". As an example, some object might have a view as a file on one's disk but another view of it might be the text of the full path to the file. Is that close to your understanding?
On a related note about examining existing systems...
It used to be that QS' source code was not available and writing plugins involved trying to understand the few examples available, asking on the forums, and trying to catch the main developer on IRC. I think the main developer felt his source code was very messy and was reluctant to release it for a while -- though he eventually did. Following a link from the guide you posted about, I learned that QS' source code went through a fair bit of cleaning up in recent years and IIUC it is generally available.
It's probably very obvious, but FWIW, being able to interact with QS and work with its source has some hurdles -- it's written in Objective C and only builds and runs on Mac OS X.
In contrast, the Kupfer launcher seems to me a pretty close emulation of QS and though AFAIK it doesn't run on Windows, its source (Python) is available and can run on *nix -- so can be tested pretty easily via something like Virtualbox.
I've only written one plugin for Kupfer, but I found it much easier than writing plugins for QS. I believe this has to do with Python being easier to work with for this type of thing compared to Objective C, but I think that's not the only reason. My impression so far is that historically, Kupfer had the advantage of being able to examine how QS worked and the developer was able to avoid a lot of messiness that crept into QS' evolution.
Well...anyway