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

[Ralph Versteegen]

On 27 February 2012 10:14, Jay Tennant <hierandel8 at crazyleafgames.com> wrote:
>> 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

//following could be combined to a bitwise OR'ed DWORD

You could use bitfields! My favourite little-used feature of C89. Even
FB supports them, amazingly. Proving that FB really is just a C clone
in disguise.

>> >
>> > 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've had this "weird idea" too. For example, allowing people to write
plug-ins for the map editor such as for map generators or automatic
adjacent tile matching. That sort of plugin support is quite common in
other map editors.

Another possibility would be rewriting editors totally in HS, which
would allow easily "porting" them, say to a rewrite of Custom in
Python.

But yes, these weird ideas are definitely "not right now".

>> > 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!

slices.bi

I thought we were going to rewrite or port the whole GUI framework to
FB, rather than using this code directly. Partially because I've never
seen James touch a line of C, but I definitely don't want to exclude
him. Partially to make sure the result is just what we need. I still
want to (re)write all the controls in FB, but however now I'm not sure
that I will be bothered rewriting everything in FB, due to FB's
horrible data structures.

Notice that nothing in the Slice struct is encapsulated by an API.
Copying/porting the struct definition to C sounds like a bad idea
since it's quite large and changes fairly frequently, and FB and a C
compiler might differ on the layout. There are functions for
reparenting and SliceCollidePoint for hit-testing. What else would be
need aside from functions to return the FirstChild, NextChild members?

>> ---
>> James