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

Tue Feb 28 01:31:24 PST 2012

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.

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

> 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