Some thoughts on coding up layout.

* Resource compiler (rsc/source/*)
	+ rscdep - dependencies ?
	+ rscpp - pre-processor ?
	+ rsc2 - real compile

* Resource reader (tools/source/rc/resmgr)

* Current design:

	+ Hierarchical information
		+ None in the resource file
		+ None in the code

	+ Window construction
		+ can pass ResId for toplevel win, but
		  doesn't have to [ only bother fixing up
		  people using ResIds ].
		+ children instantiated, associated with
		  Window parent (and a ResId).

	+ Resource load (Window -> is a Resource) [ tools/inc/rc.h ]
		+ Window::ImplInitRes( rResId )
			+ GetRes( rResId )
		+ Whole resource load process done via cursor
		  state on GetResManager(); 
		+ ResManager has an Init/PopContext stack
		  
		

* Hacking

	+ Hierarchical information
		+ Add it to the resource format - tied to
		  Window - do we currently have a list of
		  children even ? [ or is it totally abstract e

	+ Window creation
		+ walk hierarchical information
		+ build a set of layout / peers
		+ associate these at Window::ImplLoadRes time
		+ post-association / on Window show => doLayout first.

* Demo

	+ svtools/workben (svdem): hack here ... ?

* Suggested Format:

#define DLG_TEST   1001
#define BTN_OK     1002
#define BTN_CANCEL 1003
#define DLG_TEST_LAYOUT   1100

ModalDialog DLG_TEST
{
        OutputSize = TRUE ;
        Moveable = TRUE ;
        Closeable = TRUE ;
        Sizeable = TRUE;
        LayoutId = DLG_TEST_LAYOUT;

        PushButton BTN_OK
        {
                Text = "OK";
        };
        PushButton BTN_CANCEL

        {
                Text = "Cancel";
        };

        Layout DLG_TEST_LAYOUT {
                Homogeneous = False;
                Layout {
                        PeerId = BTN_OK;
                        Expand = True;
                        Fill = True;
                };
                Layout {
                        PeerId = BTN_CANCEL;
                        Expand = False;
                        Fill = False;
                };
        };
};


* Glade2 XML format:

	  <child>
	    <widget class="GtkHBox" id="hbox4">
	      <property name="visible">True</property>
	      <property name="homogeneous">False</property>
	      <property name="spacing">0</property>

	      <child>
		<widget class="GtkVBox" id="vbox1">
		  <property name="visible">True</property>
		  <property name="homogeneous">False</property>
		  <property name="spacing">6</property>

		  <child>
		    <widget class="GtkCheckButton" id="enable_toggle">
		      <property name="visible">True</property>
		      <property name="can_focus">True</property>
		      <property name="label" translatable="yes">E_nable sound server startup</property>
		      <property name="use_underline">True</property>
		      <property name="relief">GTK_RELIEF_NORMAL</property>
		      <property name="active">False</property>
		      <property name="inconsistent">False</property>
		      <property name="draw_indicator">True</property>
		      <signal name="toggled" handler="enable_toggled_cb"/>
		    </widget>
		    <packing>
		      <property name="padding">0</property>
		      <property name="expand">False</property>
		      <property name="fill">False</property>
		    </packing>
		  </child>
		  ...
		</widget>
	      </child>
	    </widget>
	  </child>
	  etc.

		
* Resource compiler class hierarachy:

# BiNode
    * NameNode
          o IdNode
                + RefNode
                      # RscTop
                            * RscArray
                                  o RscClassArray
                                  o RscLangArray
                            * RscBaseCont
                                  o RscContWriteSrc
                                        + RscCont
                                        + RscContExtraData
                            * RscClass
                                  o RscMgr
                                  o RscSysDepend
                                        + RscFirstSysDepend
                                  o RscTupel
                            * RscClient
                            * RscConst
                                  o RscEnum
                                  o RscFlag
                            * RscIdRange
                            * RscLongRange
                                  o RscLongEnumRange
                            * RscRange
                                  o RscBool
                                  o RscBreakRange
                            * RscString
                + RscInstNode
          o StringNode
                + RscDefine


	+ despite all the .cxx, .hxx etc. stuff it seems to
	  compile direct .src -> .rc with no intermediates.
	+ Post parsing we call WriteRc on the nodes,
	+ We can also call WriteSrc - presumably a legacy
	  from the src -> representation / fiddle / -> src 
	  round-trip process.
	+ RscCont is a generic container class.
	+ code hidden in rsc/source/prj/gui.cxx flow:
		rscyacc.y:
			+ everything built into a RscTypeCont *pTC.
			+ all strings munged into HashString: pHS
			+ pHS->Get( HASHID ) returns it to a string.
		RscTypeCont -> RscTypCont::Init - sets up parser.
		RscCompiler (pTypeCont)->Start.
			+ CheckSyntax -> ParseOneFile -> parser -> yyparse
			  -> DoClassHeader (rscyacc.cxx) -> GetElement (rsctop.cxx)

	+ Problems
		+ each RscClass has to define it's child
		    properties => we have to define all possible
		    child properties in advance for 'Widget')

* VCL Issues

	+ Flow:
		+ Res -> Window -> [ constr. Layout tree ]
	+ We need to associate instances of widgets later;
		+ They do ImplInitRes - and we need to connect them
		  and queue re-draws on the parent etc.
		+ Have a hash of Layout <-> ResId mappings on Window ...
		+ re-flow on re-size etc. 'queue_redraw' ?

	+ Layout -> Widget [ via. Layout tree & peers, toplevel is always a peer ]

	+ Window <-> Layout in all cases ? [ show / hide ? ]
	  cache 'visible' state ? etc. have a Layout ptr. on each
	  Window ...
	+ Need a factory for Layouts ...
	+ We only need to virtualize sizeAllocate on the Layouts,
	  not the widgets - thank goodness.

** Decisions
	+ Totally static layout manipulation
		- ie. no self-building - too complex anyway.
