After the discussion on menus has sort-of ended in a solid stalemate, there's something we need to clear up anyway before moving further: How to actually bring those menus to life in the first place. There's already quite a bit that can be done using objects, but I feel by defining a new interface we could more easily integrate new features (especially ones that aren't tied to synchronicity!).

Looking through the various suggestions, we need to be able to at least do the following:
* Placement both relative to objects as well as absolute
* Rules for solving collisions (could theoretically be done in script, not sure)
* Visibility rules for players
* Colored boxes
* Colored lines
* Draw object icons in various sizes
* Draw text
* Draw graphics, with color
* Provide (asynchronous) reactions on mouse-over
* Provide (synchronous/asynchronous) reactions on mouse click

So here's a few examples. Normally, you would obviously wrap these examples with even more helper functions:

message = GUI_Text() {
  placement = Place_Object(this, Align_AboveCenter),
  collide = Collide_GoUp(MessagePriority),
  width = 200, height = 200,
  text = "This text should show above the object!"
};
ShowGUI(message);
[...]
HideGUI(message);

Going through it:
* The "GUI_Text() {..}" syntax should here construct a new proplist, with "GUI_Text()" as the prototype. Do we already have something like that? I feel it would be very natural. Influences see Haskell, Java, or even Torque Script.
* Place_Object(this, Align_AboveCenter) -> placement relative to a game object. HUDs could use Place_Screen(Align_BottomCenter).
* Collide_GoUp(MessagePriority) -> defines how the element position is to be changed if another element (say, another message) collides. Here we say to go up until a good place can be found. Note that we can set priorities.
* width = 200, height = 200 -> static sizing for now. For text it would obviously be a good idea to have something like "auto" here, but that opens another can of worms.
* text = "This text should show above the object!" -> straightforward enough. Should be word-wrapped and clipped according to box

Okay. Let's define a simple menu:

menu = GUI_Box() {
  placement = Place_Object(this, Align_BelowCenter),
  collide = Collide_GoDown(MenuPriority(this)),
  width = 40, height = 20,
  color = RGBa(0,0,0,50),
  children = [
    GUI_Image() {
      x=2, y=2, width=16, height=16,
      id = GetID(this)
    },
    GUI_Box() {
      x=22, y=2, width=16, height=16,
      children=[MakeMenuIcon(Contents())]
    }
  ]
}

* color = RGBa(0,0,0,50) -> Simply coloring the output, could work for almost all GUI elements. Another possibility would be to have different "fill" styles.
* children -> Allows you to place other elements relative to the given element (see below). Also might inherit a few properties, e.g. visibility.
* GUI_Image -> Here used to show the icon of an object definition. Should probably be made general enough to show arbitrary stuff from Graphics.png and/or object graphics. Longest shot: Take ActMap structure to specify animation
* x=2, y=2 -> No placement given, which then defaults to Place_Inherit(Align_TopLeft), meaning that the coordinates given refer to the coordinates of the top-left corner relative to the top-left corner of the containing box.
* GUI_Box() -> Used without color, therefore just defines a box that contained elements might inherit their positions from.

Let's turn to the menu item:

func MakeMenuIcon(object obj, int wdt, int hgt) {
  var mouseOverTag = Format("MouseOver%d", ObjectNumber(obj));
  return GUI_Box() {
    width=wdt, height=hgt,
    color = { (mouseOverTag) = RGBa(255,0,0,50) },
    onMouseEnter = React_SetTag(mouseOverTag),
                onMouseLeave = React_UnsetTag(mouseOverTag),
    onMouseClick = React_Call(this, "MenuItemSelected", obj),
    children = [ GUI_Image() { id = GetID(obj) } ]
  };
}

Okay, here it's getting interesting:
* mouseOverTag -> This is a tag, which defines a state of the GUI. The identifier should be as unique as possible - the way it is done here is relatively crude, real implementation should take more care.
* color = { (mouseOverTag) = RGBa(255,0,0,50) } -> A tag-specific property. Using another bit of not-yet implemented syntax, we construct a proplist that lists the value for each tag where we want the property to actually be set.
* onMouseEnter = React_SetTag(mouseOverTag) -> This is where the tag gets its live. Once the mouse enters the box, the tag gets set and the color of the box should change. The good part here: This doesn't need to be synchronized at all, therefore we have instant reaction!
* onMouseClick = React_Call(this, "MenuItemSelected", obj) -> Another reaction, this time a script call. This will obviously have to go over the control queue in order to be synchronized.
* children = [ GUI_Image() { id = GetID(obj) } ] -> Not sure, but here it would be convenient if it defaulted to inherit wdt and hgt from the container.

Finally a sketch how drag&drop could work. The idea would be to have the following code:
[...]
    dragClass = "ContentsItem",
    dragData = [ this, obj ]
    dragGraphic = [ GUI_Image() { id = GetID(obj) } ],
    nodragGraphic = [ GUI_Image() { id = NoDropPossible } ],
[...]
    dropClass = "ContentsItem",
    onDrop = React_Call(this, "OnMenuItemDropped")
[...]

Which means that the engine would draw "dragGraphic" whenever the mouse drags over a GUI element which has a matching "dropClass", and "nodragGraphic" if there's a mismatch. Once dropped over a matching drop region, the callback is issued - here giving as parameters "this" and "obj" from the viewpoint of the object that created the menu.

Future work:
* adaptive layouts that grow/shrink dynamically (necessary once we get larger amounts of text in there, which might have different size across translations!)
* scrolling
* animations

Thoughts?

This is WIP btw!