Demo headers and nk_ and design choices, oh my!

[bolt-blue]

tl;dr

Are the demo headers, e.g. nuklear_glfw_gl4.h intended to be copied and used directly, albeit with any cannibalisation deemed necessary, or are they purely examples of the kind of header we might write ourselves?

If the latter, does the use of NK_API ... nk_... in the demo headers suggest that when writing an equivalent header ourselves, we should "extend" the nuklear API in a similar fashion?

---

I believe this is part of the trouble faced by the OP in #424. The mere use of nk_ for these function protoypes and structs make the header feel like it's part of the library, while I can see they are not really.

So I guess I'm mostly looking for clarity on that design choice, and whether or not to adopt it myself. I get the feeling I should not do exactly the same.

I note that using NK_API can result in the functions being either static ("internal") or extern, which further confuses me a little as to how related they appear to be to the nuklear codebase.

Hopefully that makes at least some sense. I can try to further clarify if necessary.

---

Some waffly background

I'm just trying to seek a little clarity as I am getting to grips with using nuklear for the first time. I'm reasonably ofay with C, but I still have much to learn about "real-world" software writing.

From reading some existing issues I have come to understand a bit more about the library; in particular what problem it's actually solving: creating command buffer lists for drawing UI elements (unless I'm still mistaken).

As I stumbled blindly at first through the docs, wondering why the provided example didn't draw anything on the screen, I realised I had to choose or implement an actual rendering backend.

I opted for glfw for the time being, at least until I get a better grasp on things.

I then struggled to determine how to connect the two together - essentially how to pass the necessary data to glfw.

Eventually I found the examples/ and demo/ directories; I was a bit slow on the uptake :/

Which brings me to the initial questions.

[quadroli]

Hii @bolt-blue 👋 yes, they are meant to be used directly, they are kinda what glue Nuklear together with the chosen backend

You are welcomed to write your own but for the most part they are just drag and drop

Hope that clarifies the matter 👋

[bolt-blue]

Thanks @quadroli, that's ideal.

Might it then be recommended to not edit a copy?

Again, the main reason I ask is because then it would feel like I'm messing with the library which would generally be a bad idea.

I suppose any parts I wanted to change I would write my own code for and simply substitute those aspects.

[quadroli]

The glue code e.g. nuklear_glfw_gl4 isn't part of the library per se, you can mess with it, heck you can even mess with nuklear.h, but for the most part, it's got you covered so that literally all your messing (if not most) will be on your app, the consumer of the api ...

[bolt-blue]

Granted we can of course mess with the files locally, but that's asking for trouble if one wants to have an easier time of pulling potential changes.

I feel more free to edit the backend code from the various demo's.

But then, like I said before, it feels odd mainly because of the naming conventions and use of more "library-specific" macros (e.g. NK_API) and such.

Maybe I'm just overthinking, as is my wont.

[RobLoach]

IF you have additions you believe are missing, feel free to suggest them. F\or the most part, they should work in your platform of choice.

[bolt-blue]

@RobLoach Apologies for not responding earlier. It's fine for the issue to remain closed.

I just wanted to mention that I was not implying that anything was missing, though if I ever do I'll happily make suggestion(s).

I'm not sure how else to explain it other than what I wrote previously.

Oh, and I am happily using the glfw demo as the basis for a current project.