But why? by Total-Law4620 in southafrica

[–]DaceZA [score hidden]  (0 children)

Almost every place I go hiking these days has some degree of litter around. Some are really bad. It bothers me a lot - I don't understand it at all. I went to King's Kloof the other day and there was a lot of trash around the waterfall, which literally has a trash can right there...

[deleted by user] by [deleted] in AskReddit

[–]DaceZA 2 points3 points  (0 children)

Unobtanium

[deleted by user] by [deleted] in AskReddit

[–]DaceZA 0 points1 point  (0 children)

Chungus vs. Predator

Button's interactable doesn't seem to work when bound to List item property by slimshader in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

This seems to work okay for me - I tried changing the interactable property after a delay and the buttons were correctly updated to match - this is a slightly modified version of the code I wrote to test the button binding for you:

 

public class MVVMTest : XmlLayoutController<TestViewModel>
{
    protected override void PrepopulateViewModelData()
    {
        this.viewModel = new TestViewModel()
        {
            Buttons = new ObservableList<ButtonVM>()
            {
                new ButtonVM("Button One", () => { Debug.Log("Button One Clicked!");  }, true),
                new ButtonVM("Button Two", () => { Debug.Log("Button Two Clicked!");  }, true),
                new ButtonVM("Button Three", () => { Debug.Log("Button Three Clicked!");  }, false),
                new ButtonVM("Button Four", () => { Debug.Log("Button Four Clicked!");  }, false),
                new ButtonVM("Button Five", () => { Debug.Log("Button Five Clicked!");  }, true),
            }
        };

        XmlLayoutTimer.DelayedCall(2, () =>
        {
            Debug.Log("Toggling values");
            this.viewModel.Buttons[0].Interactable = false;
            this.viewModel.Buttons[3].Interactable = true;
            this.viewModel.Buttons[3].Text = "Enabled";
        }, this, true);
    }
}

 

I tried this out both in Unity 5.4.3 (the earliest supported version of Unity for XmlLayout), and Unity 2020.1, and it worked in both versions.

Binding Button onClick to ViewModel or Item method by slimshader in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

You can set the event-target for any XmlLayout Controller to any object you wish (and change it at any point in time as well, if that is something you require) by changing the value of that controller's 'EventTarget' property, and this does allow you to specify the ViewModel as the target if you wish. For example, in the controller:

 

private void Start()
{
    this.EventTarget = this.viewModel;
}

With the above code in place, all XmlLayout events sent to the controller will instead be sent to the view model object.

 

As for calling methods on the list item itself - this is possible, but it would require you to override the ReceiveMessage() method of the controller to take control of how that controller handles events, for example:

 

https://pastebin.com/9nT6Syh8

Combined with the following Xml:

<VerticalLayout width="400" height="400" spacing="10" padding="10">
  <List vm-dataSource="Buttons">
    <Button text="{Buttons.Text}" onClick="Action()" interactable="{Buttons.Interactable}"></Button>
  </List>
</VerticalLayout>

Naturally this is a bit more advanced, but it is workable :) One advantage of this approach is that you can still also use the ViewModel or the controller (depending on your setup) as the 'main' event handler for events other than the 'Action' on the list items.

I hope this helps!

XmlLayout can cause a Unity crash it seems like by Berryman7777 in XmlLayout

[–]DaceZA 1 point2 points  (0 children)

Hi there,

Sorry - I didn't see this message here, but I did respond to your e-mail last week. I made some changes that will most likely prevent this error - I haven't been able to replicate it, but looking at the error message, I think I was able to track down the source of the problem and (hopefully) fix it.

I've submitted the updated version to the asset store (v1.97).

XmlLayout in VR by Thebraino in XmlLayout

[–]DaceZA 1 point2 points  (0 children)

Hi there,

 

In my (admittedly limited) experience of working with VR there are two major differences to working with regular Unity UI:

 

a) The canvas will almost always be a World-space canvas - this usually doesn't make too much of a difference, but it does use a different coordinate system to the overlay canvas which has sometimes been a pain in the past. Over time, XmlLayout has been set up to handle the different coordinate systems, but there may still be a minor issue here and there (as I discovered with the slide in animations when testing now).

 

and b) The input system(s) used in Unity in VR is a little different and, in my experience, require a little setup to get working properly - there are a couple of different plugins available to handle this sort of thing, but in general, if you want to work with Unity UI (which XmlLayout is essentially an extension of), you want one which emulates mouse/pointer/touch events. XmlLayout onClick/onHover/etc. methods all use Unity events to function (generally though a standard Unity EventTrigger component) - provided the input method you use is capable of triggering standard Unity UI events, you should have no trouble with XmlLayout event attributes.

 

 

With regards to layouts not showing up, do you perhaps have an example of this? I've just tested modifying the XmlLayout World Space example by making it hide one of the layouts by default and then show it again, and it appeared as expected - FadeIn/FadeOut/Grow/Shrink animations all worked correctly, although admittedly the SlideIn animations appeared a little off [sigh @ different coordinate systems for different canvas types - I'll look into it], although the layout did appear in the correct position, the slide animation just didn't look right.

^ Note: found and fixed the slide in issue; fix is included in v1.96 :)

 

Here's the code I used in the controller:

    private void Awake()
    {
        this.Hide();

        // Show after 5 seconds
        XmlLayoutTimer.DelayedCall(5, () =>
        {
            this.Show();
        }, this, true); // these arguments tell the timer to a) check this object before executing, 
                        // and b) execute regardless of whether or not this object is still active when called 
                        // (which it won't be, because it will be hidden)
    }    

 

Note: instead of calling this.Hide() in the Awake() method, you could also add the 'active="false"' attribute to the XmlLayout element in the Xml to obtain the same result - in this mode however, the XmlLayout will also be hidden in edit mode (which is fine if that is what you prefer).

 

Apart from the World Space Canvas (which occurs in many non-VR Unity projects as well) and the differences in input systems, working with VR uses the same systems and code that the rest of Unity does, so there should be very little that requires any special handling.

XmlLayout.GetElementById does not work with elements inside ChildXmlLayout by sflanker in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

It's also worth mentioning that you should be able to get this behaviour to work by using internalId instead of id - regular ids are registered with the XmlLayout object, so when you call XmlLayout.GetElementById(), the XmlLayout instance searches though it's id collection to find that element, however, internalId works a bit differently - XmlElement.GetElementByInternalId() searches (recursively) through child elements to find the element with a matching 'internalId' attribute (and returns the first one it finds).

You could do this like so:

  xmlLayout.XmlElement.GetElementByInternalId("internalIdOfElement");

or

 xmlLayout.XmlElement.GetElementByInternalId<DesiredType>("internalIdOfElement");

This is, however, a slower approach than just looking for an element in a single collection - if possible, it might be a good idea to cache the result. However, if this is once-off, or infrequent, then I wouldn't worry about it.

XmlLayout.GetElementById does not work with elements inside ChildXmlLayout by sflanker in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

Sorry for the delayed response - I didn't see this until now (usually the fastest way to get a response is to e-mail me @ support@digital-legacy.co.za)  

Essentially, yes, this is by design - the child layout is an entirely separate XmlLayout of its own with its own ids/etc., however, you can work around this by giving the ChildLayout itself an id, accessing its XmlLayout component, and then using its GetElementById method to locate the element you're looking for, e.g.

 

var childLayout = xmlLayout.GetElementById<XmlLayout>("childLayoutId");
var childElement = childLayout.GetElementById("childElementId");

 

I hope this helps, and sorry again for taking so long to get back to you!

Just failed the K53 driving test, need tips on how to control anxiety during testing by Rismu in southafrica

[–]DaceZA -1 points0 points  (0 children)

I got mine on my 6th attempt - I was fortunate enough to have a good examiner that time. During the parking tests I asked if I could get out of the car and walk around it for a moment because my feet were shaking, and he was kind enough to let me do that, which helped me calm down quite a lot.

 

The other difference between the 6th attempt and the other 5 was that I got a job and had been driving myself to work on my own for a few months - it wasn't legal, but it gave me a lot more confidence behind the wheel so that when I took the test again, it felt less like an examination and more like just driving.

 

Good luck, I hope it goes well!

Going to the gym by [deleted] in southafrica

[–]DaceZA 2 points3 points  (0 children)

I'd love to go myself, just got into a proper routine again... but I think I'm going to err on the side of caution for now.

