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

Tue Feb 28 15:04:22 PST 2012

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 ;)

> >> > 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.
> >
> > I like this and I think such functions could come in handy.
> > One reason is that they provide centralized places to do validity
> > checking on the Slice ptr.
> >
> >> > 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.
> >>
> >> FB does not yet support polymorphism in a stable release, but it's
> >> been available in an SVN branch for a long time.
> >>
> >> > 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.
> >>
> >> >> 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
> >>
> > _______________________________________________
> > Ohrrpgce mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> 