> does not have any dependencies, a default renderbackend or OS window and input handling but instead provides a very modular library approach by using simple input state for input and draw commands describing primitive shapes as output.
It seems that you're expected to provide the layer between the OS and nuklear. They probably have some default implementation for demo's and stuff.
Ah, I read that three times on the site but it didn't sink in until I saw your comment. I guess with a title like "GUI toolkit" my expectations were set incorrectly. Thanks for that!
So, you glue it to the OS yourself. That's... well actually I guess if someone marries it to SDL it could be very useful.
It's nice because your backend doesn't matter. If I have a custom rendering platform I can probably spit out an image. But if I don't want to write a gui library or hook up some BS like QT, this is a super simple solution. I have three projects for three different clients which can use this, for at least internal debugging.
Interesting. So to answer the other poster who complained about the use of pixels rather than "display units", your lower 'glue layer' could accept dp in the input and scale the output to provide density-independent behaviour?
It seems that you're expected to provide the layer between the OS and nuklear. They probably have some default implementation for demo's and stuff.