Quote: Originally Posted by
Bugbyte 
As I understand it, a framework is a collection of routines that may be reused or need to be accessed by plugins, for example. If that is true, then what I was thinking was this framework could be useful not just for modifying, but also for giving people a leg up to create their own front ends with less programming effort.
Basically, you are correct.
A framework is meant to group code together that serves a similar purpose so that it is easily reusable. There are two main types of frameworks that are common. The first is the public framework which is meant to be used by other programmers either to extend an application or to simplify functionality for any application to use. The other is a private framework which is stored in the application that uses it and is not meant to be used by the rest of the world.
For CarFrontEndAPI, as well as defining the Protocol for the plugins it supports, it will mainly provide Cocoa control subclasses (and IBPalettes when I get that far) that will allow plugin programmers to easily maintain the look & feel. It's main goal is UI extentions, the protocol is just thrown in too rather than have a separate framework for a single header file.
Quote:
Most front ends need to play music. In the case of CFE, you have it controlling iTunes, which is a good place to start. What would be cool is if I could use the Framework for my own personalized interface, usint it to do stuff like return a list of music or playlists or to start/stop/pause and so forth. That way I wouldn't have to reinvent the wheel all the time.
That is a worthy idea, and actually probably a really good one to help build Mac frontends (if developers built frameworks that did the required functionality, then anyone could simply build a UI that they liked around it). That falls outside the direct scope of CFE, but I will try to keep it in mind when I write my own music player (e.g. write it as a framework that a plugin displays the info for).
Quote:
Increasing the capabilities of the framework would be done by adding modules to the framework.
This is actually not what you would want to do for a couple of reasons.
The first, as I mentioned above, is that a framework is supposed to provide rather specific functionality (e.g. you shouldn't have framework that primarily processes text also process images (unless there is some direct correlation)).
The second reason falls what the programmer/user needs. One of the main things I despise about Java* is the ability to import modules with * (e.g. import java.lang.*) because you are importing more than you actually need (I understand you don't have to, but it's shocking how many "experienced" programmers do!!!). While it is handy and simple, it is bad style and leads to code bloat.
For our purposes, if I am not interested in GPS why should I have to compile and link against a module that contains it?
The main goal of CFE is to provide an interface that allows the user (and the programmer) to only include what they care about and leave the rest out.
* I believe Java and similar languages being taught in CS courses is the death stroke for talented programmers that understand things like resource management. Just because HDDs and RAM is cheap does not mean there are not better things we can do with it besides linking in MBs of libraries that aren't required or letting the VM determine when I want to free memory.
Quote:
That would let others concentrate on the user interface. If some people wanted an interface that looked like an iPhone, okay. If others wanted specialty logos, that would also be fine. It would be a matter of setting up the UI to connect to the framework.
Am I off the tracks here, or is could it be done that way?
I don't think so at all. If we could build a library of frameworks like you suggest, then creating custom UIs would be insanely easy even for those with little knowledge of programming (e.g. they just need to know the basics of XCode, IB, and Cocoa/Obj-C).
For my part, I will try to keep this in mind as I start to work on other CFE plugins (AddressBook, sys info, and iCal (will require Tiger) are what are on my mind once I over come the UI issues that currently have me stumped). Then anyone can extract the framework from the plugin bundle and use them as they see fit.
-dave
).
You don't see them in the screen shots that I posted (actually you can in the full size version, it's just not as noticeable) because the image isn't stretched, that's what is making the flaw more glaring.
), so hopefully i'll have them fixed soon.
). In the meantime i've given up on fixing the button images and hope to enlist the assistance of someone from the group that has more graphics experience.
it works on my Mini now. Apparently 10.4.7, iTunes 7.1.1, and god only knows what archaic version of QuickTime were a bit too out of date for CFE. I updated everything on my Mini and it's all happy now 
Linear Mode
