Replies: 1 comment 1 reply
-
Thanks for the suggestion. I appreciate the understanding that features and additions, including all of the backends, have non-trivial maintenance costs. I completely agree with that, and I think it is important to be aware of this anytime new features are added to the library. With that said, a primary aim of the library is to be easy to integrate into any existing setup and framework. We want the library to adapt to the user's environment, not the other way around. Different users have different needs, and use different platforms and frameworks. Some prefer SDL, others prefer GLFW, and others again want everything to be native. By supporting several of the popular backends, it ensures easy integrations into the user's existing setup. To me, this benefit is important enough that I'm willing to spend some extra time maintining the backends. Another nice benefit is that it allows us to easily test the library during development using different frameworks and on different platforms. I can perhaps understand that some users might find the number of choices a bit overwhelming. Especially for those that are mainly interested in getting a UI application up and running, and otherwise do not have a particular preference. Maybe we could make a recommendation for a specific backend in these cases. Generally, I think GLFW+GL3 and SDL+GL3 are solid choices here. |
Beta Was this translation helpful? Give feedback.
-
Is it better RmlUi only integrates GLFW+GL3 (or another combination)?
I think this is good for both maintainers and developers.
For the maintainer, this can reduce a lot of work, free them up to focus on more important features and issues.
If someone wants to commit code, they don't have to worry about whether their code is compatible with all of the backends.
For developers, RmlUi is much easier to use.
They only need to download a few header files and library files, Just like SFML.
Beta Was this translation helpful? Give feedback.
All reactions