Add a sample that doesn't involve SHELL

[mccakit]

Add a sample that doesn't involve SHELL, anything basic would do, the sample shouldn't use manual building of the library or a pacakge manager, it should use normal toolchain files, git submodules and add_subdirectory

[wh1t3lord]

Hello there, It is a really nice request and issue! But tbh I need to warn about two things:

1. Don't hurry with your wishes
2. It is not that trivial as you might think

I am talking about that part of your message

doesn't involve SHELL

So it is better to say that people want to see and expect from Mike's library to be as 'easy integration' and as 'comprehensible' (aka huge amount samples, huge amount of documentation, and etc). As you notice library grows, it becomes bigger and bigger and sadly we have more and more backends.

From my point of view, I propose to use SHELL as one thing that handles both things as implicitly handle user most wanted thing as 'easy integrate' backends and at the same time maintain the thing from SHELL to be as it was before the library that works with examples that goes out-of-box as demontration for user (as well as integration samples as new ones).

So it is a discussable, otherwise what do you mean by sample without shell? But what's the point of backend then? Providing another library but it is separated to shell, hm I am not sure it is a good design, about this:

pacakge manager, it should use normal toolchain files, git submodules and add_subdirectory

Elaborate please, I am not aware of CMake integration or something else, it is a reasonable statement of yours but how to merge these two independent things in peace like C++ implementation and these toolchain/CMake scripts it is all Mike's headache and as I stated "not trivial" so it requires some effort and concentration. As I guess you faced the problem that RmlUi doesn't provide a such thing as ImGui but we're working on that and make our own approach that could satisfy most cases, it is not final, but I hope Mike will take a good time on making things up.

Best regards,

wh1t3lord

[mccakit]

For any reasonable project, you wouldn't use a package manager at all, because the project may use another stdlib, compiler etc.

Sane approach to CPP project management is always building everything from source.

It is very hard to do this with rlmui with the provided sample and documentation.

What should we do is, at least provide 2 new examples to the samples directory with 2 different backends, SDL-OpenGL and SDL-Vulkan, then update the documentation so using package manager is of secondary to building it from source.

I already have a SDL-OpenGL sample, which I compile to 4 Linux distros, windows macos, android and iOS. The sample can just take my repo and assume native compilation by editing some stuff

https://github.com/mccakit/rml_ui_template

We could discuss the documentation update in a separate thread, as I believe switching to sphinx is a good idea

[mikke89]

The thing is, there are a million ways to set up a C++ project and its dependencies. As a library, we need to support pretty much all of them. Directly including source code is just one of many approaches. And to the contrary, it's perfectly possible to use a package manager and change all of the things you mention, including stdlib and compiler, and also build everything from source. Let's not present any one solution as the correct (or sane) way to do it, it's too opinionated, and this library doesn't have a stake in that.

Another complication is that there are tons of ways to configure the library, including the choice of backends. And we need some kind of shell regardless for adding fonts. That's mostly what the shell is doing any way, in addition to handling some key bindings and such, the shell is quite small really.

You have made a nice template there already. And I'm sure it's quick to get going and use. But it's very specific to SDL and OpenGL, and of course very specific to the submodule approach. It wouldn't be practical to provide something like this for all our backends, or different setups.

But it could be nice to show one backend as an example in different types of setups. Alternatively, I think we could go a long way with some better documentation, and partial examples with some instructions. We've discussed some of these things already here: #685. Or maybe it's better to leave this to thirdparty resources like yours altogether.

[mccakit]

I support one backend multiple approaches idea, a new page in the doc can point to third party project samples.