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

[James Paige]

On Tue, Feb 28, 2012 at 03:04:22PM -0800, James Paige wrote:
> On Wed, Feb 29, 2012 at 11:55:43AM +1300, Ralph Versteegen wrote:
> > On 29 February 2012 04:10, James Paige <Bob at hamsterrepublic.com> wrote:
> > > On Tue, Feb 28, 2012 at 10:31:24PM +1300, Ralph Versteegen wrote:
> > >> On 28 February 2012 08:59, Jay Tennant <hierandel8 at crazyleafgames.com> wrote:
> > >> >> From: James Paige <Bob at HamsterRepublic.com>
> > >> >> Sent: Monday, February 27, 2012 10:07 AM
> > >> >>
> > >> >> On Tue, Feb 28, 2012 at 12:43:33AM +1300, Ralph Versteegen wrote:
> > >> >> > 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.
> > >> >
> > >> > Hmm. I'll have to look into bitfields then.
> > >> >
> > >> >> > >> >
> > >> >> > >> > 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.
> > >> >>
> > >> >> Allowing people to write plug-ins for editors in custom is not the smae
> > >> >> thing as using editor widgets in game.
> > >> >
> > >> > Oops. I said "custom" panels, but I should have said "customized" panels.
> > >> > Allowing plugins sounds neat, but I was thinking of customized panels to
> > >> > display inventory, or a hud, etc.
> > >> >
> > >> >> If gui widgets are to be exposed to plotscripting, I think it would have
> > >> >> to be via slices. For example, adding new slices for TextWidgetSlice or
> > >> >> ButtonWidgetSlice.
> > >> >>
> > >> >> > Another possibility would be rewriting editors totally in HS, which
> > >> >> > would allow easily "porting" them, say to a rewrite of Custom in
> > >> >> > Python.
> > >> >>
> > >> >> I must admit that idea makes me frown. Porting to python would be no
> > >> >> justification for having to go through the pain and suffering of porting
> > >> >> editors to HS. Maybe I will feel differently about this once HS has more
> > >> >> language features, but right now the idea makes me shiver.
> > >> >>
> > >> >> > 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.
> > >> >
> > >> > Oh, I didn't intend on porting to the language. I am adapting the GUI
> > >> > framework to the engine. I don't want to exclude anyone either. Once I'm
> > >> > finished with this, it an be ported to whatever language, or left alone.
> > >> > I don't plan on modifying the language of any other part of the engine.
> > >> >
> > >> >> > 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?
> > >> >
> > >> > Hmm, intriguing. Now looking at slices.bi, the structure contains most
> > >> > of the information needed by the GUI manager. I think I'd like to use
> > >> > the slice tree more than I initially planned.
> > >> >
> > >> > Perhaps the functions used would include:
> > >> > NewSlice
> > >> > DeleteSlice
> > >> > DrawSlice (or SliceDraw?)
> > >> > OrphanSlice
> > >> > SetSliceParent
> > >> > InsertSliceBefore
> > >> > SwapSiblingSlices
> > >> > LookupSlice
> > >> > FindSliceAtPoint
> > >> >
> > >> > The information needed from slices include:
> > >> > Parent
> > >> > FirstChild
> > >> > NextSibling
> > >> > PrevSibling
> > >> > NumChildren
> > >> > X
> > >> > Y
> > >> > ScreenX
> > >> > ScreenY
> > >> > Width
> > >> > Height
> > >> > Visible
> > >> > Mobile
> > >> > Clip
> > >>
> > >> Mobile doesn't do what you think it does: in fact it does nothing. I'm
> > >> not sure what James intended it for, maybe a "pause slice movement"
> > >> command.
> > >
> > > My memory on that topic is fuzzy-- but I think I was planning a feature
> > > that allowed you to give velocity to slices and then have them move
> > > automatically-- but I decided the feature was not well-thought-out and I
> > > abandoned it. I guess I forgot to remove Mobile.
> > 
> > Your memory is very fuzzy indeed: you didn't abandon it; it's finished :)
> 
> Oh! Haha! So I did. I even used the feature in Wandering Hamster :)
> It was pleasant to work with, and I was happy with it!
> 
> When I finally lose my mind completely, I hope y'all come visit me in 
> the rest home once in a while ;)

So, Jay! To answer your earlier question, Mobile is a boolean which I 
had intended to use to check whether or not a slice's x and y velocity 
should be used. However, I ended up leaving Mobile enabled all the time. 
it never gets turned off. I should really remove the Mobile member of 
the Slice object completely, since it does nothing.

I am not sure what you had in mind for widget animation features, but 
do the Velocity or Targ seeking already accomplish what you were 
thinking of?

---
James