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

[Jay Tennant]

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

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

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

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.