Forums » Suggestions
RmlUi - Draggable HUD design
I think it would be beneficial if the new RmlUi-based HUD were designed from the beginning to allow major display components to be draggable.
RmlUi's <handle> tag already works out-of-the-box to allow simple movement or resizing of display elements.
One major consideration that comes to my mind when planning for this is the structure of the HUD. The IUP HUD currently uses a multi-layered, single-document (dialog) approach. I'm assuming this was due to how IUP dialogs interacted together and possibly styling limitations. With RmlUi being much more free-form, I think a multi-document approach would be a good direction to take things. Each major HUD component would be a separate document that is only sized to its contents and has a <handle> that could be used to freely reposition it.
Clearly, certain elements, like the center crosshairs, would need to be static. For these, a fullscreen-sized document would probably be best. Of course, this introduces the possibility of clicking this document and pulling it to the front and on top of everything else. This should be easily remedied by having a Click event for it that merely uses `Document:PushToBack()`.
In my own experimentation, I've been looking at trying to use RmlUi Templates as a means to create the building blocks for these component documents, but these efforts are hampered by our current inability to use inline scripting in Rml files. My plan here was to use a combination of inline scripts for "onload" and the "onhandledrag" to retrieve or store positioning and then update custom RCSS properties. While this can be worked around using `Element:AddEventListener()` in the back-end Lua, or C++ equivalent, it could be streamlined by having it all defined in a single template.
RmlUi's <handle> tag already works out-of-the-box to allow simple movement or resizing of display elements.
One major consideration that comes to my mind when planning for this is the structure of the HUD. The IUP HUD currently uses a multi-layered, single-document (dialog) approach. I'm assuming this was due to how IUP dialogs interacted together and possibly styling limitations. With RmlUi being much more free-form, I think a multi-document approach would be a good direction to take things. Each major HUD component would be a separate document that is only sized to its contents and has a <handle> that could be used to freely reposition it.
Clearly, certain elements, like the center crosshairs, would need to be static. For these, a fullscreen-sized document would probably be best. Of course, this introduces the possibility of clicking this document and pulling it to the front and on top of everything else. This should be easily remedied by having a Click event for it that merely uses `Document:PushToBack()`.
In my own experimentation, I've been looking at trying to use RmlUi Templates as a means to create the building blocks for these component documents, but these efforts are hampered by our current inability to use inline scripting in Rml files. My plan here was to use a combination of inline scripts for "onload" and the "onhandledrag" to retrieve or store positioning and then update custom RCSS properties. While this can be worked around using `Element:AddEventListener()` in the back-end Lua, or C++ equivalent, it could be streamlined by having it all defined in a single template.