MyGUI 3.5.1 release plan

[Altren]

I've made many minor fixes, mostly related to tools and demos. Also few fonts related fixes.
Basic scale support for entire GUI is the only new feature.
Also I've added the MYGUI_BUILD_RENDERSYSTEMS to build multiple render system platforms.

@ssunday I hope this changes would help with the vcpkg port. I want to make sure that there are no more issues related to vcpkg before releasing this.

[ssunday]

Awesome! I hope vcpkg gets merged next week lol.

The decision landed on—vcpkg upstream port uses dummy and people wanting anything else can do whatever as an overlay—is fine for our (OpenMW) purposes. We just need dummy and that's it. People who want otherwise can make an overlay port.

I think the multiple render systems could theoretically help if you write it as an additive render systems, but we still couldn't have tools as a feature for the port because it depends on choosing non-dummy. But as I said above, I wouldn't have any reason to implement that upstream though others could. But yeah, I guess it would help in offering multiple render systems (though are the two opengls mutually exclusive??) so each could be its own feature, but tools still couldn't be added IF it requires A rendering system that isn't dummy.

Taking a step back, what does the render system choice even...like mean/do? Like why is it even a thing if we can decide to plug in our own rendering system regardless? I believe that the tools functionality requires certain render systems chosen and of course demos and stuff, but...as far as actual library interop, it seems like you have to choose which platform you want anyway so why have a build lock in that isn't much of a lock in.

Bringing in @AnyOldName3 in case he has any thoughts.

[ssunday]

"But as I said above, I wouldn't have any reason to implement that upstream though others could." -> I say this but I probably would just because 😂.

[ssunday]

I do think making it so it's not like either or but additive does definitely help make it more flexible, but it doesn't solve offering tools as an option...though, I guess we could make it so it always produces if it can...so it's not a feature...but is that annoying to ship it if you don't want it (like is it that heavy)? I don't know. 🤔

[Altren]

but we still couldn't have tools as a feature for the port because it depends on choosing non-dummy

Why choosing non-dummy is a problem? I guess I missed initial problem. Somehow I though that allow building multiple render systems would help with that. (also it helped with CI anyway)

Taking a step back, what does the render system choice even...like mean/do? Like why is it even a thing if we can decide to plug in our own rendering system regardless? I believe that the tools functionality requires certain render systems chosen and of course demos and stuff, but...as far as actual library interop, it seems like you have to choose which platform you want anyway so why have a build lock in that isn't much of a lock in.

Now MYGUI_RENDERSYSTEM defines only what to use for demos and tools, while new option MYGUI_BUILD_RENDERSYSTEMS define what to compile.

[ssunday]

So vcpkg ports can have features—optionally things you decide to add. MSDF is a feature, for example, you can optionally add and it doesn't impact anything else. https://learn.microsoft.com/en-us/vcpkg/concepts/features

"By design, features should follow these principles:
Additive: enabling a feature should provide new functionality otherwise missing from the package without disabling any other functionality.
Non-exclusive: enabling a feature should not prevent other features from being installed."

"Features should not be used to define alternative sets of functionalities. For example, a graphics library should not use features to choose between exclusive graphics backends, since it's not possible to install all of them at the same time."

I just saw ^ this quote which, ugh, really sums it up. Right now the situation is 'use an overlay port to do what you want'. I suppose that could be upstreamed to 'mygui-opengl', but IDK if vcpkg goes for that in the upstream or would want people to use overlays.

Features do not have the concept of feature dependencies, so that's why this is important...you couldn't say 'I want tools, but tools requires you to have chosen a render system'. Like you shouldn't be able to choose to install tools with dummy render system, from my understanding of mygui, so that's why adding tools as a feature is problematic.

I don't know like the use case of someone wanting tools in their mygui vcpkg so I don't actually know why it was added to begin with.

[ssunday]

The more I think about it, the more I get confused. I'm not sure what people's use cases really are. Like tools is a wrench in designing it, but if the port doesn't offer it as an option and people have to go overlay, then we can allow for more render systems to be compiled w/o concern for that....hmhmhmh.

[ssunday]

But whether vcpkg thinks it makes sense IDK.

[AnyOldName3]

The main reason why OpenMW prefers the dummy rendersystem is because all the other ones end up pulling in dependencies like SDL2_image, and we'd rather not include libraries we don't use into our first-party packages.

[Altren]

Looks like I'm ready to release 3.5.1. Will wait for a day in case I forgot something