11
Replies
>> SLow Leopard (the old one)
LOL!
Thanks for the other tips - most are news to me.
Let's comparing some more notes!
Here's a few things I believe (I won't say 'I know' - I have no hard proof, and I don't have a budget to investigate getting hard proof 
)
I had extremely frustrating debugging issues with Xcode 3.1 - most of the time breaking into assembly code instead of showing the source code. No clear pattern: same breakpoint hit the first time shows the source code, second time assembly code. Fiddling with 'back arrows' sometimes got the source code to show up. It got so bad that I often had to revert to command-line debugging using gdb. Also a lot of 'mumble mode' - things just ................ coming to a pizza-colored cursor for no ................ apparent reason.
As a result, I've gotten into the habit of doing my coding and debugging on Windows XP with Visual Studio - once you get rid of the C-compiler RSP files and put the include paths into your project file instead, it works rather nicely, and to me it feels much faster than Xcode, even in a virtual machine.
I still do a lot of coding and debugging with InDesign CS on Windows/VS2003 - turnaround times (launch/debug/exit/...) are so much faster.
With Xcode 3.2.x on Snow Leopard things seem to work much better - so I might start to gravitate back to Mac-based debugging; time will tell.
CodeWarrior is over for me - I only use it to generate release versions (I still have some PowerPC macs around 'just in case' I need to debug something with CodeWarrior, but it's not been necessary).
As to Windows debugging: I use both Parallels and VMware, and my gut feeling is that Parallels seems to work quite a bit faster. Totally subjective, and probably unfair (the virtual machines have different histories, etc...) - but currently I find myself a lot in Parallels, with a virtual machine stored on an external USB drive connected to my laptop - I have heaps of virtual machines around, too many to store on the internal HD. Even with the slow USB bus 'underneath' it all, it works well.
With VMware I get a lot of mumble mode - machine non-responsive for minutes at a time, even with the virtual machine on the internal HD. Parallels has not done that to me (yet).
Another thing (might be fixed in Snow Leopard) - but have you ever had it happen that your InDy CS3 and CS4 plug-ins suddenly get a folder icon instead of a plug-in icon? Typically, all plugins will exhibit that behavior when it happens.
It's something with the package/bundle stuff, and the Finder getting confused. This is my unconfirmed theory: the Finder accepts a whole host of bundle formats, and the bundle structure used by the Adobe sample projects is 'iffy' - the Finder supports it, but occasionally, the Finder gets confused, and shows these plug-ins as folders (and that then further leads to customer support requests).
Now, if you go into the plugin package, it looks different from most other packages I've seen.
Here's how I fixed it: I added another build phase to the target - a 'Run Script' called 'Restructure Bundle'. I've put in the following shell script (using /bin/sh):
rm -rf $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
mkdir $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
echo InD3InDn > $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents/PkgInfo
mv $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Resources/Info.plist $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
mv $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Versions $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
mv $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Resources $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
mv $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/$PRODUCT_NAME $TARGET_BUILD_DIR/$PRODUCT_NAME.InDesignPlugin/Contents
AdChoices