I have done a lot of work with plugins for xcode, and have run into many obstacles with the architecture. One of the biggest obstacles I found, was that since the plugin is loaded as a bundle of xcode, it does not gain application status of its own but rather allows xcode to hold the application status. This makes allocating large amounts of new memory and dealing with complex data structures quite a bit more difficult than if you were working in a standalone app. I’ve also found there to be a lot of quirks in the way the plugins handle various scripting methods. There seem to be some unexplained bugs or incompatibilities in the plugin architecture that I have yet to overcome. The plugin itself is not a subclass of say nsapplication or nsobject, but is a subclass of the “ASKplugin” class, which has little support and absolutely no documentation or examples. I have received wierd errors when using code within my plugin that is completely error-free when cut&pasted into a stand-alone app.
If you’ve messed with apple’s only plugin sample code found on the ‘plugin loaded’ doc, you’ve probably found that you indeed CAN create a menu quite easily… and depending on the planned intensity of your menu this may work fine for your needs. I would assume though, in your ambitions to add “full” support for just about anything to Xcode using a plugin, that your project will be fairly complex, thus…
The mode I’ve decided to employ, is to use a two-fold approach. Because I am using the “plugin” to do a lot of processing and data management, it’s proven to be unreasonable for me to rely solely on the plugin itself to do all of my work. I use the plugin merely as a gateway to my actual app. I have a menu created by the plugin that launches windows, pops up the about panel, checks for updates, etc. But I use it to call a ‘background application’ that handles all of the actual objects and code. Since I’m writing it myself, it is fairly simple to make calls to my BGapp and for the most part, once it’s activate it no longer communicates with my menu. As you can see, this may not be the perfect solution to everyone’s project design, as I’ve taken the functionality out of the menu and placed it in a window. The menu simply did not have the space and power to do what I’m doing.
As far as the AS/obj-c angle goes… I’d add whatever obj-c you can to your project. As I learn more about obj-c and get more comfortable using it, I find it to be more efficient, easier to code, and more flexible than just AS. No, it’s not possible to write it ENTIRELY out of obj-c, but you can use AS to open the door and then use obj-c to walk through it.
Like I said, I’ve put LOTS of hours into working with the plugin architecture. I’m still far from getting my plugin to real beta stage (mostly because I’m a slacker, though 8)). I’d be happy to share some of my insights with you in more detail, or to help you overcome obstacles if possible. I know that there are a few other people with some experience messing with plugins, too… and maybe they’d lend some insights, as well. PM me if you get to needing more input. I know NOTHING about python, but have come quite a ways with my knowledge of the xcode plugin architecture (after 10 dev versions of the same stupid unfinished plugin :rolleyes:)
Good luck,
j
