show quick look preview in a view

I am trying to show the preview of a file in a View instead of in a panel. All examples I fo开发者_StackOverflow社区und are about QLPreviewPanel. :(

Thanks in advance for your help.

---

Starting in OS X 10.7, there is a public API for this: QLPreviewView.h, which is part of the QuickLookUI framework (which is part of the Quartz framework). There doesn't seem to be documentation on it, but the header file provides some basic info.

---

It seems like Apple really wants you to use the QLPreviewPanel; the only possibility I see is "scraping" the preview, by setting the panel to layer-backed and getting the contents of the correct sublayer. Something like this (although I haven't gotten it to work):

[[[QLPreviewPanel sharedPreviewPanel] contentView] setWantsLayer:YES];
[[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil];
NSLog(@"layer: %@", [[[QLPreviewPanel sharedPreviewPanel] contentView] layer]);
// I believe there are two sublayers
id QLcontents = [[[[[[QLPreviewPanel sharedPreviewPanel] contentView] layer] sublayers] objectAtIndex:0] contents];
NSLog(@"contents: %@", QLcontents);
[myView layer].contents = QLcontents;
[myView layer] setNeedsDisplay];

Not a final solution by any means (this doesn't work as is) but maybe it'll point you in a useful direction.

UPDATE: Just stumbled across a category on NSImage, written by a fellow named Matt Gemmell, which uses QLThumbnailImageCreate. Look for "NSImage+QuickLook" on his source code page. He seems to imply that the QuickLook Panel actually uses QLThumbnailImageCreate. I think that function may be the best way to go. The category might make your life a little easier.

---

I've made some headway with this. The sublayers' contents were nil. But the old-fashioned subviews work:

[[[QLPreviewPanel sharedPreviewPanel] contentView] setWantsLayer:YES];
[[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil];
NSArray* subviews = [[[QLPreviewPanel sharedPreviewPanel] contentView] subviews] ;
for (id subview in subviews) {
    // The first view is the one we want, which is an unsubclassed NSView.
    // The second is a QLPreviewTitleBarView.  However, instead of relying
    // on that order, we check for the class.
    if ([subview isMemberOfClass:[NSView class]]) {
        NSLog(@"frame of subview: %@", NSStringFromRect([subview frame])) ;
        // The following statement will *remove* the desired subview from
        // the QLPreviewPane and place it into myWindow instead.
        [[myWindow contentView] addSubview:subview];
        break ;
    }
}

It even seems to update myWindow when I send -reloadData to the QLPreviewPane. I'm feeling slimy. Not sure what to do next, though. One problem is to deal with the arbitrary size of the subview. One of the reasons why I don't like QLPreviewPane is that there is no control over the window size; it gets a view from the generator at some arbitrary size and splats it on the screen. I guess I could put it into a scroll view. Another issue is how to deal with the QLPreviewPanel which is still on the screen. Maybe set its frame origin to off-screen But I need to go work on another task right now. Any further ideas would be appreciated.

Later. I think this approach is going to be to problematic. First, I tried to get rid of the QLPreviewPane window by sending it a setFrameOrigin:NSMakePoint(10000, 10000). Result: [QL] Assertion failure ([event window] == window) - Wrong window in event. Then I tried to omit the call to -makeKeyAndOrderFront: and instead skip up to -reloadData. Result: [QL] QLError(): -[QLPreviewPanel reloadData] called while the panel has no controller - Fix this or this will raise soon. See comments in QLPreviewPanel.h for -acceptsPreviewPanelControl:/-beginPreviewPanelControl:/-endPreviewPanelControl:.

The second error is understandable, however it indicates that the QLPreviewPanel will not try to find its data source, as it does, until it is made key or ordered front. The first assertion, however, indicates that, besides not providing a proper API to get the preview data directly, maybe Apple has laid some traps for the casual hacker like me.

If I come back to this, next time I'll try the more serious hack proposed by Ken Apeslagh.