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

Mon Feb 27 23:07:55 PST 2012

On 28 February 2012 05:07, James Paige <Bob at hamsterrepublic.com> wrote:
> 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.

Yes, widgets will basically be slices with a little extra data. Though
I've been contemplating whether having just two new slices types would
work: SelectableSlices for things to which you can select with the
arrow keys, and WidgetSlices for everything else. Or not.

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

Heh! The idea of writing things like that in FB sounds like pain and
suffering to me! That's why I fantasise about using some pleasant
scripting language instead, like hopefully HS in some far-off future
utopia :)

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