plredmond / gpipe-glfw Goto Github PK

@sorki @SwiftsNamesake @grtlr @Kludgy @LinuxUser404 @MaciekFlis @bch29

Hello! I'm thinking of making some breaking changes to GPipe-GLFW to simplify the codebase.

• If you don't care about this, please let me know below and I'll remove your name from this issue so you don't get any more notifications. Sorry!
• If you do care about this, please read below and let me know whether these changes would cause you trouble in your projects.

GPipe-GLFW code is too complex because it was originally supposed to support multithreaded use. Since that was removed from GPipe, the corresponding code in GPipe-GLFW could be simplified too. I'm thinking of making some potentially breaking changes as a result.

• Do you, in any way, call GPipe or GPipe-GLFW functions from another thread? (If so, how? This isn't supported in ContextT currently)
  • If I remove the automatic RPCing of GLFW calls to a "correct" thread it could break multithreaded code, if any exists.
• Do you use the "mulitple contexts" or the "multiple windows" feature of GPipe?
  • If I remove this feature from GPipe-GLFW it would dramatically simplify things, but it would no longer be a correct implementation for GPipe. I'm curious whether anybody uses it.
  • Multiple contexts is kind of pointless since ContextT provides no way to fork a thread, but multiple windows might be a thing that people use.
• Do you use the "mainloop" or "mainstep" functions in GPipe-GLFW?
  • I'm considering simplifying or removing these.
• Would it break your code if GLFW callbacks were changed from IO to ContextT?

See also tobbebex/GPipe-Core#77

The application I've built recently is like hybrid CLI/GUI thingie and its output gets interleaved with debug messages.

Would you accept a PR changing debug function to debug = const $ return () while retaining the old one as e.g. debug' so it can be switched if needed?

Btw thanks for setWindowSizeCallback, I've added it and noticed it's already there during rebase!