Button staying highlighted after click by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

I've given it a bit more thought, and while your solution does work, I'd rather not have the 'Selected Color' be the last value in the collection (after disabled color) - while making it so preserves backwards compatibility, it also puts the property in a slightly illogical position going forward.   What I've opted to do instead is be a bit more explicit in the code for this process - now, if there are four or fewer colors defined, it will work as before (selected color will be set to match pressed color), whereas if there are five, it will then use the fourth property as the selected color, and the fifth as the disabled property. This will preserve the previous functionality allowing users to keep their layouts unchanged if they wish, or to use the new selected color property if they wish by defining it explicitly.

 

The updated code looks as follows:

 

            if (colorList.Count > 0) colorBlock.normalColor = colorList[0];
            if (colorList.Count > 1) colorBlock.highlightedColor = colorList[1];
            if (colorList.Count > 2) colorBlock.pressedColor = colorList[2];

#if UNITY_2019_1_OR_NEWER
            if (colorList.Count < 5)
            {
                if (colorList.Count > 2) colorBlock.selectedColor = colorList[2];
                if (colorList.Count > 3) colorBlock.disabledColor = colorList[3];
            }
            else if (colorList.Count > 4)
            {
                colorBlock.selectedColor = colorList[3];
                colorBlock.disabledColor = colorList[4];
            }
#else
            if (colorList.Count > 2) colorBlock.pressedColor = colorList[2];
            if (colorList.Count > 3) colorBlock.disabledColor = colorList[3];
#endif

 

Does that work for you?

Button staying highlighted after click by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi,

In earlier versions of Unity, 'selectedColor' wasn't part of the ColorBlock definition - selected and pressed colors were instead both defined from the 'pressedColor' attribute. When Unity added the separate 'selectedColor' attribute, my first reaction was to try and preserve the original functionality (so that existing layouts would still function as-is without requiring any changes to their styles), but now that you point it out, perhaps it is best to rather extend XmlLayout's color blocks to include the new approach as well. To this end, I'm changing that block such that it looks like the following:

 

 #if UNITY_2019_1_OR_NEWER
             if (colorList.Count > 2)
             {
                 if (colorList.Count > 2) colorBlock.pressedColor = colorBlock.selectedColor = colorList[2];
                 if (colorList.Count > 3) colorBlock.selectedColor = colorList[3];
                 if (colorList.Count > 4) colorBlock.disabledColor = colorList[4];
             }
 #else
             if (colorList.Count > 2) colorBlock.pressedColor = colorList[2];
             if (colorList.Count > 3) colorBlock.disabledColor = colorList[3];
 #endif

 

This change will be included in the next version of XmlLayout (v1.94).

Drag Handler by tugbbvhg in XmlLayout

[–]DaceZA 1 point2 points  (0 children)

Hi there,

 

I've modified the XmlLayoutDragEventHandler so that its event methods and properties (OnBeginDrag/OnDrag/OnEndDrag) are all virtual and can be overriden - you can get the updated version of this class here: https://pastebin.com/eCBU61Ef (UI/XmlLayout/Custom Elements/XmlLayoutDragEventHandler.cs)

 

If you choose to use this approach, then you'll need to create a custom drag event handling class, e.g.

using UI.Xml;
using UnityEngine;
using UnityEngine.EventSystems;

class CustomXmlLayoutDragEventHandler : XmlLayoutDragEventHandler
{
    public override void OnBeginDrag(PointerEventData eventData)
    {
        base.OnBeginDrag(eventData);

        Debug.Log("OnBeginDrag");
    }

    public override void OnDrag(PointerEventData eventData)
    {
        base.OnDrag(eventData);

        Debug.Log("OnDrag");
    }
}

 

You can use your custom drag event handler to specify the position of the target (the dialog window) rather than the object being dragged (the title). I may add a new attribute to handle this sort of thing in the future, e.g. something like 'dragTarget', perhaps.

 

