Developers:
==========

Why does the generated Python code set thisown=0?
Without it, windows that popped up off the main window that contained
Tabs caused segmentation faults the second time they were activated.
I think Python was deleting the shadow class, and with thisown=1 the underlying
FLTK object was also deleted, but somewhere else in FLTK there was still a pointer.  See bugs/TabGroup off the main directory for a demonstration of the original problem.


How it Works:
-------------
For writing new code generators, you really only care about
the output from FlParseTreeConverter::getFunctionDefs(). It
is a list of function definitions.  Each function definition is
a dictionary.  See the file: hello.output for more details.

The whole process works like this:

<raw fluid data file>
      |
      V
FlPreProcessor::tokenize
FlPreProcessor::getvalue
      |
      V
<string containing the fluid file with multi-word label/code defs 
wrapped in quotes>
      |
      V
FlScanner::tokenize
      |
      V
<list of token (type [,value]) tuples>
      |
      V
FlParser::parse
      |
      V
<AST parse tree>
      |
      V
FlParseTreeConverter::getFunctionDefs
      |
      V
<list of Python dictionaries containing function definitions>
      |
      V
CodePy.write
      |
      V
<Python source code>



To add new types of class options:
----------------------------------
1) Add regex to FlScanner::keywordRegex that matches the option.
   This will prevent the new type from being called an identifier
2) Add to the BNF in FlParser.  Must add a line of classOpts1 ::= <new opt def>
   and a line <new opt def> ::= <new opt>.  See stepDef for a good example.
3) Add to the code generator.  For Python, it is Code_py::binaryOptionSet.
   This is a list of tuples.  The first element is the name of the option def,
   the second is the string of code that implements this option. 

That should be it!



Input Parameters to Functions:
-----------------------------
C/C++ allows just a type without a name -> ie:  (int, int) vs 
(int x, int y).  It's better style to use the latter form.

Python function input parameters are not typed, so it looks like: (x, y).
Given that fltk is C++, function parameters are parsed assuming a single
identifier is a parameter type. If the function is defined as it would
be in python, this means the parameter name is in the first string, as in 
'ptr' in the following:

	in C++:    void func(char *ptr) {....
    inputParams = [['char *', 'ptr']]

	in C++:    void func(char *) {....
    inputParams = [['char *', '']]

	in Python: def func(ptr):
    inputParams = [['ptr', '']]


   inputParams = [['char *', 'test'], ['int', 'tp']]
   inputParams = [['int', ''], ['int', '']]




