Nuklear

This is a minimal state immediate mode graphical user interface toolkit written in ANSI C and licensed under public domain.

https://github.com/vurtun/nuklear

https://github.com/billsix/pyNuklear

(edit) Wow, that looks way more powerful and embeddable than I was expecting. I'll have to give it a try.

Nim's syntax is very python like, but it's statically typed and compiles to C. Best of both worlds.

Do you really prefer to learn a different API and library for every different part of your app ?

Qt is not focused on being a useful tool that you simply put next to your other modules, and plays nice when it's called. Qt wants to be a framework that drives your application. Qt expects you to speak in its own datatypes, not type-agnostic flat memory.

I mean, I've only used Qt very briefly, but how would I, for example, use Qt widget functionality to add a nice menu to my existing 3d game? It's uncommon enough that I can't easily find how to do it, and I wouldn't be surprised if it's next to impossible.

I don't think that would be very desirable: Qt widgets are made to mimick the desktop OS themes... I doubt you want these in games. However, you could use QtQuick, here is for instance an example of integration with a 3d game engine: https://github.com/MaxSavenkov/nya_qt And another which integrates with the creative coding framework openFrameworks: https://github.com/aklevy/ofUnderQml ; doing for instance a HUD à la Scaleform with these is fairly realistic given the nice scene graph of QtQuick

I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects.

I don't want to structure my code heavily towards a framework. I don't think that is flexible or maintainable. I don't want to use a framework that takes over the process and the processes' I/O and the main loop, and that I can't extend without plugging hard to maintain code into lots of magical sockets. Which also only gets you so far; you'll never be able to bend the framework to do quite what you need; and you'll waste hours and hours reading documentation and browsing obscure github projects to find clues how to bend it a little more. And of course, these clues will be invalid in the next version. This is my experience with Qt at least (as well as with CMake, for example).

What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result.

> through a simple plain data API,

I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ?

> I don't think that is flexible or maintainable.

The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ?

> I don't want to use a framework that takes over the process and the processes' I/O and the main loop,

That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA.

> This is my experience with Qt at least (as well as with CMake, for example).

I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.

It seems you are less informed than my first impression was. I did a few web searches, and the AAA titles using especially Unity seem to be far and far between. It's not good enough technically for top-notch performance (seems to require a garbage collector).

Also there are so many types of games that they cannot possibly supported by just two generic engines. For example, Open-World games need their own. Or military games like Call of Duty have their own. (And of course many Indie games have their own, as I said in the other comment).

Also most bigger publishers breed their own engines to save the fees for licencing a third party engine.

Bethesda games, generally open world, use an engine (https://en.wikipedia.org/wiki/Gamebryo for older games and https://en.wikipedia.org/wiki/Creation_Engine for most recent), they certainly don't go reimplementing it.

> Or military games like Call of Duty have their own.

No, they used the id engine and improved it over time.

> Also most bigger publishers breed their own engines to save the fees for licencing a third party engine.

Like ? for instance Bioware (as part of EA) uses Unreal engine. You mentioned FIFA games: they also use engines shared across a huge swath of games: https://en.wikipedia.org/wiki/Ignite_(game_engine) and https://en.wikipedia.org/wiki/Frostbite_(game_engine)

The only big release I know not using an engine shared across multiple game series is the recent Witcher games engine.

Well I had to do a little dashboard application and the interfacing from C++ to QML was... laborious, to say the least. It was quite hard to find the right magic words to do seemingly simple things like getting a list of dropdown items over to QML. If you don't have to work with Qt containers most of the time, I figure you have good abstractions in place. (So you're not working directly with Qt after all?) I wanted to do that too, but my employer wasn't happy with me not using enough QStrings and QStringLists and what not.

> Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D?

I don't play many games, and if AAA means "graphically impressive but possibly not a conceptual innovation", then my answer would be "no". I would be hard pressed to quote 5 AAA games at all. (I sometimes play FIFA on a friend's PS3 (yes it's dull), and here we have the first exception. Whatever)

However I happen to "know" that many Indie game developers prefer to control their own codebase, that they know in and out, and that they can cut and trim and slice and dice, to try out new ideas. (This includes more commonly known titles like Super Meat Boy, Braid, The Witness).

> keep reinventing game loops

Why should I not "reinvent" a game loop? It's a trivial thing to do. No big deal. I'd rather do it myself than starting with a big preconceived framework that starts with words like "Awake", "OnEnable", "OnLevelWasLoaded", "OnApplicationPause" (What's a level? Why would I have such a thing?).

> I feel like we're living in a parallel world.

I would like my applications to last much longer than 6 years. And I would really be surprised if there were not more problems. Regarding CMake, I wasted >20h in multiple attempts fighting an existing CMake build system including a tangled mess of CMake scripts. It's really hard to understand and maintain. The documentation is not good, it doesn't try to teach you the underlying conceptual models. I then decided to just put my build description in a python file and generate the build system myself. 3h until it first worked, very little maintenance afterwards. Plus, I now have the flexibility to easily add more facets as the system evolves, and to easily derive other useful dev tools from the python structures. (Small downside, would possibly have to write more build system generators if there were multiple supported platforms. But while CMake makes some of this a no-brainer, it's almost never just "now compile for this other platform", and other aspects to porting get relatively harder with CMake).

With Qt, Qt itself is the app, your code is just a plug-in. :-)

The killer app is if this was all done at compile time. Use common web technologies to design the UI, translate that into lightweight GUI code.

One advantage of this approach compared to the minimal UI libraries is that you can expect it to work well with a massive array of hardware – elements like scroll boxes should work seamlessly with touchscreens, apple trackpads and regular wheel mice, text input elements should respect the user's navigation key bindings. Accessibility features like voiceover should be supported. The downside is of course the weight of the browser engine compared to a tiny C library, however it'd be an interesting experiment to see how much bloat could be stripped out of a browser if you only care about a subset of features, i.e, WebGL can go, legacy layout modes can go etc

[1]: https://github.com/zserge/webview

For painting, I have positive experience with this cross-platform C library: https://github.com/memononen/nanovg It’s tiny, has very few dependencies, and the performance is good even on relatively slow hardware like Broadcom or Mali embedded GPUs.

However, it lacks higher level stuff. There’s no layout, input handling, styles, controls, advanced typesetting, or animations.

> options like QT, but found them to be extremely large and full of things I didn't need

> But then, I decided to just use a web browser.