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

Mon Feb 27 11:59:37 PST 2012

> 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

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 )

Alternatively, can FB define interfaces, and support polymorphism?

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.

> 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
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org 