2.0 architecture discussion

[Madman10K]

The framework has evolved a lot over time and with evolution comes bloat. I would really like to have this project be as slim as possible, while still having a good number of features that accommodate most use cases. However, the planned features for version 2 are expected to bloat up the framework exponentially. Specifically features like the proposed:

1. Cross-platform IME support
2. Mobile support
3. Better renderer

This discussion is a place to discuss the issue of bloat in the framework, so that we can find a point where minimal workflows are as minimal as possible, while complex applications can still work for many of our users.

How to handle the growing number of platforms

Currently, we support 4 platforms:

1. Windows
2. Linux
3. macOS
4. WASM

However, for 2.0 we also plan to add support for:

1. iOS/iPadOS
2. Android

The good thing is that iOS and iPadOS support is mostly ready out of the box, since many of the macOS features work in the same way over there. However, there are also many missing features, mainly:

1. How do we port UntitledOpen to these platforms. Opening links and file pickers there is different, though it looks like it is easier to implement due to their more closed nature
2. Porting UntitledFontManager will be hard and might even just not be possible out right
3. We have to account for touch input in dear imgui, since dear imgui is mostly made to work with pointers, instead of multi-finger gestures. This will be a big pain, specifically for developing applications that need multi-finger gestures(image editors, games, etc)(needed for WASM too)
4. We have to have solid IME support because 99% of input on these devices is done through an IME
5. Build system updates: dealing with the Android and iOS dev kits, generating builds for cross-compilation, generating local developer builds that launch emulators, CI for these platforms, etc
6. Probably many other issues down the line

This will add a lot of complexity in a very short amount of time. The current solutions are:

1. Just YOLO it and add them in
2. Forget about mobile support - we don't want to really do that due to an internal project that will greatly benefit from having it
3. Remove the platform code out of the monolithic framework binary, create unified interfaces for each platform and make each platform a separate module - basically a more complicated way of following the dear imgui backends model

The SDL3 question

We decided to commit to switching to SDL3, since IME support in GLFW will not be a thing for the foreseeable future and it is the only windowing library that works on mobile, as well as on desktop. It is a bit bloated though.

SDL3 and the framework share some similarities in the way they handle modules, so while live builds of SDL3 that you can find in most distributions will be quite bloated, since all the options will be enabled, it is not like you have a choice with the distribution builds of the framework.

My though it that, maybe we can switch to SDL3, minify and remove parts of it that we don't need, such as APIs that duplicate ones that are available in the C++ standard library, and then for the rest, we can include them in the modules system, since we have no choice over this either way.

Another solution is to implement an adapter that uses a plugin-like interface to dynamically load a backend. This way we can have an SDL and GLFW backend that can be loaded at runtime. I expect that this will be a disaster when it comes to maintaining it to be honest.

Better renderer

Currently we have a basic renderer that can only renderer dear imgui UI and nothing more. However, in the future we want to allow people to design their own custom graphics pipelines so that applications with more complex rendering needs can still be made with the framework.

We can either:

1. Replace the current renderer with some off-the-shelf solution, which is not satisfactory due to our need for OpenGL and WebGPU support, at least until WebGPU is supported everywhere and OpenGL can be removed(this is mainly an issue of shading languages and poor support on the web)
2. Keep the minimal renderer but create an adapter abstraction that allows people to add their own custom rendering engines through a unified interface

I think point 2 is the way to go, though point 1 would be great in the future when we an really only roll with Vulkan and WebGPU, or even with just WebGPU when support is universal across both desktop, mobile and web platforms.

Conclusion

What are your opinions? The current questions are:

1. Do we modularise the platform-dependent parts of the framework?
2. Mobile support: yes or no?
3. Opinions on switching to SDL3? How should the integration be handled?
4. Do we modularise the renderer?