Non skanky Quicklook plugin

itsthejayj's picture

Hi guys, just wondering if anyone has made a non skandy sdk quick look plugin, like kineme's own for QC? If so would you be willing to share?

Otherwise ... i shall set myself the mission to learn/create one :(

Thanks

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gtoledo3's picture
Re: Non skanky Quicklook plugin

If some kineme quicklook patch code pops up in my inbox, I'd give a quick run through of making it conform to qcplugin, if possible (seems like it would be). I don't think it's published, and I don't have the the time at the moment to do it from scratch, but it would probably be a quick thing to convert some already existing code.

itsthejayj's picture
Re: Non skanky Quicklook plugin

*tips cap @gtoledo3

Quicklook is my most used kineme plugin, however i'm currently working on a project that requires official API plugins only. Good practice as the mac app store doesn't allow private APIs in applications. Baring this in mind should it not be time we started re/creating some of the most used free Kme plugins without the Skanky SDK (where actually possible of course, i understand the befits of the unofficial framesworks).

@kineme Would be nice we could have a peek at the quick look patch source, possibilities of posting it to your github account?

Otherwise I think I'm game for learning how to make qc plugins, if @gtoledo3 doesn't beat me too it!

itsthejayj's picture
Re: Non skanky Quicklook plugin

Matt Gemmell has made a nice NSImage+quicklook category which should help the process

http://mattgemmell.com/2007/10/29/how-to-get-a-quick-look-preview-as-an-...

Now back to working out qc plugin examples

smokris's picture
Re: Non skanky Quicklook plugin

Yes, we'll try to get FileTools published on github soon.

gtoledo3's picture
Re: Non skanky Quicklook plugin

Cool.

Also, btw, I've had some contributions to some of the github stuff that I haven't given a final lookover and push yet (as well as the github shadow environment that OniDaito made with the skankySDK). Just mentioning that, because it's really cool that you put that stuff on github, and I want to see kineme get some kind of code contribution back from the community for it.

gtoledo3's picture
Re: Non skanky Quicklook plugin

@ itsthejay, I dig your logic about stuff working in the qcplugin api when possible, and have done a few plugins for that reason, even though I'm largely ambivalent about the apple appstore. I may be projecting, but I think some of the kineme hierarchy may be as well. Also.. I'm unsure, but you may have to load your plugins from inside the app to conform to sandboxing, or maybe have the user do something to explicitly say they can load plugins from the external folder. Not exactly sure, but I'd keep that in mind and research what is considered acceptable.

You know, I was just having a thought, that a bunch of the "custom data" stuff can probably also be handled in the qcplugin api without ability for virtual ports or custom ports by using a structure instead, and just making whatever that data is be an index. Don't hold me to that, I haven't tested, but I think it would be possible.

dust's picture
Re: Non skanky Quicklook plugin

here is a quick look plugin a la official sdk. quick look itself isn't to complicated just a couple lines of code. its providing the output image provider that seems maybe complex to me or maybe unnecessarily complex in reference to just assigning a image to a published port inside a qc application context. meaning its much easier to send an image to a qc view then to qc via plugin.

luckily apple provides developer examples that one can copy and paste. the provider in this plugin comes from apples fast image plugin which is a good starting example to look at. i guess it all depends on where your coming from. i actually found that making a non image processor type of plugin a lot easier at first.

so this is basically a synchronous version of kineme's plugin. it provides a boarder/frame view and preview width and height etc... if there is no image preview then the icon image of the file is shown instead. I'm nit really sure how your using the plugin. I'm assuming its for the file icons ? or are you just wanting to load images faster at a low res without sizing them in qc ? either way hope this helps.

hit me up when your ready to deploy and i can help you with loading the plugin inside your app.

PreviewAttachmentSize
QLook.zip57.62 KB
QLook.plugin.zip6.39 KB

gtoledo3's picture
Re: Non skanky Quicklook plugin

The compiled plugin doesn't restore on my system. 10.6.

gtoledo3's picture
Re: Non skanky Quicklook plugin

Oh.

Set your architecture for standard (32-64 bit Intel) and your base SDK explicitly for greatest likeliness of compatibility... for something like this, building 64 bit with deploy target being 10.7 and base 10.6 may not be the way to go since people still use 32 bit. Also, you only need to build for i386 and x86_64 unless you're dealing with 10.4 afaik. Any particular reason for using LLVM (not being critical, just curious)?

Not busting chops here, just throwing these concepts out there for anyone reading this who decides to delve into qcplugin :-) Haven't run it/looked at it anymore than checking out the build settings.

cybero's picture
Re: Non skanky Quicklook plugin

The compiled plugin did restore on 10.7.3.

However it hung in QC. Interesting plugin though. Then I went to try out the project. Clearly set to 10.7.x - or maybe that was a bit of on the fly Xcode 'magic' at work. This time around, with the plugin freshly compiled from the project and running in QC 4.6, it worked for both the Icon Look and the Image Look resources coded in .

The Xcode project gave some errors though, as follows line 20 QCPlugin.m

@implementation QLookPlugIn

Property 'inputWidth' requires method 'setInputWidth:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation
Property 'inputHeight' requires method 'setInputHeight:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation
Property 'inputIcon' requires method 'setInputIcon:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation
Property 'inputWidth' requires method 'setInputWidth:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation
Property 'inputHeight' requires method 'setInputHeight:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation
Property 'inputIcon' requires method 'setInputIcon:' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation

