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

[James Paige]

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

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

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.

(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