Add demo mainloops to the normal code base about nuklear

[robotanarchy]

Okay, thanks for explaining. I'm planning to use it as lightweight main GUI library in a lightweight program with no bigger ecosystem, that's why I was asking.

But maybe we could split the demos into 2 files - the loop with GUI and the glue (boiler plate) code.

Sounds useful to me, but I don't even use zahnrad yet - so only do this if you have a benefit, too.

[dumblob]

How about adding all the mainloops from the demo as normal code base?

In my opinion this might seem appealing, but it doesn't make sense, because Zahrad is mainly meant to be used as part of some bigger ecosystem (where GUI is just a subset of visual functionality - e.g. games or simply drawing to separate canvases including pictures, charts, etc.), but not necessarily as a standalone application (which is what demos are good for).

Also e.g. in case of X11, there are plenty of options how one can setup the main loop, so forcing one specific implementation by providing an officially supported function like zr_mainloop_x11(my_zahnrad_gui_function) wouldn't be an advantage, because many people would customize it anyway (instead of just copying the loop file).

Last but not least, it's unnecessary to spend a lot of time with polishing and maintaining such platform-specific code (right now demos are not considered to be perfect unlike zahnrad.c and zahnrad.h). The "loops" are also quite different in nature from zahnrad.c and zahnrad.h, so the development "cycle" and bug fixing will not fit each other either.

But maybe we could split the demos into 2 files - the loop with GUI and the glue (boiler plate) code.

[vurtun]

But to use it, it seems like one needs to copy paste most of the demo code, before a GUI can be drawn. I know, that this is by design - but what's the benefit?

So far I can definitely say that I will not add any kind of platform dependent code in both zahnrad.h and zahnrad.c. There are multiple reason for my decision to not make a framework but instead try to focus on a reusable component library.

• Currently there is only me as main developer on the actual library with some contributors like dumblob and richi. To actually implement a perfect solution for any backend is not possible and I don't want to create half baked solutions if it is way easier to let the user control the backend. Frameworks like QT only achieve platform independence by having 1000+ developer working on it. So actually creating a framework is not possible and not something I want to do with this library.
• If I would be the one to write each backend then a lot of control would be lost on the user side and so far I personally want to have as much control over a library I use as possible.
• The complexity of in-library loops would require me to add a LOT code and preprocessor defines which would bloat the library to probably at least 3x the size with almost no benefit other than beginners having a simpler start into this library. Personally I do not care for beginners with this library and there are enough frameworks which provide an easier start in GUI development.
• Since there are multiple different ways of using this library (different font handling mechanism, drawing output,...) there would not just one zr_mainloop_x11(my_zahnrad_gui_function); but one for each usage pattern of only one platform.
• Another thing is that if I start to add platform dependent code into the library it will not stop, because the mental barrier to add more platform dependent stuff would be much higher for me. This in term would result into big compatibility mess.
• My last point is that immediate mode GUI's are already hard enough to develop without having to fight different platforms, frameworks and libraries.

But maybe we could split the demos into 2 files - the loop with GUI and the glue (boiler plate) code.

Could you elaborate what you mean by that. So far I am quite happy with the distinction of platform dependent code and the demo.c GUI code. Actually implicitly adding the demo code into each platform would be quite a hassle to maintain. Granted it hurts understanding if both are divided but it is easier for me to keep everything up to date and I have examples inside the example folder which are one file for platform and example, which should help to get a good understanding of the embedding process needed for this library.

[richi]

Could you elaborate what you mean by that.

I guess dumblob accidentally confused the demo.c with the examples. It would be indeed not bad at all, to have the examples a little bit more cross platform :)

[vurtun]

I guess dumblob accidentally confused the demo.c with the examples. It would be indeed not bad at all, to have the examples a little bit more cross platform

Oh ok than I completely misunderstood. I actually thought it would be good to have examples with one file to get a quick overview over all code that would be required to embed the library. In addition I could do things not all platforms support out of the box (for example X11 does not natively support drawing images with different source to destination size or opengl would need stb_image to read in icons for example/demo). If it is something worth doing then I can spend some time to convert all examples.

[dumblob]

Oh ok than I completely misunderstood.

I'm sorry for not being clear. Yes @richi is correct - I meant doing it in case of each zahnrad/example/*/*.c file. To avoid further confusion, I'd like to propose renaming https://github.com/vurtun/zahnrad/tree/master/example/demo to something else (rather not containing the demo string at all).