<szgy>
@leon-p: I tried to use antares from luajit using its ffi. It doesn't work yet but I feel it cloose
<szgy>
(given that I only experimented with it for like, 2 hours...)
<szgy>
My roadblock until now: calling `antares_run` returns 2 (so missing an interface). Printing the error string (`context.error_info.str`) returns `river_window_manager_v1`
<leon-p>
szgy: rivers window manager protocol only exists in the rwm branch
<leon-p>
it will not work with any river release or rivers git master
<szgy>
ooh, I thought that with the xml and the generated {c,h,o} file on the protocol folder was enough!
<leon-p>
nope, the server has to implement a protocol as well for it do work
<szgy>
heh, makes sense.
<leon-p>
also, don't access context.error_info.str directly. struct fields are considered private and not stable, use the provided function to get the error info string
<leon-p>
not that anything in the library is stable right now anyway
<szgy>
I used that 'cause the function mentioned in the comments didn't existed (probably because I didn't git pull maybe?)
<szgy>
so, to test this I should: 1. compile river on the wm branch, run it and somehow run antares inside?
<leon-p>
yes
<leon-p>
`export WAYLAND_DISPLY=wayland-X` is your friend, where X is whatever number the rwm river uses
<leon-p>
note that you can run that build of river nested inside your regular one, which makes testing a lot easer
<szgy>
oh, so like. If to processes share the same `WAYLAND_DISPLAY` they would be talking to the same server??
<leon-p>
the function does exist btw, I just forgot to put it into the header file.
<szgy>
*two
<szgy>
(oh, cool!)
<leon-p>
WAYLAND_DISPLAY basically just tells the client what socket to connect to
<szgy>
ohh thats handy
<leon-p>
note that the rwm branch is also still in development, so don't expect perfection, all very mushc still work in prograss
<leon-p>
*much
<szgy>
nnaah, of course not! I've been following development and interested on creating a lua compositor on top on river. Just sloowly getting accustomed to all the wayland protocols stuff...
<leon-p>
also I haven't exposed all events / requests yet in antares, so it can't do a lot yet
<szgy>
e.g., For me, reading the protocol files gets hard pretty soon; and more so translating that to an api in my head. So, yesterday I experimented with creating luadoc type annotations from an xml. That way I wouldn't have to parse c code with my mind and rely on autocomplete
<szgy>
yeah, its just to get a hang of it (also, never used luajit ffi before, so also learning that...)
<leon-p>
the XML is usually easer to read than the generated .c .h files
<leon-p>
szgy: let me know how the lua FFI thing goes. antares is designed to be easy to bind in high-level languages, but so far I have only actually done so from guile
<leon-p>
guiles FFI is pretty weak, which caused me to not have any structs in the API
<szgy>
at a glance, the limitation seems to be that luajit doesn't admit preprocessor macros. So I had to edit `antares.h` to delete the `#ifndef`, etc from the top
<leon-p>
ah. Guiles FFI doesn't parse any header files at all, so I just hardcoded all functions signatures
<leon-p>
and I kinda expected most language bindings to do the same
<leon-p>
I have a very lovely scheme macro for binding a C function, makes it quite simple
<szgy>
you hardcoded in guile directly, right?
<leon-p>
yes
<leon-p>
meaning I call (foreign-library-function antares "antares_run" #:arg-types (list '*)) and bind the result to a local function inside a proper scheme function
<szgy>
right, so you type the function from scheme, makes a lot of sense
<szgy>
yeah, I had to do this weird thing were I copied the header to a new one and remove the macros. Wondering if removing `#include` calls would give me issues...
<szgy>
e.g. I had some error loading the header that I pinpoint to references to `wl_list`, which is defined in `wayland-util.h`. So I basically copied over the definition struct to the header
<leon-p>
I see
<szgy>
and there are a bunch of references to wl_* stuff (like `wl_display`), no idea why `wl_list` was the one that cause the failure...
<leon-p>
for language bindings it's likely best to treat pointers to antares_context/window/output/seat as opaque (maybe even as void*)
<szgy>
don't know the meaning of that (treating them as opaque)
<szgy>
is it like "blindly knowing whats inside" ? ?
<leon-p>
It's "I have a pointer to an object, but I have no idea what that object is or what is inside of it"
<szgy>
mh. That means that I e.g. I could treat the `antares_window` members as void* without worrying about its types? (so, I shouldn't care about what a `river_window_v1` is, only knowing what it exposes?)
<szgy>
mmm, maybe I'm not explaining myself right...
<leon-p>
you never have an antares_window struct, you only ever have a pointer to that. as such you don't need to know it's size, which in turn means you don't need to know what's inside
<leon-p>
looking at the luajit FFI docs right now, you can probably use ffi.cdef and copy all functions you wish to use into that string, changing pointert to be void*
<leon-p>
depending on how advanced that parser is, you can probably also give it `struct antares_window;` and since all later references to that are a pointer, it should not complain
<szgy>
mh. at least at a glance that doesn't work (tried it with `wl_list`, just adding `struct wl_list;` to the header...)
<leon-p>
🤷 not a lua expert; I just know how the FFIs of scheme, julia and python work
<szgy>
well, e.g. `wl_list` is not used as a pointer (I think?). e.g. `link` is a member of `antares_output` of type `wl_list`; but its not a pointer its a value
<szgy>
If I change every appearance of `wl_list` to being a pointer it compiles the code, buuut, that couldn't be right
<szgy>
yeah, no problem, this is just me not knowing C :P ...
<leon-p>
no, but you could remove the entire antarea_output struct, replace it simply with `struct antares_output;`
<leon-p>
same for antares_window and antares_context
<leon-p>
poof no more magic wayland types
<leon-p>
and those antares_* struct are only ever accessed by pointer
<szgy>
mHh. I've just tried that and it didn't work... e.g. defined `antares_context` only as `struct antares_context`. And if I tried to access some member from lua (e.g. `context.run_status`) it fails...
<leon-p>
of course, because you are not supposed to access members :)
<leon-p>
check the guile bindings, no members accessed anywhere, it just calls functions
<leon-p>
you should treat all of antares's structs as block boxes; if you care about what's inside, you're doing something wrong
<szgy>
jajaj OHHHH
<szgy>
looking at `guile/antares.scm` the functions you talk about are the hooks passed to the `get_context` and like `antares_run`, `antares_connect`, etc, right?
<szgy>
not much more, right?
<leon-p>
the hooks are a concept of the binding, the C library doesn't know anything about them. They get called from the callback function pointers passed to get_context
<szgy>
right. I think I'll get more a hang of it once I get it _actually_ running. But for now, thanks! don't want to bother you anymore with this :)
<leon-p>
it's no bother, don't worry :)
<szgy>
it helped to know that I don't actually need to have a header matching everything, just the minimal stuff that I want/need to call. As to what it is, TBD
<leon-p>
call antares_get_context() with function pointers to your event handlers (this is the one ugly part of the library), call antares_connect(), then antares_run()
<leon-p>
if an event happens, the event handler you put into antares_get_context() will be called
notzmv has joined #river
<szgy>
and e.g. If I want the client to create a window? I would be able to do that from the handler to `new_output` e.g.?
<leon-p>
it can't do that yet
<szgy>
HEH, OK! getting ahead of myself
<leon-p>
also I am not sure why you'd want the window management library to create a window; It's more meant to handle other programs windows
<szgy>
but _the idea_ is to handle everything from those hooks you set up when calling `antares_get_context`, right?
<szgy>
(or maybe this idea will change in the future...)
<leon-p>
basically yes
<szgy>
allrighty theen
<szgy>
cool
<szgy>
is it your plan to add other dynamic language bindings to the antares repo? (I can try it with lua, if you're interested in it)
<leon-p>
yes, once the C library is in a good shape and I am done with the guile library
<leon-p>
I was planning on adding julia and python
<leon-p>
and re-implement the same reference window manager in all languages which have bindings
<szgy>
that's pretty cool
<leon-p>
ifreund: see recent commit, it should now work without needing to do anything with the paths
<leon-p>
(if you stay in the repo root when calling it, library lookup is messy)
<leon-p>
szgy: you probably also want to read the protocol itself, since antares will only be a thin wrapper around that
<leon-p>
the only thing I plan on abstracting heavily is creating desktop widgets
<leon-p>
(I hope y'all like sceumorphic designs, bezel borders and the looks'n'feels of window maker and CDE, no flat or round things to be seen anywhere)
<szgy>
yeah, I'm mostly using the protocol as a reference and also to try to generate luadoc type hints to ease writing the wm itself
<leon-p>
anyway, I need sleep now; I'll be back tomorrow if you have more questions o7
<szgy>
probably gonna nag you soon heh! have a good night sleep! (I should also get away from the computer now and get smth to eat?)
<szgy>
mh, just tried building river on the `rwm` branch, run `./zig-out/bin/river` with WAYLAND_DISPLAY=wayland-T and got an error that it can't connect to a display...
Snetry has quit [Ping timeout: 265 seconds]
sentry has joined #river
<szgy>
I'm sorry -> `WAYLAND_DISPLAY=wayland-2` I meant to write...
<szgy>
with setting WAYLAND_DISPLAY to a different value and running river on the rwm I won't run. If I set WAYLAND_DISPLAY=wayland-1 (so, the original value, where stable river is hooking up to), river on the rwm branch runs
<szgy>
buut, when I try to run the client using lua I get the same status error (so, no `river_window_manager_v1` supported...)