go-sdl2
go-sdl2 copied to clipboard
veandco
sdl.Main() and sdl.Do() onerous
I completely understand why there is sdl.Main() and sdl.Do functions, and I'm sure that playing nice with SDL's threading is pretty difficult, but I just wanted to provide some feedback that the suggested patterns of use with those two functions don't leave much room for structuring of client code.
go-sdl2 is likely to be used with other libraries, and this pattern can make it difficult to adopt go-sdl2 without having to bend everything else to this requirement. If this pattern is still under development, I would humbly ask the maintainers to consider a different solution.
Hi @bartgrantham, I can see how it takes over the client code in that way makes it a pretty rigid library. I will consider an alternative approach that empowers the clients to use it more flexibly. I probably won't be very active until after Chinese New Year but after that I should have come back and I will think this through!
Thank you for the consideration. I try not to open "complaint" issues without having an alternative to suggest, however in this case I am at a loss but I felt it was worth providing the feedback anyways.
As I get more familiar with the library perhaps I'll have an idea or two. If I do I'll add them here for whenever development picks up again.
Looking through the code supporting Main/Do, what you've already implemented is pretty much the only idea I had! (ie. a loop on the main thread pulling anonymous functions from a channel and calling them)
It appears that SDL is hard-wired to require certain functions to only run on the main thread, presumably as a precaution against clobbering internal data structures and not because OS libraries require it. That's very frustrating. It's too bad there no "I'll handle locking, thank you" version of SDL.