5 ms·
On Mac I finally got the example to run had to brew install glew and glfw3 and change the makefile to point to the include and lib paths. A lot of the interacti
by soheil 6y ago
On Mac I finally got the example to run had to brew install glew and glfw3 and change the makefile to point to the include and lib paths. A lot of the interactions don't seem native, for example tap to click doesn't work, I have to do hard clicks on my Mac. Also dragging doesn't seem to work like other apps, it stops dragging if go outside the boundaries of the element. Overall this is pretty epic and I wonder if serious alternatives to XCode and JS based wrappers like Electron are possible.
- mike_d 6y agoBased on the gallery of examples it looks to be focused on what you might call "full screen" applications, like games. In these use case consistent cross-platform interaction is more important than feeling "native" on any given platform.
- jki275 6y agoYou may have an issue with your installation of glew and glfw -- I didn't have to make any changes to the makefile to build the examples.
- soheil 6y agoProbably my env paths are not set correctly with brew on my M1 Mac.
- jki275 6y agoAh -- brew is definitely not mature on the M1 Macs yet as I understand it. I've been on the fence for a couple of months over this -- I want to grab an M1 Mac for R&D type stuff, but at the same time I want to wait until they release the 16" with a hopefully upgraded M1 of some sort.
- soheil 6y agoYou should probably get one anyway, it's incredibly life changing. You can always sell it on eBay after the 16" comes out, they hold on to their value pretty well.
- jki275 6y agoI really should. lOL. Thing is, I literally just bought this maxed out i9 less than a year ago and it works perfectly!
- flohofwoe 6y agoThe tap-problem depends on how the input integration is done, I've been running into similar problems in Dear ImGui (and Nuklear too). You need to implement your own little input event queue which tracks button up- and down-events and still creates a "click" even if both happen in the same frame. TBF, it's a common oversight when creating an input polling layer over event-based input, and usually it only shows up with touchpads, because physical buttons are usually too slow to trigger up and down in the same frame. Check the sokol-headers integration example here, this should properly detect short touchpad taps: https://floooh.github.io/sokol-html5/nuklear-sapp.html https://floooh.github.io/sokol-html5/nuklear-sapp.html
- flohofwoe 6y agoThe "drag doesn't work outside widget boundaries" seems to be a mix of Nuklear-specific and platform-specific problems. It seems that scrollbars don't loose input when the mouse is not over them, but slider widgets do (that would be a Nuklear specific problem). For the problem that an app might lose mouse input when the mouse moves outside the window boundary, this must be handled differently depending on the underlying OS. For instance on Windows you need to call SetCapture() [1]. The platform integration isn't handled by Nuklear itself, so you'll see different problems like this pop up depending on how carefully the platform integration has been implemented (the official samples should be in better shape though I guess). [1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setcapture https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...