[Ohrrpgce] SVN: jay/5076 gui*: generalizing. Not factory factory factory...

[Jay Tennant]

> From: James Paige <Bob at HamsterRepublic.com>
> Sent: Sunday, February 26, 2012 11:06 AM
> 
> On Sun, Feb 26, 2012 at 07:27:03AM -0800, Jay Tennant wrote:
> > > From: subversion at HamsterRepublic.com
> > > Sent: Sunday, February 26, 2012 9:20 AM
> > > 
> > > jay
> > > 2012-02-26 07:20:03 -0800 (Sun, 26 Feb 2012)
> > > 331
> > > gui*: generalizing. Not factory factory factory...
> > > 
> > > Restructuring the system to follow Window's design a little more closely, namely using a registration system and extra data associated with "GuiClass's", and the GuiClass instance extra data.
> > > 
> > > Added GuiObjectState to retrieve pertinent render state about a particular GUI object.
> > > ---
> > > U   wip/gui.h
> > > U   wip/guiBase.h
> > 
> > The goal is making this easier to construct GUI objects in plotscripts.
> 
> Wait... I am confused again. Why would there be a direct plotscripting 
> interface for this? I thought the purpose of this gui code was low level 
> stuff to use for custom?

Yes, the purpose is for custom, but I started getting weird ideas again
about allowing users to create their own custom panels through plotscripts.
Possibly a completely bad idea. But, honestly, structuring this way is
a lot easier for me to keep track of. I've done so much Window's programming
that it feels second nature to structure a framework thusly. On the downside,
I had to actively fight against the urge to write the structure and class 
names in all caps. ;)

So should it be accessible for plotscripting? Not right now, possibly
not at all. But adding the ability won't require a restructured
framework.

> > I don't really know how the slice tree is adjusted whenever a node must
> > be manipulated/moved to another location in the tree. I was considering
> > just letting the GUI manager keep a tree, and allow that to be readable
> > through the functions guiGetChildCount() and guiGetChildByIndex().
> 
> Slice tree nodes are moved to other places in the tree by reparenting. 
> They can also be reordered relative to their simblings with commands 
> like "slice to front" "slice to back" "move slice above" "move slice 
> below" or by sorting a group of slice siblings.

Perfect. That addresses the needs completely. I can now understand much
more clearly how the GUI manager will work with the slice tree.

Can you refer me to all specific functions for slice tree manipulation?
(At least, to the file?) Thanks!

> ---
> James