Release 1.4

[Madman10K]

Goals

The goal of release 1.4 is to clean up and abstract all systems related to:

1. Windowing & monitor management
2. Input
3. IME, WASM and other imgui usability improvements
4. Parts of the CMake build system

Windowing, monitors and input

These systems are currently the most ugly part of the framework. They are really rigid and functionality is seemingly randomly shared between the internal window and the interface classes.

In previous monthly newsletter posts we mentioned our decision to switch to SDL3, which, while similar to GLFW, is also different enough to warrant at least a month to port to, an entire refactor of basically the entire windowing and input interfaces and fixing the increasingly convoluted abstractions of the current backend code.

We also have concerns about SDL3's size, which means that we're not really comfortable in switching to it, since one of the goals of the framework is to be generally compact. Unfortunately, SDL depends on many times the dependencies of the framework, let alone the dependencies of glfw.

Therefore, we decided to keep glfw as the only current windowing library, with support for SDL being optional.

Our current solution is to do the following:

• Do a surface-level refactor of some functions
• Split the internal window class into a generic class with specific backend instances
• Port over the entire window interface to the new generic class
• Port over the entire input interface to the new generic class
• Port over the entire backend window class to the new generic class
• Port over the entire renderer utils interface to the new generic class
• Port over each dear imgui renderer-dependent function
• Port over each renderer-depended function for extensions, window integration, etc.
• Document the changes in the window interface
• Document the changes in the input interface
• Document the changes in the backend window class
• Document the changes in the renderer utils
• Document the changes in the custom renderer system
• Migrate current custom renderer examples to the new internal renderer system

Additionally, we're planning of developing a separate window backend for SDL3 which will not be bundled with the framework by default, but would rather be integrated as a separate library by projects that need better OS integration.

The tasks for the SDL port are the following:

• Complete the SDL backend
• Integrate with the new input system
• Document backend

IME, WASM and other imgui usability improvements

The current release has broken support for the following:

1. Any type of IME support. GLFW simply assumes that once you are focused on the window the IME should always be active
2. WASM interactions such as copy-pasting, which is partly a GLFW problem and partly a browser problem.
3. Integration with other text editing-adjacent systems: virtual keyboard hints, setting virtual keyboard types, better touch support in dear imgui in WASM

Most of these are dropped, since GLFW is lacking the required features. The optional SDL renderer will be able to solve most of these issues with the cost of more raw interaction with some SDL primitives in some cases.

CMake reform

To say our CMake code is an unreadable mess is an undestatement. Even though over a year ago the monolithic 1K+ lines CMakeLists.txt file that was generated for each project was replaced with a smaller template, which was then split into internal CMake files for easy updating without the need to regenerate a project's files for every major framework update, the files are still messy and include way too much platform-dependent logic and sporadic bug fixes in random places.

With some patches that are already in the latest git master the internal CMake files are now split into platform-dependent functions which makes refactoring, adding or removing of platforms way easier than before. It also makes the core code more readable and platform-idependent

Final major packaging effort

With 1.4 we finally expect to have the framework packaged as a debian package, as well as its packages being automated by pkggen.

Hitting feature-complete status

I really think that 1.4 might be the last framework release for a long time and I think I might just release it as 2.0 instead.

This does not mean the framework is being abandoned. Feature requests and bug reports will all be acknowledged, reviewed and merged as normally. The fact is that I can't really think of any new big features we can add to the framework at this point.

It really is a case where when I think of the future of the framework I can barely imagine anything that I can improve on apart from continued code maintenance.