search

slobo / Perl6-X11-Xlib-Raw

Perl 6 Xlib::Raw
Artistic License 2.0
2 stars 4 forks source link

X11 namespace heads up #1

Open skids opened 8 years ago

skids commented 8 years ago

Hi, I just wanted to let you know I'm also working in this namespace, on a libxcb-based binding, so we can pool resources or just try to keep from naming collisions.

skids/perl6-xcb is the repo.

It's not ready for ecosystem integration yet, but is starting to get to a useable state.

slobo commented 8 years ago

Nice! I think that there are some structs / definitions that are common to both Xlib and XCB, perhaps it does make sense to make a single project to cover parts of both? My thinking is that there should be a set of X11::*::Raw packages that just provide thin veneer via NativeCall, and then separate Perl6ish interfaces on top of that. Open to any suggestions / collaboration.

slobo commented 8 years ago

Also, my initial inspiration for starting Xlib::Raw was to make a window manager in p6, and XCB is probably a way better choice for that anyways :)

My focus is temporarily shifted in auto-producing useful API documentation from the pod in the source (i.e. documenting all the struct members etc).

(btw, sorry for late replies, just saw your issue few moments ago, i'll double check my notification settings)

nrdvana commented 7 years ago

Hi! Small world. I just recently took over maintenance for perl5's X11::Xlib to add a bunch of functionality I needed for my project. It would be neat if there was a way to converge on API such that upgrading from perl5 to perl6 was easy...

slobo commented 7 years ago

Neat!

Right now p6 X11::Xlib::Raw only concerns itself with straightforward, pretty much 1:1 mapping to C Xlib API. I see that p5 X11::Xlib includes a nice OO interface - would be nice to have something similar built on top of ::Raw, maybe released as separate X11::Xlib module?

Is there anything you would change in the p5 OO Xlib interface, such any usage pain points? Can you think of any p6-only feature that would make it kick more ass?

nrdvana commented 7 years ago

I was also aiming for a 1:1 mapping to Xlib on the root module, then the other sub-packages are just sugar to make real applications easier. Though for the structs, with perl5 my options were either to fully inflate/deflate every struct from a hashref, or to give them all XS wrappers. I chose the latter for performance. But, I also had to do something about the functions that return arrays. For instance XQueryTree which returns a pointer reference that needs freed afterward. I chose to convert those to a return list rather than populating a user-supplied arrayref. On that note, how do you free that memory? I don't see anything in your example or library...

Biggest pain point was probably the giant wad of XS for accessing the fields of XEvent. I ended up parsing the header file and writing a code generator. Looks like perl6 has that nicely taken care of, though I suppose a code generator might help you finish out the rest of the structs. (I don't suggest using mine; it's a total mess)

Other things that probably need some consideration are Xlib's mandatory termination of the program on a disconnect, and need to call XInitThreads as the very first call to the library if the program is multithreaded. For perl6 you might just want to do that unconditionally. I'm still on the fence for perl5. There could be derived modules (Like VideoLAN::LibVLC that I considered writing) that would need it, but in general it would just slow things down.