Re: Grief with porting IB palettes to plugins
Re: Grief with porting IB palettes to plugins
- Subject: Re: Grief with porting IB palettes to plugins
- From: Ricky Sharp <email@hidden>
- Date: Thu, 1 Nov 2007 19:09:43 -0500
On Nov 1, 2007, at 6:33 PM, Rainer Brockerhoff wrote:
At 16:11 -0700 01/11/2007, email@hidden wrote:
From: Ricky Sharp <email@hidden>
Date: Thu, 1 Nov 2007 17:51:30 -0500
Message-ID: <email@hidden>
I unfortunately assumed that porting my IB palettes would be fairly
straightforward. I just cannot get anything to work in IB's
simulator.
All my plugins suffer the same fate as the ClockControlPalette
sample. I can drag items from the library over to say a window.
Running will always crash the simulator and in the console I get
the same report:
2007-11-01 17:44:45.457 IBCocoaSimulator[6464:10b] An uncaught
exception was raised
2007-11-01 17:44:45.458 IBCocoaSimulator[6464:10b] *** -
[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of
class (ClockControl)
11/1/07 5:44:45 PM IBCocoaSimulator[6464] *** Terminating app due
to uncaught exception 'NSInvalidUnarchiveOperationException',
reason: '*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot
decode object of class (ClockControl)'
I ran into that, too.
The thing is, the new simulator is a separate app, and it expects
your class to be available in a framework; static-linking it into
the plugin no longer works.
The Xcode template apparently expects you to build your class
framework to a fixed absolute location (like /Library/Frameworks),
and then include the ibplugin within the framework's resource
folder. And apparently you should distribute it that way, too! But
then, it's not practical for inclusion into an app. Beats me why
they decided to do it that way...
I filed a bug disagreeing with that. rdar://4704698/ and it was
closed with the remarks:
Interface Builder v3.0 will automatically find plugins which are
*resources* of a required framework for a project. If you create
an IB plugin for a framework, you can install the .ibplugin in the
resources for said framework: when a NIB file is opened from
within Xcode, IB will pull the list of frameworks for the project,
and then search them all for plugins which are not yet loaded.
If you would like to have your plugin loaded, please install it
inside of the framework it is exposing in IB.
Anyway. Since I want to ship my ibplugin separately from (and
outside of) my framework, I'm building the framework inside the
plugin, instead of the oterh way around, and for now it works OK.
HTH,
Rainer,
I will definitely try what you did (framework inside the plugin).
However, after I installed the ClockControl framework inside /Library/
Frameworks and reloaded the plugin that sat inside the framework's
Resources, I still get the crash in Simulator.
Previously, I did have the framework installed to ~/Library/Frameworks
and I had IB install a 'loose' copy of the .ibplugin file. I can now
see why that would not work. I'm going to attempt to install my other
plugins co
After I place my test plugin frameworks in the correct spot and
attempt to load them into IB, I get "Could not load plugin" due to
"its principal class is not a subclass of IBPlugin". I just cannot
win! I even tried a fresh IB plugin project, walked through the docs
and still get the not a subclass of IBPlugin. In inspecting all
Info.plist files though, the class in question is indeed a subclass of
IBPlugin. Also inspected ClockControl to see if there was anything
different, but couldn't find anything.
So, in summary, my plugins now refuse to install. And when they did
install, they (as with ClockControl) all crash the simulator.
I'm giving up and waiting until the weekend.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden