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).

Damn these Mod privleges!!! Sorry Bugbyte, I hit the edit button by mistake and didn't realize until it was too late -dave

Originally Posted by BugByte

If you make CFE an iPhone dependent app, I'd encourage you to go all the way and make it a true extension of the iPhone.

The (theoretical) iPhone app will be the only thing iPhone dependent. The related idea (along with AppleScripting and my KeyBindings replacement) is to provide a generic interface for controlling CFE from an external (e.g. not a TS) source. An iPhone app is what I would be most likely to build to take advantage of the TCP/IP interface, but it's protocol would be open for anyone else to use if they wanted.

Originally Posted by BugByte

Just recognize that the user base will be quite a bit smaller as many people simply won't buy an iPhone.

Absolutely.

Originally Posted by BugByte

I know you haven't concentrated on skinnability, but neither has anyone else. While I agree in principle that a simple approach is the cleanest, one of the things people want is customization in their car PC. Right now, you can't even put you car logo on any of the FE's. Making CFE skinnable would be a big step forward for Mac FE's.

I'm not against it really (and I thought Jirka made QCar skin-able?), I just don't have the first clue about how to skin a NIB based Cocoa app (well besides the obvious of the skinner replacing the NIBs, but they would have to do this for all the plugins too).

-dave

Originally Posted by ghettocruzer

I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.

I for one will be very happy to see work continue on CFE as it's much more what clients want from an in-car GUI, simple, big buttons, not to many options to deal with and scaleable with the plug-in framework.
I'm impressed with the work done so far, I really think you're on the right lines with this project, however when you say no more Tiger support do you mean you will no longer be supporting Tiger or do you mean the app will rely on Leo components to run?
The reason I ask is because kit car enthusiasts are starting to examine in-car computing as a way of personalising and differentiating they're car, and indeed having a toy to show off. Many kit car enthusiasts still believe that the point of a self built car is to build something personal and unique for as little money as possible, as such many enthusiasts looking to integrate a Mac are looking at integrating second-hand Mac Mini's or as a practical, stylish option G4 iMacs, you'll usually find that older Macs have been upgraded to Tiger but with the hardware requirements in Leopard people are looking to replace rather than upgrade they're Mac leaving quite a few decent, older Macs going cheap with Tiger installed.
Also, has anyone developing an in-car GUI thought to approach any car manufacturers in respect of sponsorship funding for a project like CFE? No doubt BMW would be glad of someone offering them an alternative to the god-awful Windows CE based iDrive system... actually part of that sentence is redundant, I could have just said the god-awful Windows CE! But seriously whilst large scale manufacturers may not be to receptive, low volume car companies may well be interested in adding a Mac to they're products to help compete in a saturated, fickle and transient market sector.

however when you say no more Tiger support do you mean you will no longer be supporting Tiger or do you mean the app will rely on Leo components to run?

It is theoretically possible that the App itself will run on 10.4 (though it will not compile on 10.4) as it shouldn't have anything 10.5 specific in it (at least at this time). The plug-ins (at least the music player that will be released along side the app) will have 10.5 specific functionality that would prevent them from working on 10.4.

As long as the core remains workable in 10.4 (though I am not planning for this nor will I test for it), someone could build plug-ins for it that work on the older OS.

but with the hardware requirements in Leopard people are looking to replace rather than upgrade they're Mac leaving quite a few decent, older Macs going cheap with Tiger installed.

There are a few G4 Mini users here that have already upgraded to 10.5. Leopard is supported and runs decently on (at a minimum) everything since the debut of the original Mini.

But seriously whilst large scale manufacturers may not be to receptive, low volume car companies may well be interested in adding a Mac to they're products to help compete in a saturated, fickle and transient market sector.

I wouldn't call BMW a "low volume car company"
CFE is open source and they are welcome to run with it if they want. In the end it boils down to features, ease of us, and support. Car computers and their front ends in general do not fit those requirements. Until the companies like Alpine, Pioneer, etc.. take this market and it's possibilities seriously, you won't see it get any traction with the car mfgs. Look how long after the aftermarket stereos had various support (CD, CD Changers, Sirius/XM, MP3 CDs, NAV, etc..) before it started to show up in even the small mfg's cars.

I wouldn't call BMW a "low volume car company"
CFE is open source and they are welcome to run with it if they want. In the end it boils down to features, ease of us, and support. Car computers and their front ends in general do not fit those requirements. Until the companies like Alpine, Pioneer, etc.. take this market and it's possibilities seriously, you won't see it get any traction with the car mfgs. Look how long after the aftermarket stereos had various support (CD, CD Changers, Sirius/XM, MP3 CDs, NAV, etc..) before it started to show up in even the small mfg's cars.

-dave

The BMW comment was just a joke, have you seen iDrive? it really, really sucks, I mean more than usual for Windows CE and that's saying something!
As a matter of fact I asked because the subject of in-car computing has come up more than once in consultation with low volume/kit car manufacturers in the UK and the biggest concern is always ease of use, to be perfectly honest I'm just looking for a way to shortcut a budget limited project.

BTW: stuff Alpine & Pioneer, many car makers (especially low volume, specialist marque's who often make cars that don't even have doors) but also the big players are looking for solutions that can be integrated rather than the kind of in-car PC that mounts in a standard ICE slot. Very low thermal output/power consumption SBC's are seen as more attractive option as it can appear to be "magically integrated" just like integrated GPS systems and don't invite theft in the way that after-market ICE slot PC's do. However, bespoke integrated computers are expensive to design and are not really something specialist companies can afford, as a result there is a market for low cost solutions built around existing technology that end market customers will recognise but that can be used with a minimum of "eye time" when driving and that can be branded by the marque.

Great to see you back working on CFE, Dave. Ive been running CFE for a while now, but put down any work on the car once I got my mini in a working state. My long term goals were to code a plugin for the window and door control and have this controlled via bluetooth. But, once I saw the SDK for the iPhone I had the exact same idea (TCP/IP over a local wireless network). I've also tossed around the idea of using a cell card in the car, and a server to proxy the requests between the iPhone and the car to give kind of an onstar-ish control. I just haven't had the time to learn Obj-C well enough to get it done, which turns out to be a good thing given your new game plan.

I look forward to seeing the new line of code, and eventually jumping in to help out!

Well in typical me fashion, I did some work for a few days, got lost in the minutia, got bored, and haven't looked at it in a few weeks.

Mainly it's the UI elements that are hanging me up (the custom look is a royal PITA, especially since I haven't mastered that stuff yet). So i'm actually starting to work on a non-car friendly version of the App (e.g. using the normal OS X interface elements) that I can get out so people have something to work against for building and testing plugins while I continue to work on the APIs and UI elements.

My long term goals were to code a plugin

Let me know how I can help and I will be glad to offer advise, tips, review code, etc..

Hopefully Alex will a test that i'm more useful in helping plug-in developers than I am actually advancing CFE itself

I've also tossed around the idea of using a cell card in the car, and a server to proxy the requests between the iPhone and the car

My thought is to create an iPhone App that has squid (proxy server) built in (with an option to turn it on/off. I have a feeling that won't get by Apple though which means either limited (100) distribution or having to go the jailbreak route. Then there is the whole NDA fiasco which would seem to prevent making your App open-source. Only time will tell I suppose.

I just haven't had the time to learn Obj-C well enough to get it done, which turns out to be a good thing given your new game plan.

If you've worked with other languages (especially C and some OO languages), it's pretty easy to pick up.

I've been looking around for a decent front end that'll do what I want it to do and simply (ie. without too much hoopla and clutter) while I'm waiting for my parts to arrive - it's a long way down here to NZ

As a developer I'm hoping I'll be able to contribute to the code base as well (halfway through the xcode3 d/l!).