Lessons from InterfaceAPI

InterfaceAPI has been released over on itch.io and also available on Codeberg, and there is now a C# port currently in the works.

What's so big about C# when the work in Odin is already a work-in-progress, and works really well?

Shift in Thinking

Most of the work involving Odin is very impacting, but there has been a lesson to learn about its' development. It is currently using Raylib as its rendering backend, which is great -- there's nothing wrong with it -- except there are some things you need to do manually which require the extra effort. Text rendering is somewhat inconsistent. Some text is rendered against back buffers, others direct to screen. This causes a slight issue if you're not careful about texture filtering.

It's easily missed; setting texture filtering to POINT to ensure crisp text (Raylib's default is BILINEAR), without which would cause text to blur slightly and wasn't noticed until much later in development. The font glyphs are already rasterized using FreeType into a texture atlas, but it's a lot of extra work.

Add on top the glyph shaping work and ensuring width values match the width of rendered characters despite all the features Harfbuzz gives to support this process is still time consuming, and the fine tuning required to ensure consistency is challenging.

Most of the InterfaceAPI library is AI generated. Some of the initial concepts were hand-written, then it was handed off to AI to prompt, design, plan and implement the various features it has today.

It is a fairly complete UI library and contains perhaps the most UI widgets of a free, open source library anywhere written in Odin. Because of the substantial library, it becomes difficult to consider switching to another language for the sake of it, so why change?

I have my personal gripes with Odin, and not because of Odin, but because of my patience:

I find manual memory management tedious. new, make, delete, free. It's a common occurrence, and perhaps too common. More often than not, I'm asking AI to generate create_* and destroy_* procs for me because it's incredibly tedious trying to do it myself.
Debugging is a fight against unrefined debuggers. One option out there for Odin compiled code is RemedyBG, besides Visual Studio, and others, but Odin does not produce the most accurate debug symbols. This is something that takes patience working with. In real applications, debugging work does tend to be where you spend the most time, but that shouldn't mean resorting to fmt.printf everywhere because debuggers don't work how you need them to work.
Allocator hell. Well, actually, this is more a gripe with myself. Mixing allocators can be easily avoided if one simply thought about what they were doing before typing a single line of code. This is where the "engineering" pays off, because you are taking the time to appreciate each and every allocation you do and managing it properly. But doing so requires a tremendous amount of patience. Patience I personally do not have.

Odin is a language that embraces what it calls the "joy of programming". Of course, that depends on what people refer to as the "joy of programming". I enjoy programming in general, but it takes a certain kind of "joy" to get me excited about something, and "joy" for me is being productive, allowing myself to make progress, being able to debug things quickly without needing to add debug prints everywhere. If the language I'm working with is tedious and difficult to debug, that's not "enjoyment" to me.

Now, I'm not saying all programming should be enjoyed. There are times when programming does get tedious, and it does get like that from time-to-time. That said, forcing me to write debug prints because modern debuggers can't capture lexical scope properly or the debug symbols are not producing correct loop offsets so you lose variable visibility many lines before the end of the lexical scope, that's not a pleasant experience and that needs an urgent fix.

Perhaps Odin has improved since last I used a debugger with it, so I may be premature with this frustration if this has since been fixed, but it was one of the many reasons I was put off Odin for some time.

However, my limited patience with points 1 & 3 above are the main reason I am choosing instead to use C# for InterfaceAPI - at least in the beginning. Having access to a decent debugger, even if it is for a GC language, is still, in my opinion, a better experience and is the reason for this port.

Working on the Port

Despite the risks, I started the port on the pretext of using the same technology as I did with the Odin version of InterfaceAPI, but I quickly decided against using Raylib in C# and started looking at Skia. This was because Avalonia, another UI library in C#, also uses it and has a track record.

Avalonia took inspiration from WPF, however, and uses what I think are inferior UI models. The term "MVVM", or Model-View-View-Model, is the concept that data and views interchange state between them with event handlers. Microsoft used XAML in WPF, which was, in my view, a step down from the Windows Forms ecosystem, which was the RAD environment I had literally grown up with and spent over a decade learning and perfecting.

That aside, the exploration into C# got me wondering -- I had spent some time with AI attempting to figure out how to do proper crisp text rendering without realising Skia had even existed. Perhaps out of curiosity and a sense of interest, I did pursue the use of FreeType and Harfbuzz and I could remain on Raylib with the Odin code side; but it gets me wondering: do I keep what exists in the current InterfaceAPI already written in Odin when I decide to return, or do I instead replace the rendering engine with something more powerful and more appropriate for business-style applications?

These are questions worth asking, but the downsides are the time used to convert. It's quite possible I keep with Raylib, but I will most certainly swap its windowing and input system with SDL, as my work with InterfaceAPI in C# has taught me that SDL has a windowing system that works very well on Linux.

Curiously, Raylib may get a engine swap from OpenGL/GLFW to SDL in the foreseeable future, so the SDL swap-in makes the most sense here while the work in Raylib remains a work-in-progress or "on the table", so to speak.

The Future

InterfaceAPI is approaching the final stages of its C# port, and at the same time an editor is being developed that will allow generating Odin and C# code from designed Views. It will currently be relatively basic, but the expectation is that it will be expanded; at least a little.

I will unlikely work on anything major until this editor has been worked out. My goal with this is to make InterfaceAPI work well in both Odin and C# with this RAD-style development environment, albeit without any code editor. The idea is it generates code and you can use your own code editor alongside.

More information on this will be developed nearer release.