CarFrontEnd State of the Code
So it's been awhile since I have done anything meaningful with CFE, but hopefully that is about to change.
As some know I attended WWDC last week and while it did not meet my expectations, it did reignite my interest in moving CFE forward (oh the iPhone ideas I have :)). The bad news is that based on some of the things that I did learn at WWDC, I need/want to make some serious architectural changes.
The big upside of WWDC was that I got to spend time with the big AppleScript guys and now have pointers in the right direction to do it the way that I want.
The jist is that what is released now (outside of oh my god this is broke!!! fixes) is the last release of the current code line. It is also the last version that will support 10.4, so you'll need to upgrade for the new version (so will I actually).
From the users perspective, not much (if anything) will look/act different. The changes will all be under the covers (I still don't have ideas for skinning, so it's still not happening, sorry) which means that current plugins absolutely will not work. The upside is that for any plugins that have been written (and open source) at the time that I add the code to GoogleCode, I will help or take care of porting it to the new architecture myself.
The main points of the changes:
- iTunesPlugin to use the AppleScripting bridge (or whatever it's called now) rather than direct AS calls. Will make for cleaner code (making it better for being an example) and should run a bit faster.
- Use the Garbage Collector. I hate the idea of GC in general (learn to manage your memory!!!), but the stats and info they showed at WWDC convinced me that i'm making my own like miserable. The API framework will support either mode, but plugins will need to be GC compliant (much easier than the alternative actually).
- Make the current KeyBinding architecture more generic. The plugin will no longer bind keys to specific functions. They will define commands and what they map to, then the App will provide a way for the user to select what keys bind to the command. It will also bubble those commands up to AppleScript and a TCP/IP interface i'm thinking about.
- Add more custom UI components. I'm not releasing anything this time until I have custom NSButton, NSProgressIndicator, NSTextView (with OSK support), NSTableView, and NSScrollView along with a supporting IBPlugin.
- Performance tuning using Instruments (actually the current code line is much better than I expected, but could use some improvements).
- 10.5+ only, no more 10.4 support. I will continue to support PPC and will shoot for 64-bit compatibility (though I think at that point most of our Minis will be obsolete).
The main idea for almost all of my changes will be to make it that much easier for first time Cocoa/Obj-C programmers to build plugins.
So that is the jist. Feel free to comment, scream, etc..
So I mentioned a TCP/IP idea. Watching the keynote I started getting ideas for the iPhone (don't have a GPS antenna, why not have the iPhone tell the Mini where you are? Wanna setup the Mini to control your door locks and/or ignition, why not use the iPhone as a remote starter/keyless entry? Need internet access on the Mini, it may be possible to do it through the iPhone (yet to be determined if the SDK will allow what I think though). Want to browse your Mini's music library like the iPhone does it, why not use an iPhone to do it?) and the best way I can think of to do all this is via TCP/IP. My idea (mainly since I now have a spare WiFi router running around) is adding a router and hardwiring the Mini to it. Then the iPhone can connect and send WakeOnLAN packets to wake the Mini when it is sleeping, then send messages to it (and display information the Mini supplies it).