Expose some currently internal constructors about haskell-wayland

[abooij]

By default, the constructors should not be exported, since they give access to the underlying Ptr values, which breaks the abstraction principle we want to achieve. More precisely, if we'd export constructors, then users of the library could do pointer arithmetic with windows etc, which doesn't make sense.

However, I understand your use case. One popular approach in these situations is to add .Internal modules that expose all of these constructors, and other implementation details.

I won't do this because I don't like the approach that I took in this project, and so I ceased its development. I think a real haskell wayland library should be an independent wayland implementation, rather than binding to libwayland. I wrote some reasons why in the readme for sudbury.

[Ongy]

sadly that wouldn't work for my usecase either.

Unless we can get the functions from libwayland.so to work on sudburys implementation without breaking things left and right because both libraries asume to be the only way to access internals, things will still break.

Since wlroots (or libweston fwiw) will still bind to the libwayland.so. And (mostly since Haskell code needs to be set up when called from a C main) we can't just use it as a drop in replacement (and to be honest, I wouldn't want to pull GHCs rts into everything).

For me the best way would be to have a small wrapper that exposed the Ptr types.

I see your point about only exposing them from an .Internal module, that's fine with me.
If you don't want to continue this, would you mind if I took over and exposed things as I need them?

[abooij]

get the functions from libwayland.so to work on sudburys implementation without breaking things left and right because both libraries asume to be the only way to access internals

That's exactly what I managed to do for sudbury. For example, the weston demo clients work with sudbury, without recompilation. Sudbury is ABI-compatible with libwayland. (I haven't written the server side yet, and although there are some added snags, I believe it can be done.)

pull GHCs rts into everything

If you want to run haskell code, you'll need a haskell RTS. There's no avoiding that.

[abooij]

If you don't want to continue this, would you mind if I took over and exposed things as I need them?

Sure, it's open source.