C++ Programming

[zeOrb]

@Gwenn;431383

Well in some regards Slate code is almost alien to the gameplay code. Some + and - :

• It’s really easy to define new widgets, new events, new parameters in your new widget…
• It’s really easy to work with dynamic data. Having a text, an icon, an alpha value that changes with the game’s state is as simple as it could hope to be.
• If you’re making a complex UI with a lot of shared graphical assets that you may want to change at some point, there is a “style” mechanism which lets you define style assets in the content browser, with a graphical editor. The setup is a bit complicated (Rama has a wiki tutorial on this) but it’s great.

• Movement in Slate is close to impossible. Not sure about whether UMG is better.
• Overlapping widgets are close to impossible. You can write a custom layout class or you can just add another UI layer, but it’s really painful.
• Some base widgets are really limited in a painful way. You can’t use a combo box and change the highlight color (bright yellow). You can’t make a slider with a background that is larger than the thumb. Etc.
• So really, you need a custom widget for everything, including buttons.
• Slate widgets don’t inherit UObject, for example, so everything you thought you knew goes out of the window. Using game objects in the UI can be really painful, with Slategoing as far as making you declare a structure to store references to UObjects, in some cases.

As far as UI frameworks go, well it’s much less worse than Scaleform from a programmer’s perspective, more programmer-oriented than HTML, and maybe more intuitive than Qt. It’s supposed to be close to WxWidgets, apparently. I’m not sure if it’s just Stokholm syndrome or if it’s good UI framework, but I’ve been writing Slate code for a year now and I’m always fine with doing more, so it’s not that bad.

Thank you, Gwenn
I guess I’ll take a look at Slate and practice a little bit to decide which way is more suitable for me now