Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging Quick Look plugins




On Jan 23, 2008, at 10:45 AM, Chris Espinosa wrote:


On Jan 23, 2008, at 9:46 AM, Steve Mills wrote:

I found the docs that explain how to debug a Quick Look plugin <http://developer.apple.com/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/QLDebugTest/chapter_11_section_2.html>. But one thing I've found is that I have to manually copy the built plugin into /Library/QuickLook/. If I don't do that, then the debugger tries to start up, but then exits without displaying the qumanage window for the preview or thumbnail. My project has the default settings from the project template, including the Installation Directory of /Library/QuickLook. Is there something else I need to do in order for Xcode to copy the built plugin into that dir so it will debug correctly? Or should something else be changed so it can be debugged from the build directory?

This is a general Xcode FAQ.  The Installation Directory is only used in two circumstances:

1) when you do an 'xcodebuild install' from the command line
2) if you specifically and intentionally check 'Deployment Postprocessing' in the build configuration you use for Release

The reason the former is preferred over the latter (and neither is default or automatic) is that installation often involves using escalated privileges to set ownership and permissions on the installed product, or to install it in places that require escalated privileges.  We don't have a mechanism in the IDE to let Xcode do the whole build as your user but just the installation as a superuser, and if we don't do that, the first build-and-install would work but the second one would fail because your user can't overwrite a file originally written by a superuser.

The solution is to either set Deployment Postprocessing (and make sure permissions are set correctly) so you can repeatedly do Build Release from the Xcode IDE, or to go to the command line to debug, or to put a symlink in /Library/Quicklook to your Build Products folder where your regular debuggable executable is going to land after every rebuild.  I prefer the latter solution myself, and use it frequently for all kinds of system plugins.


Actually, a  third option (and the one I've used when working on QuickLook plugins) is to create a custom executable that points to /usr/bin/qlmanage and add an argument like (see 'man qlmanage' for more details):

-p -c "public.text" -g "$(BUILT_PRODUCTS_DIR)/quicklook.qlgenerator" $(HOME)/Desktop/quicklook/main.c

Since the Xcode will resolve the BUILT_PRODUCTS_DIR build setting properly when the executable is run, you don't have to worry about setting up anything outside Xcode (like symlinks). The other benefit is that you don't need to pollute your Quicklook plugins with your development plugin.

And before people ask, I've already filed bugs asking that the QuickLook project templates get updated with this approach.

Scott



Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden

This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden

This email sent to email@hidden

References: 
 >Debugging Quick Look plugins (From: Steve Mills <email@hidden>)
 >Re: Debugging Quick Look plugins (From: Chris Espinosa <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.