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

[Jay Tennant]

> From: Ralph Versteegen <teeemcee at gmail.com>
> Sent: Tuesday, February 28, 2012 3:32 AM
> 
> 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.

Hmm. James, what was the intent? Because I may have a use for it,
though I'm not sure. I was thinking animation (like a pull-down menu).

> > With concern to the dynamic nature of the slice code, could we just
> > add accessor and mutator functions for each of those members? I
> > wouldn't mind if the slice pointer was typedef'd as a void* in C.
> > sliceGetParent( s as Slice ptr ) as Slice ptr
> > sliceGetFirstChild( s as Slice ptr ) as Slice ptr
> > sliceGetNextSibling( s as Slice ptr ) as Slice ptr
> > sliceGetPrevSibling( s as Slice ptr ) as Slice ptr
> > sliceGetNumChildren( s as Slice ptr ) as integer
> > sliceGetX( s as Slice ptr ) as integer
> > sliceGetY( s as Slice ptr ) as integer
> > sliceGetScreenX( s as Slice ptr ) as integer
> > sliceGetScreenY( s as Slice ptr ) as integer
> > sliceGetWidth( s as Slice ptr ) as integer
> > sliceGetHeight( s as Slice ptr ) as integer
> > sliceIsVisible( s as Slice ptr ) as integer
> > sliceIsMobile( s as Slice ptr ) as integer
> > sliceIsClipping( s as Slice ptr ) as integer
> >
> > sliceSetX( x as integer, s as Slice ptr )
> > sliceSetY( y as integer, s as Slice ptr )
> > sliceSetWidth( w as integer, s as Slice ptr )
> > sliceSetHeight( h as integer, s as Slice ptr )
> > sliceSetVisibility( b as integer )
> > sliceSetMobility( b as integer )
> > sliceSetClipping( b as integer )
> 
> Sure.

Ok. I'll work with that idea.

> > Alternatively, can FB define interfaces, and support polymorphism?
> 
> In this context, I have no idea what you mean by "interface". It
> supports methods and "property" methods (a getter/setter pair which
> creates a fake member), but they are only available in the -lang fb
> dialect. James has gotten us half way to switching to lang fb.

I meant an interface as in members defined in a class:
virtual int doSomething() = 0;

and overrided in inherited classes. The base class is completely
abstract, containing no other members besides interfaces.

> FB does not yet support polymorphism in a stable release, but it's
> been available in an SVN branch for a long time.

Ah, well nevermind then.

> > Second alternative (and preferred over other two), can't we just
> > define both the FB and C++ version within the same header?
> > C++ uses some of the same compiler directives, so perhaps a check
> > could be done whether __cplusplus is defined. If not, enable the FB
> > code. Otherwise, enable the C++ code.
> 
> Haha. I never thought of that. It would work, but I think it would
> just add clutter (having to ignore the other language) without any
> benefit. We already have a soup of hundreds of files (which I know has
> put people off), another won't hurt.

Ok, and I do like the first idea where a Slice ptr is the same as a
void pointer, using accessor/mutator functions. I'll carry on that idea.

> >> I don't think C/C++ should be avoided just because of me. I know enough
> >> C/C++ to get by, and I am certainly capable of learning more.
> >>
> >> In the past I would have worried a lot about compatability between mixed
> >> modules of different languages, but it has already been proven that we
> >> can make c code and fb code play nicely together in the same build
> >> process.
> >>
> >> The only thing I would object to about using C/C++ is that I don't want
> >> to port anything to C/C++ just for the sake of porting it. If it is
> >> being ported to make it better, cool. If it is being ported as part of
> >> an organized process of cleaning up code, cool. I just don't want to
> >> port anything based on an idea that something needs to be in a
> >> particular language just for the sake of being in that language.
> >>
> >> And so for that same reason I don't think any code of language X needs
> >> to be ported to language Y unless there is a real
> >> compatability/interoperability/maintenace reason that it needs to be
> >> done.
> >
> > Agreed.
> >
> >> (That being said I don't know the first thing about how hard it is to
> >> link and interface the output of different compilers, only that I know
> >> we are already doing it)
> >>
> >> ---
> >> James