Hacker News Reader

Came across this yesterday:

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

Neat, thanks for sharing!

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

Lol I was just about to repost my pyNuklear link. Regular nuklear is fantastic if you like C, which I do too :-).

We bumped into each other yesterday on the PyQt thread, and the grandparent seemed to be asking for the same thing. ;-)

https://github.com/zacharycarter/nuklear-nim/

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

This is a good one too: https://github.com/ocornut/imgui

Seconding Dear Imgui, it's a great small library that has a ton of bindings available. Highly recommend Flix01's addons branch https://github.com/Flix01/imgui/wiki/ImGui-Addons-Branch-Hom...

Do you have an idea why this is not just merged back into 'regular' Imgui? I like the look of some of the addons, but by having this fork no Imgui bindings will support them.

imgui is a C++ libarary, which is why I chose nuklear being a C library written in C89. Just a small distinction, but some people are working in just C.

I wonder what's the point of people touting about reusable code is when as soon as a set of 71 distinct libraries, most of them optional, (disclaimer: ls /usr/lib/libQt5*.so | wc -l) full of reusable code with a common API and coding conventions is not considered since it's apparently "too much".

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

You should look into the sibling comments (nuklear, DearImgui, Casey Muratori), and try doing a simple toolkit for your own use. Then you will understand the difference. Qt is huge, and opinionated, and very difficult to control.

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.

Fully agreed.

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

> 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?

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

Both seem to integrate an existing thing into the QML runtime by using Qt-defined hooks and subclassing Qt-defined classes. I can't really understand it or map out the control flow. There's lots of magic involved.

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).

> 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.

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.

> What do you have in mind for instance?

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).

> 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?

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.

> For example, Open-World games need their own.

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.

Modularity. In a project of mine, https://github.com/billsix/hurtbox, I switched from "dear imgui" to "nuklear" trivially. I imagine that switching a project from qt to gtk or wxwidgets would be a massive rewrite.

Curious to know why you switched?

Is the browser really lighter weight than Qt?

I view this all as a huge step backwards. This is exactly why my glorified IRC client takes over a gigabyte to run.

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.

I like this approach, I'm keen to try it too – is the project open source? Which browser engine did you use?

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

We're currently looking at pxCore / pxScene. It's a fairly small couple of libraries with a portable frame buffer layer (core) and hardware accelerated 2D scene graph (scene) with an optional JavaScript API (you can also just use C++ too).

A bit of a stretch, but you can use Electron (https://electronjs.org/) which ties to nodejs, and use nodejs to call out to C.

Or a webview using Webkit or IE11. There is a cross-platform wrapper in C99 [1]

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

This is awesome, thanks for sharing !

> Something that could offer similar usability in C definitely sounds exciting

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.

Amusing.

> 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.

I'm a bit unclear, do you mean you fully switched to using a WebGL canvas with HTML-based controls? Or more like a browser-widget embedded in your application with HTML UI widgets, that somehow controls a separate OpenGL canvas?

What did you use in the browser for UI and GL?

Pretty much just CSS and Bootstrap for things like nested menus. The normal input/a tags are pretty versatile, but Bootstrap does also help a lot.

Yeah I don't even bother with thinking about building desktop applications. User interfaces are over 9001 times easier and faster to build as web pages / pwas.