[Ohrrpgce] SVN: jay/5073 gui*: cleaning up GuiManager and the GUI_MESSAGES

[Ralph Versteegen]

On 24 February 2012 21:38, Jay Tennant <hierandel8 at crazyleafgames.com> wrote:
>> From: Ralph Versteegen <teeemcee at gmail.com>
>> Sent: Thursday, February 23, 2012 9:09 PM
>>
>> On 24 February 2012 07:24,  <subversion at hamsterrepublic.com> wrote:
>> > jay
>> > 2012-02-23 10:24:36 -0800 (Thu, 23 Feb 2012)
>> > 49
>> > gui*: cleaning up GuiManager and the GUI_MESSAGES
>> > ---
>> > U   wip/gui.cpp
>> > U   wip/gui.h
>> > U   wip/guiBase.cpp
>> > U   wip/guiBase.h
>>
>> I know that it's probably too early to have a close look since you're
>> still busy on it, but I did it anyway, so here are some comments.
>
> Well, I'm glad there's interest in its development. :)
>
>> It's (currently) a lot of code, mostly because you were implementing
>> everything from scratch, but partially I had forgotten just how much
>> logic a GUI framework would contain. The later isn't a bad thing:
>> it'll hopefully save a lot of code elsewhere.
>>
>> Object factory classes don't seem useful, and tracking the factories
>> of objects isn't actually used anywhere. Much simpler to just let the
>> object constructors handle everything, passing in a pointer to the
>> GuiManager. That removes lots of code.
>
> I can almost agree with the object factory classes. The use cases I
> had were sharing video memory resources among all objects of the
> same type, or built from the same factory. If there's not a predictable
> usage of said feature, than it's simply another layer of abstraction,
> and probably can be discarded.
>
> The factory tracking was so that the objects could be removed from
> said factories upon their destruction. This was just one way of
> providing the releasing mechanism of the factory references.
>
>> I would just delete guiText.*.
>
> Hehe, I imagined it wouldn't be too useful here. It could convert
> a string into a bunch of character regions with different
> properties. For example, I was able to demonstrate different horizontal
> alignments for each line of text, changing colors, and changing
> font sizes for each letter in a line. You can see the parse routine
> checking for "<COLOR=*>" and "</COLOR>", etc.
>
> But I forgot the engine already does most of that, with different
> character codes. Regardless, it's way too much work to fix this
> control into a usable control for the engine.

Oh wow, I didn't realise that it did all of that. As it just so
happens that I'm working on the OHR's text rendering code today, I was
quite interested and just read through all of CGuiText, and I'm quite
impressed how much cleaner your code is than mine! Took me only a few
minutes to read through and understand all 1000 lines, whereas I can't
even understand parts of my own, massively denser, 650 lines of code!
The difference is striking.

The OHR's render_text doesn't support alignment, but it's massively
complicated by features like 2-layer fonts (where all of the bottom
layer is drawn before all of the top layer (why on earth didn't I just
draw to two different buffers or call render_text twice?)). Since this
is performance critical code (the framerate plummets on drawing a full
screen of text if every character is preceded by a colour code), I
might have to rewrite part of it in C/C++ anyway.

>> Switching to slices really will simplify CGuiObject.
>
> I still don't know how it will, but I'm not concerned with that. I'm
> actually going to get rid of CGuiObject, and the virtually overridden
> GuiObject structure for that matter. Instead, GuiObject would contain
> a bunch of state, with a function pointer to either C++ or FB.

Sounds good.

>> Seeing all this low level stuff, I thought some more about the
>> abstraction of other GUI systems. Having a (low level) abstraction
>> layer seems to make the idea somewhat useless, since there's no hope
>> of mapping between the abstraction and the low level details of some
>> framework. I think that if we did abstraction, it would have to be at
>> a much higher level where the GUI manager handles everything and
>> there's no other framework-specific code anywhere else in the engine.
>> (Even then, it doesn't seem worth much effort). And we wouldn't be
>> passing creation and destruction and hittest messages to widgets, the
>> framework would do all of that itself. So plumbing details
>> (GUI_CREATE?) which are useless to the engine have no purpose and
>> should be removed.
>
> I don't know how low level this is, but with the planned removal of
> factories and the simplification of GuiObject, it seems like a
> regular GUI system (well, a lot simpler than Windows). The manager is
> still handling all the ugly focus transitions, input funneling, and
> object creation/destruction, so it still relieves a lot of the work.
>
> The GUI_CREATE is necessary. That is the first message called on the
> object, allowing the object to allocate resources, create child
> objects, etc. I really can't imagine not having it.

Well, the alternative would be to do all the intialisation in the
object constructor, to which you can freely add more arguments.

> I think I understand the statement about hittest--certain messages
> should be trimmed out of the gui.h. They would still be implemented
> by a default handler, but specialized widgets wouldn't be able to
> override them. Some others include "GUI_IS_MOVABLE_BY_MOUSE",
> "GUI_GET_CHILD", "GUI_GET_ZORDER", etc. However, GUI_CREATE and
> GUI_DESTROY should remain there so those messages can be caught
> in custom procedures.

Yes, I doubt we'll have any use for overriding hittesting. Movable by
mouse sounds useful, but that can become a simple bool.