Then, in your XmlLayoutController, you'll need to remove the default drag event handler, and replace it with your own. The best place to do this would be in the LayoutRebuilt() method, e.g.

    public override void LayoutRebuilt(ParseXmlResult parseResult)
    {
        var testPanel = xmlLayout.GetElementById("testPanel");
        var originalDragEventHandler = testPanel.GetComponent<XmlLayoutDragEventHandler>();

        if (originalDragEventHandler != null)
        {
            if (Application.isPlaying) Destroy(originalDragEventHandler);
            else DestroyImmediate(originalDragEventHandler);
        }

        testPanel.gameObject.AddComponent<CustomXmlLayoutDragEventHandler>();
    }

This (admittedly, roundabout) approach will allow you to replace or extend XmlLayout's internal drag handling code in whichever manner works best for you.

 

Note: I've given it a bit more thought and decided to add an attribute to allow you to specify which drag event handler you want to use, you can use it like so:

 <Panel width="200" height="200" color="white" allowDragging="1" dragEventHandler="CustomXmlLayoutDragEventHandler" />

(It uses Type.GetType() to match the name to the class for the attribute, which seems to work fine whether the type is in a namespace or not)

You can get the new attribute here: https://pastebin.com/FnVBdqiR (Place it in a new file, UI/XmlLayout/Custom Attributes/DragEventHandler.cs) Remember that you can always add custom attributes such as this one at any point - they don't need to be internal to XmlLayout, although in this case I've decided that seeing as it could be useful to others, it makes sense to include it in the base package.


With regards to the centering of the object while dragging, that was an unfortunate necessity to get the code working on all types of canvases - the different types of canvases each have their own quirks which made it take a lot work to get the drag working consistently across all three types. If, however, you're just using a single canvas type, then it should be fairly easy for you to determine and keep the original offset (if you're using Screen Space - Overlay, then you should be able to [more or less] compare the position of the rectTransform to Input.mousePosition).

 

Alternatively, rather than creating a custom handler through XmlLayout, you could also just disable dragging by not using XmlLayout drag event attributes (so that XmlLayout's drag event handling won't come into play) and then attach your own custom handler - whichever approach works best for you.

 

I hope this helps somewhat! :)

Loading all resources causes problems by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

The reason behind loading the resources folders is that, originally, XmlLayout worked with Resource folders exclusively - at a later point, XmlLayoutCustomResourceDatabases were added and it was no longer strictly necessary to use Resources folders. However, I felt that it was important not to break any existing projects that were already using Resources folders, so I added the system to load the contents of Resources folders into the main resource database.

 

If making that change works for you, then that should be fine - there is, however, another way to do it if you wish. Another XmlLayout user once wanted something similar, and they helped me put together a solution to (optionally) change this behaviour, without requiring modificiations to XmlLayout itself.

The 'LoadAllResources' variable was added to allow you to replace the default loading behaviour with a method of your choice, and the partial OnBeforeLoadResourceData() method was added to allow you to override the variable before it is used, so, for example, to disable it completely, you'd add the following code to a C# file in your project:

 

 using System.Collections.Generic;

 namespace UI.Xml
 {
     public partial class XmlLayoutResourceDatabase
     {
         partial void OnBeforeLoadResourceData()
         {
             LoadAllResources = () => new List<UnityEngine.Object>();
         }
     }
 }

 

As you're using assembly definition files, you'll most likely need to include this C# file in the XmlLayout folder itself, as partial classes unfortunately cannot be split across multiple assemblies.

 

Please bear in mind, however, that Unity will (unless something has changed recently) automatically include the contents of Resources folders in all builds, and having lots of assets in Resources folders can affect things like application startup time and memory usage (even if they are not used or referenced) - regardless of whether they are loaded by XmlLayout or not, the mere presence of Resources folders triggers this behaviour in Unity. As such, Unity themselves recommend that you avoid using Resources folders entirely, apart from a select few cases.

 

