ui lua integration: update on ufox utility library

[rxadmin]

Added the ability to setup inherited controls using the table syntax. For instance, if the window inherits from "ipopup" you can reference the inherited text node by specifying a table with no class-value. The build function then assumes it is an inherited child node. For a complete example of the table syntax, see the main.ufo file wich is completely rewritten in this style.

Table syntax sample:

tree = {
    class = "window",
    name = "tipoftheday",
    super = "ipopup",

    {
        name = "title",
        width = 496,
        text = "_Tip of the day"
    },

    ...

[DarkRainX]

Thanks! I'll try to make sense of all those merges ASAP.

Also if you're going to convert files to use the ufox library you might want to check that you don't run into the caveat I just detailed in the wiki page (took me longer than it should have to figure why my translation of the inventory/stats window to lua wasn't working as expected...)

[rxadmin]

The caveat you describe is actually a bit different. In the table syntax, child nodes are specified using child tables. As long as you do not name these child tables, lua will order them the way you specify them. I encountered this situation when I started to create the following syntax:

tree = { ... child1 = { }, another_child = { } }

If you write it like this, lua can change the order in the tables. However if you omit the key values, effectively creating anonymous child tables then lua will provide a hidden key being a sequential value. This will in effect guarantee the order.

[DarkRainX]

Correct me if I'm, wrong but IIRC the official lua documentation states that the order in which pairs() (which the ufox library was using last time I checked) is not defined, not even for indexed tables, so even if it works fine in one system it will for sure misbehave for someone else out there

[rxadmin]

Yes, you are right about the documentation on pairs. However the thing is if you use an anonymous table, lua will add a key by itself. This is actually specified by the language itself, since it explicitly states that if you specify e.g. a table of only values, like this

x = { "a", "z", "w", "b", "c" }

you can index these values in the order specified. So x[0]="a", x[1]="z" and so on. The reason pairs states that it cannot guarantee the order is simply because it has no knowledge about the key values provided by you should you choose to provide key-value pairs.

[DarkRainX]

I know that lua assigns numeric keys like that, what concerns me is this in the lua reference manual:

The order in which the indices are enumerated is not specified, even for numeric indices. (To traverse a table in numeric order, use a numerical for or the ipairs function.)

It seems to me that ignoring that is just asking for trouble, unless I'm seriously misunderstanding things here.

Anyway, I've rebased this PR on top of master, if it's ready I could apply it now.

[rxadmin]

It's ready for PR. On a side-track, I'm going to look into the 'undefined order' issue. In the meantime I'm anxious to see if anyone actually reports a mismatch in the order of ui elements and on what platform. Since it affects the main screen, if it happens, I'm sure we'll here from it.

[DarkRainX]

Merged now, as always please close this once you have no need for it as I have no right on github

Also due to the rebase to remove merge commits you should expect merge conflicts, maybe you could create a new branch for each PR to make things easier for you (that way you only need to delete the PR branch, and update master, which you can branch again for the next PR)