Application-wide C++ GUI Update

01 May 2023

Our application-wide GUI is advancing very well, we are still working on a test application and it looks very good to us. Admittedly, everyone has their own aesthetic sense but we think that we landed on a style that would please a lot of people. We kept the widgets as small and simple as possible while maintaining legibility in order to avoid having interfaces that would occupy too much screen real-estate and would leave too little room for what the application itself has to do.

We still have a handful critical bugs left in terms of functionality and we also have more feature lined up for implementation but we opted to get a steady build at this point before implementing other features.

This is what it looks like, isn’t it neato! (everything is dockable btw)

We have:

• a log window with color support and output to a log file,
• a tree-view panel
• a full-fledged text editor panel.
• support for tabbed window panels
• panels that are all dockable/undockable into their own little window
• an integrated script system

Text editors are super fidgetty to get right. Code-wise, we’ve done many of them so that’s not really a problem here. With text editors, people have a lot of habits concerning control keys and there’s an unspoken standard out there. If you use a text editor and these habits don’t perform what you expect them to do, the editor will immediately feel clonky and people will just stop using it all together. We saw our share of clonky text-editors in internally developped game tools in the past, heck even the window’s default text-box feels clonky.

Say No To Clonk!

We are still investing a lot of work in the text-editor but we find this part rather crucial. We are using Notepad++ as our baseline, if a key does something in Notepad++, it has to behave identically in our editor. It’s our opinion that Notepad++ got these implicitly expected behaviors down to perfection. We are almost there :)

All of the rendering is custom and opengl based, eventually, we’ll have pure opengl window panels where people could render whatever they want in them, this should be useful for game rendering views or any kind of graphics editing. Opengl is not easily multi-threaded though so we expect to have a lot of work to be done if we want the opengl context to be swipped from another application running on the side for example. We’ll see when we get there.

We also added script support, we wanted something lightweight and somewhat simple, the purpose of the script is to automate tasks either for GUI generation (the layout system maybe?) or for basic batch processes. We tried to integrate CPython in it and while successfull, CPython was too big and overly complex for our simple needs. Instead we opted for Squirrel which is based on Lua with much better garbage collection and the ability to declare classes directly instead of using Lua Tables.

Some applications using our GUI might concretely rely on python code themselves and they could want to have that script system easily linkable to inputs and outputs of our GUI. Ideally, we should have a plugin system to accept multiple types of scripts, we’ll have to design this. It’s not the priority though, we will probably settle for Squirrel at the moment and maybe support multiple types of scripting languages in future versions of our library.

One of the challenge we have is class or struct reflection since we work in native c++. We do not want to go the Unreal way and add tons of macros doing implicit crap. While this does simplify the declaration of reflective classes, it also enforces an architecture and general-bloat pretty much everywhere. The limitations the Unreal approach imposes on class constructors is an extreme annoyance for native c++ coders. We’re still analysing this, chances are we will offer two reflection options, either by inheritance or the instanciation of a reflection-class so people can add items to reflect only when needed declaratively instead of messing up all of their code-base with constraining systems like the macro approach would.

We still have a lot of widgets to make, namely for basic types and once we have our reflection system up, we’ll need to do enums and structs. Along with this, we also need a layout system so our library users can instantiate windows quickly, nicely and pleasantly. Having windows content that change depending on the underlying c++ code like Unity and Unreal does with their components is the pleasant advantage of reflection, so we’ll code that as well of course.

Other than that we need a major code cleanup pass and actually do an code interface layer. That too is another can of worms. We will try to have clean and minimally intrusive code interface as possible. We’re still looking at competing GUIs and reading comments to try and detect common annoyances and see if we can avoid these all together.

The screenshot doesn’t portray this well, but all of the panels are dockable and if they are undocked and left outside of the main window, they become their own little stand-alone window. This was a very crucial feature for us since we all work with multiple screens and our workflow often involves leaving some of the windows on our secondary screen - it was a must like they say.

CPU-wise and memory-size, the app is very lightweight and our Test Editor stands at only 2.2Mb in release and 5.2Mb in debug. If you are familiar with GUI systems, this is very small. we don’t rely on dlls and everything is statically linked into a single lib with absolutely zero encroachment on the OS. We are happy to never install whole GUI systems that take 150Mb or more and require an actual install onto your system or having your clients install a redistribution that would encroach on their system as well.

As coders, a single lightweight lib is the only way to go.

We did notice that if you render a huge svg image in the background, it costs a lot so we will probably have to implement a caching system to cache pre-renders and just reuse these until the widget changes and requires a redraw. In practice, this only happenned with the main window’s background (if we set an svg image to it) when we stress-tested it. We might just allow for bitmap backgrounds, I’m not sure there’s a need for vector graphics there. We’ll see after the cache optimization, if we can keep svg support for the main window background, we will.

So there’s still a huge amount of work left, maybe a year or so of work plus time for unexpected delays and beta-testing. This takes longer than it looks but we’re solidly heading towards having all of the main core features down.

We are super proud of the results, we started with a dark theme but we already have a color-theme system and adding new themes is easy-peasy.

Tell us what you think in the comments below!

Thanks for reading and happy coding!

Comments