-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demo headers and nk_ and design choices, oh my! #611
Comments
Hii @bolt-blue 👋 You are welcomed to write your own but for the most part they are just drag and drop Hope that clarifies the matter 👋 |
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. |
The glue code e.g. |
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. Maybe I'm just overthinking, as is my wont. |
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. |
@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. |
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" thenuklear
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 thesefunction protoypes
andstructs
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 eitherstatic
("internal") orextern
, which further confuses me a little as to how related they appear to be to thenuklear
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 withC
, 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/
anddemo/
directories; I was a bit slow on the uptake :/Which brings me to the initial questions.
The text was updated successfully, but these errors were encountered: