Emmett asked:

>What did you study to learn how to do a plist file?

Emmett:

In addition to Deep's comments, one of the first things an FB 5.x 
coder typically wants to do is use a custom icon for his compiled 
application rather than FB 5's generic blue leaf icon. The 
instructions for overriding FB's default plist to use a custom icon 
is buried in the FBtoC documentation under "Language Enhancements."

Part of the reason for the scattering and/or lack of documentation in 
FB 5 and FBtoC is that FBtoC was originally developed as a 
stand-alone application. FBtoC was created to allow code generated by 
the FB 4 Editor to be compiled as a Universal Binary using OS X's 
built-in Unix compiler gcc. This is the same compiler used by Xcode. 
(FutureBASIC 4 had its own built-in compiler that was excellent but 
was limited to legacy binaries used on the 68K and PPC platforms.)

However, as work on FBtoC progressed and Staz Software released FB as 
freeware, the FB 4 Editor was rewritten and improved by a group of 
dedicated volunteers-- all of whom are members of this list and who 
make themselves available to help with questions and problems. They 
have also been extremely quick to make improvements to both FB 5.x 
and FBtoC as suggested on this list.

The result has been that even though FB 5.x and FBtoC remain separate 
applications, they are so well integrated that we the users tend to 
think of them as a single unit. Theoretically a programmer could 
write code in any text editor-- in fact many of us do rough work in 
TextWrangler-- and compile it in FBtoC. But with the advances in the 
FB 5 Editor, we mostly prefer that environment for most programming. 
The downside of this is that the rate of development on FB and FBtoC 
has left the documentation in its wake.

Part of the dilemma is that, to be frank, FB is an extremely small 
community compared with, let's say, the Xcode fraternity. Most of the 
coders here think in terms of event-loop programming as opposed to 
Object Oriented Programming (OOP) used in Cocoa and Objective-C. At 
the same time, many of us have no problem coding in C or Objective-C 
and have no problem firing up Xcode or Interface builder. Because 
many of us are more advanced programmers, our focus has not 
necessarily been with documentation. If there is any one thing that 
hurts FB more than anything else, it is sparse documentation, 
especially for newcomers.

But in the end, FB is our native language-- one we love and 
appreciate. And we have one thing that is not available anywhere 
else: This list, a community of bright, courteous, respectful and 
helpful programmers along with a dedicated handful who have worked 
diligently as volunteers for sheer love of the language to bring FB 
to what is today.

Since FB (henceforth I will use that expression to refer to the 
FB/FBtoC package) uses the same compiler engine as Xcode, we not only 
have the capability of programming in BASIC, but have the added 
luxury of incorporating C, C++ or Objective-C code in our programs.

In an earlier post you mentioned BlitzMax. From a quick look at it, 
it appears to be a very nice cross-platform application for BASIC 
applications. In the few minutes I spent with it, I had no problem 
translating its code into FB BASIC. However, FB allows a user to 
compile anything from 1964 BASIC spaghetti code to Objective-C 
Universal Binaries, from an elementary "Hello World!" to a polished 
commercial application.

If FB were a car, it would definitely be what we here in the States 
call a "sleeper." On the outside it may look like any of host of 
garden-variety BASIC dialects, but it's the engine under the hood 
(bonnet) that counts.

FB has a huge engine that takes a very good driver to fully 
appreciate and handle.

Glad to see you behind the wheel.