all of which refer to the properties being declared in the QCPlugin.h

On to usability.

I published up the two input paths.

Changing the resource requested on the input path via the Viewer's Composition Parameters resulted in a crash, although the resource requested was loaded; changing the parameters upon the Inspector panel for the composition worked just fine. Now I'm not sure entirely about one final point but it seemed to me that running the example composition might even have been of a system wide slow down effect. Not sure though , as I was using Firefox which seems to find a lot of people's site scripting to be pretty indigestible.

Did some further testing - got a couple of crashes.

Application Specific Information:
Uncaught exception "NSGenericException": -[QCImagePixelBuffer initWithFormat:baseAddress:releaseCallback:releaseInfo:bytesPerRow:pixelsWide:pixelsHigh:flipped:colorSpace:options:]: 
Argument "rowBytes" does not verify "((rowBytes == 0) && (address == NULL)) || (rowBytes >= [format packedBytesPerRowForWidth:width])"
objc[14642]: garbage collection is OFF
*** Terminating app due to uncaught exception 'NSGenericException', reason: '-[QCImagePixelBuffer initWithFormat:baseAddress:releaseCallback:releaseInfo:
bytesPerRow:pixelsWide:pixelsHigh:flipped:colorSpace:options:]: 
Argument "rowBytes" does not verify "((rowBytes == 0) && (address == NULL)) || (rowBytes >= [format packedBytesPerRowForWidth:width])"'

The report above comes after switching the frame option off and then switching between the Image Look and the Icon Look. Haven't found this to be entirely reproducible by the way. In fact all of the crashes reported above have not proven to be reliably reproducible.

The width and height setting are commensurate for the scaled down framed presentation of the image and don't seem to do any harm when presenting the framed font face, even though neither are actually 128 by 128 pixels in size.

dust's picture
Re: Non skanky Quicklook plugin

here this should clear up the errors as far as the method implementation is concerned.... as well as fix the horrible frame rate. i didn't notice it was running at 3 fps. i was just looking for image output. you will want to mess with the build settings.... it does build down to snow leopard though and can be used with gcc 4.2 etc... can't guarantee it doesn't leak or anything like that. i just cobbled this together mostly from old dev code in hopes to get mr hammond a start on his project. basically the change i made was input a get function so anytime you want to get an image you will need to pulse in a get. this seems to fix the slow down and fps issue and puts fps at n/a.... as far as the crashes are concerned i can not replicate @cybero but thanks for mentioning slow down, like i said didn't even notice it till you mentioned it. hopefully kineme will put some code on git so we can see the correct to make a plugin like this.

PreviewAttachmentSize
QLook 3.zip65.5 KB

cybero's picture
Re: Non skanky Quicklook plugin

Actually, funnily enough dust, I didn't get slow fps. It was a general slow system thing. Might be Firefox related. Has been my browser of choice lately on Lion. Could be Lion related alone, never mind Firefox. Could be I need to reinstall Lion. Shall be seriously considering that.

Meantime , just downloaded your freshly prepped project , opened it in Xcode and in the meantime, from the previous version I compiled from the previous project here's a telling screengrab [fps wise :-)]. Just a few more than 3 fps.

I find that the best way thus far to get that older version of the project plugin to crash is to just let it run, without any interference and it goes and crashes all on its ownsome.

Compiled, installed, running, good results, like the idea of the 'Get' switch. The fps is not as spectacularly OTT as I found, nor as underwhelmingly low as you found. Steady and usable. See the QLook 3 Image and Icon pictures. However, I did manage to crash the composition. Like I said earlier, it might be my own installation base, but .... it could be something else, shall be looking into the crash report. Will attach that in a post a little later on. Also , just noticed, the fps are now shifting between 45 fps up to over 200+. It was using the Preview screen shot utility that slowed stuff down a little in the Viewer window on the Icon and Image grabs posted to this response. Given that it's static stuff being displayed, I'd have thought that a steady n/a fps would be the best result.

Forgot to ask - any reason why the compiler wasn't set to Apple LVM Compiler 1.3 but was set instead to com.apple.compilers.llvmgcc42 ? I did switch it around as recommended, but I'm curious to know if I'm missing a trick - although I guess that gives better backwards compatibility.

Crash Report attached.

gtoledo3's picture
Re: Non skanky Quicklook plugin

Here's a half-decent stack overflow on compiler difs: http://stackoverflow.com/questions/5360996/compiler-differences

The different compilers optimize the code into assembly differently. If you want to get really into it, you can actually look at your assembly code and see if the optimizer has compiled it in as optimal a way as possible, and optimize it yourself. I don't recommend thinking about that much more unless you find that you are really into that kinda thing or are used to breaking things down to assembly already.

In general, I'd use whatever the system default is for general purpose (GCC 4.2 at the moment), and maybe switch to the most recent LLVM if you want to shoot for more optimal code - I've never had any problem using LLVM actually. LLVM is currently at 3.0, and I think that Xcode 3.2.6 came with 1.7 out of the box. Not sure what Xcode 4 uses offhand.

dust's picture
Re: Non skanky Quicklook plugin

yes @cybero i tried a few different builds but as far as 4.2 is concerned for backwards compatibility. or at least that was my intention. i normally like to use 3.1 with automatic reference counting or arc turned on but that is no good for backwards builds.