6 ms·
It looks cool, though the claim about having no platform dependent code must be false... either they have it or they depend on someone who does. Since it's all
by richard_todd 11y ago
It looks cool, though the claim about having no platform dependent code must be false... either they have it or they depend on someone who does. Since it's all in one file and I'm on an iPad right now, I didn't try to discern which case it is.
What is the appeal of the implementation hiding in the header file? Is it a 'thing' nowadays? It makes every file that includes it read all 15k lines, and makes you put a special #define in one of your source files, just to avoid having a C file. That doesn't feel like a good trade-off to me. If I used this code in a project, I'd build a static library out of it first thing, and go about my business.
- nightcracker 11y ago> 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.
- richard_todd 11y agoAh, 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.
- mmozeiko 11y agoSDL glue code is available under "demo" folder in the repository.
- SolarNet 11y agoIt'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.
- taneq 11y agoInteresting. 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?
- flohofwoe 11y agoSean Barrett (of stb headers fame) has written about the reasons for header-only libraries here: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t... If compile-time is a concern (it isn't in my experience, at least if the rest of the project is C++ code), you can still wrap the library-header into your own header and put include-guards around it :) PS: also see here: https://github.com/nothings/stb#why-single-file-headers https://github.com/nothings/stb#why-single-file-headers
- Avshalom 11y agoBecause apparently archived files are just too much for Windows devs?
- flohofwoe 11y agoDid you ever try to link with externally compiled libraries on Windows? :) It's an absolute mess, the lib files are incompatible between Visual Studio versions, whether threaded/non-threaded/DLL/static MSVC runtime is used, whether linktime-code-generation is used, if there's C++ code in it, a release lib cannot be linked against a debug executable, etc etc etc... Only sane solution is to drop the sources directly into your project. Whether it's just a header or a header/source pair is just a small detail, admittedly.