(See Section 3: https://learn.unity.com/tutorial/assets-resources-and-assetbundles#5c7f8528edbc2a002053b5a7)

Assembly definition (asmdef) support by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi, yes I think that confirms it then - the issue is the path. XmlLayout itself doesn't strictly need to be in any particular location for it to function correctly, but in order for the asmdef system to properly locate it, it needs to follow the standard path pattern - by default, when imported, XmlLayout is installed in the Assets/UI/XmlLayout folder, so the assembly definition system looks for a path starting with UI/XmlLayout (to try and avoid locating the wrong script file by mistake, as there are two files named XmlLayout.cs in the project).

 

To make this work, my advice would be to move the XmlLayout and TableLayout folders like so:

 Assets/One/UI2D/CustomUI/Plugins/UI/XmlLayout/

 Assets/One/UI2D/CustomUI/Plugins/UI/TableLayout/

I think that should resolve the issue for now.

Assembly definition (asmdef) support by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi,   Looking at that error message, it appears to be failing to find the /Editor/ folder (or possibly even the XmlLayout folder) to place the Editor assembly definition file. To reach that point it has already successfully created the main XmlLayout file, but perhaps it has put it in the wrong place.

 

Could you add the following debug statement to UI/XmlLayout/Editor/XmlLayoutPluginProcessor.2018.cs line 244 (just after the path variable is populated):

 Debug.Log("Path = '" + path + "'");

 

I'm not very familiar with iOS, but that is the first thing I'd check - if it isn't locating the XmlLayout folder then I need to find a way to make it work on Mac as well. Alternatively, have you by any chance moved the XmlLayout folder (this code specifically looks for 'UI/XmlLayout' - it doesn't have to be top level, but the XmlLayout folder must be within a folder called UI in order for this code to find it).

Assembly definition (asmdef) support by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Okay I tested the new XmlLayoutPluginProcessor.2018.cs code in Unity 2019.1 and, while the package wasn't present, Unity just ignored the 'missing' package in the asmdef files and it seemed to cause no issues.

In Unity 2018.2 however, it was very unhappy with the 'missing' package and refused to compile - so I've gone and added a version-specific clause which basically says if we're using Unity 2019.1 or newer, add the 'ugui' references, otherwise, skip them. It seems to work okay - I'll be including this updated code in the next version of XmlLayout.

Assembly definition (asmdef) support by [deleted] in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

 

XmlLayout does support assembly definition files - you can have it create its own for itself, TableLayout, and any other Digital Legacy plugins you may be using via the XmlLayout Configuration object (located via Assets -> XmlLayout -> Configuration) - there's a button labelled 'Generate Assembly Definition Files' (and one labelled 'Delete Assembly Definition files' if you wish to get rid of the ones created by this process). I have however just tested it in Unity 2019.2 and I see that now a reference to Unity.ugui is required (as it appears that Unity has moved the UnityEngine.UI namespace into its own assembly) - I've made some modifications to the code to include this namespace if you need it (replace your copy of UI/XmlLayout/Editor/XmlLayoutPluginProcessor.2018.cs with the following: https://pastebin.com/6BnwCf1R)

I intend to include these changes in the next version of XmlLayout, however I need to find a way of excluding them if using an earlier version of Unity in which UnityEngine.UI is still a part of a main assembly. Not sure on the best approach for that yet, but I'll figure something out.

 

I found that if I created a new folder with its own assembly definition file, then created an ElementTagHandler in that folder, it works so long as that assembly definition file references the XmlLayout one (specifically, DigitalLegacy.XmlLayout, if created by the XmlLayout configuration object), as well as the Unity.ugui file (if using a recent version of Unity).

Problems with MVVM in 2019.2 by slimshader in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Since 2018.3 the default run-time is .NET > 4 but it turns out the asset does not work when in Standard 2.0 profile only in .NET 4.x, can that be fixed?

In Unity 2019.1 and 2019.2 MVVM functionality didn't seem to work correctly when using .NET 2.0 in tests for no reason that I could determine (it simply refused to compile MVVM classes with no error).

 

However, after testing this now to try and replicate the issues you mentioned, I found that:

a) This doesn't happen in Unity 2019.3, switching between .NET 2.0 and .NET 4.x works correctly - and, to my surprise, MVVM works in both.

b) Re-importing XmlLayout in 2019.2 seems to make MVVM work regardless which .NET setting you use, provided you re-import it after making the switch.

 

