3 ms·
If you remember, we've talked over irc =) I actually at first tried to improve upon libwm, but didn't go too far with it. There were some design points I disag
by scoopr 15y ago
If you remember, we've talked over irc =)
I actually at first tried to improve upon libwm, but didn't go too far with it. There were some design points I disagreed with, and you've seemed to stop updating, so I've started prototyping on my own codebase. I wanted some simplicity, and make it easier for various ffi-bridges, so I went with plain c.
The code is too raw, so I won't link to it, but I'll definitely make some noise when I think it is at usable state.
- exDM69 15y agoThe FFI point was a factor why I have not used/updated libwm recently. libwm is C++ with constructors, destructors and exceptions. The semantics of C++ make it poor for FFI. Some interpreter-based languages can somewhat do it (e.g. python), but on a compiler based language like Haskell it becomes a bit painful. Another factor was that libwm supports a lot of legacy API's, like GLX 1.0. I wanted to support my g/f's crappy intel based macbook because at the time I was sometimes stuck that as my only computer. Anyways, the morale of the story is: don't write system level libraries in C++ unless you want to spend the rest of your life writing C++.