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

Tue Feb 28 14:55:43 PST 2012

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

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