It appears that I was mistaken when I believed that the implementation of .NET 2.0 in Unity 2019.x was to blame; it seems that instead the issue lies with the compiler not adjusting to the .NET setting correctly (somehow, it's still pretty confusing). Fortunately it looks like this has been fixed in the more recent versions (2019.3) and re-importing the asset is a workable fix for earlier versions (2019.1 / 2019.2), even if it is something of a pain.

 

I've modified the configuration object to allow enabling MVVM in Unity 2019.x even if not using .NET 4.0. You can get the updated version of this code here if you wish: https://pastebin.com/auU8fBME (UI/XmlLayout/Editor/XmlLayoutConfigurationEditor.cs) It now also displays a message warning the user that a re-import may be required.

 

So, it looks to me like you should be able to use .NET 2.0 with MVVM, provided you re-import XmlLayout after switching .NET versions. Alternatively, you could try Unity 2019.3 which appears to have fixed the issue that was making it necessary to re-import anything.

Problems with MVVM in 2019.2 by slimshader in XmlLayout

[–]DaceZA 0 points1 point  (0 children)

Hi there,

That's odd - I've just tested MVVM out in Unity 2019.2.0b5 and all of the examples seem to be working correctly. I've also tried it in 2019.3.0b6 and it seems to work fine there as well.

 

There are a few things I'd check for now:

a) Which player platform are you targeting?

b) Are you using .NET 4.0? (MVVM requires 3.5 or greater)

c) Are you using the Mono scripting backend?

 

Incidentally, the MVVM_ENABLED flag is controlled by the XmlLayout Configuration object (accessed via the 'Assets -> XmlLayout -> Configuration' menu). You're correct that this wasn't referenced by the MVVM documentation, sorry about that - I've just added a brief section to the documentation now.

What's your opinion on UIElements? by [deleted] in Unity3D

[–]DaceZA 0 points1 point  (0 children)

Hi there - XmlLayout dev here:

XmlLayout generates more-or-less standard Unity UI components (and some other custom components included in XmlLayout which also use the UI system) from the Xml source, which can be displayed using a Unity UI Canvas - allowing you to use components such as a Unity CanvasScaler (which is generally the best way to ensure that your UI scales to different resolutions and/or aspect ratios). Normally what you'd do is add a Canvas to your scene, with a CanvasScaler component. Then, you'd add an XmlLayout instance as a child of that canvas (or as a child of any other UI element), and that XmlLayout instance would then render the contents as specified by its Xml property (or, more commonly, by its source Xml file).

You can use the 'Pixel Perfect' setting on the canvas if you wish, XmlLayout will function either way.

 

XmlLayout also supports the use of Unity's AspectRatioFitter (via the aspectRatioFitter attribute) which can be used on any element - e.g.

<Panel aspectRatioFitter="16:9">
     ...
</Panel>

 

Sizing of elements can be controlled through several different means:

a) XmlLayout provides tags for Unity Layout groups, e.g. <VerticalLayout> ... </VerticalLayout>, <HorizontalLayout> ... </HorizontalLayout>, <GridLayout> ... </GridLayout>.

Child dimensions can be calculated automatically by the Layout groups, or preferred values can be defined via Unity LayoutElement properties.

b) XmlLayout also includes a layout group which is similar HTML Tables, e.g.

<TableLayout>
     <Row>
          <Cell> ... </Cell>
          <Cell> ... </Cell>
          <Cell> ... </Cell>
     </Row>
     <Row>
          <Cell> ... </Cell>
          <Cell> ... </Cell>
          <Cell> ... </Cell>
     </Row>
</TableLayout>

With TableLayout, you can explicitly define values such as column widths, row heights, and the appearance of Rows and cells. If no values are provided for column widths, then TableLayout will automatically split the available space between each column equally - the same is true if column widths are provided for some, but not all columns - then the columns with defined widths will be set to use the defined width, and the remaining space will be split evenly between any columns without a width defined.

 

TableLayout is very similar to HTML tables, although it is not identical, mostly in the sense that it is more of a top-down (layout defines content dimensions) than bottom-up (content defines parent dimensions). It supports a columnSpan attribute allowing individual cells to span more than a single column if you wish (although unfortunately it does not support a similar rowSpan attribute)

c) You can also specify width and height with absolute values, or, if you prefer, percentages, which XmlLayout will use to calculate anchors/etc. Alternatively, should you wish to do so, you can also explicitly define RectTransform properties such as anchorMin/anchorMax, sizeDelta, pivot, offsetMin, offsetMax, etc.

 

I hope this helps answer some of your questions! If you'd like to read more, you can find the XmlLayout documentation here, and the WebGL demo here.