<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...)
<szgy>
nevermind. It seem that I should set WAYLAND_DISPLAY to be `wayland-1`. If I run river on the wm branch and then the lua script it works (but I can't call the lua script multipletimes, only once)
<szgy>
some `sync` event was produced, and If I resized the window that contains the rwm I would get some `output`, `output dimensions` and `output position` events, pretty neat!
<szgy>
Well, I got a bunch of stuff working (can log window dimensions an initial position), this is where I'll mantain my fork for now -> https://git.sr.ht/~szgy/antares
<szgy>
(if someone is curious...)
notzmv has quit [Ping timeout: 265 seconds]
dariasc has quit [Ping timeout: 240 seconds]
<ifreund>
szgy: WAYLAND_DISPLAY is defined by the wayland server (river) and read by clients to connect to the server
<ifreund>
that is to say, you should leave it alone when running river and set it to the appropriate value when running client you wish to connect to river
<ifreund>
leon-p: nice, works for me :) I now only need to patch -I/usr/local/include and -L/usr/local/lib into the makefile as I'm on my FreeBSD machine currently
<ifreund>
doing make CFLAGS=-I/usr/local/include seems to completely override the value defined in the Makefile despite the +=...
* ifreund
is not a makefile enjoyer
<ifreund>
probably one needs to do CFLANGS=$(CFLAGS) + ... or something
<ifreund>
leon-p: anyhow, definitely let me know if there are specific rwm features that are blocking your progress
<ifreund>
I plan to work on keybindings next
<ifreund>
but there are a ton of more minor features that probably wouldn't take long to implement if needed
notzmv has joined #river
p00f has left #river [ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)]
elshize has quit [Ping timeout: 248 seconds]
fitrh has joined #river
fitrh_ has joined #river
fitrh has quit [Ping timeout: 244 seconds]
fitrh_ has quit [Quit: fitrh_]
fitrh has joined #river
belanthor has joined #river
Keeto has joined #river
Keeto has quit [Remote host closed the connection]
Keeto has joined #river
fitrh has quit [Quit: fitrh]
Keeto has quit [Ping timeout: 246 seconds]
belanthor has quit [Quit: Leaving]
<leon-p>
my major progress blocker right now is on my end: I need to define wrappers and callbacks for all requests and events before I can do actually anything initeresting
<leon-p>
although I noticed that on startup I don't get a new-output event and windows which exist before the wm also don't get advertised immediately. only after launching another foot instance does the output and the early window get advertised.
<leon-p>
and initial output dimensions are wrong (0,0) unti I resize the river window
<leon-p>
szgy: you should only capp antares_error_info_str() after the missing interface error, otherwise it is undefined. The header file should tell you when you are allowed to call it. It also asserts it anyway.
<leon-p>
ifreund: can't you add /usr/local/include to LD_LIBRARY_PATH and C_INCLUDE_PATH ? I think that is more canonical for system paths than using -L / -I
mtm has quit [Ping timeout: 244 seconds]
mtm has joined #river
graves has quit [Quit: WeeChat 3.5]
graves has joined #river
<sewn>
since you can configure river with any language, has anyone actually done it with languages like lua (trying atm) or python? even C seems probable
<leon-p>
I have seen both lua and C in the wild
<leon-p>
and now I have to debug my first "illegal instruction (core dumped)", that will be fun...
<szgy>
heheh
<szgy>
sewn: I use lua to configure river (used to use fennel, which is a _sort-of_ lisp that compiles to lua)
<leon-p>
decided today to keep the last ~5 closed windows / removed outputs around so that antares can raise an invalid object error rather than core-dump, which would have saved me an hour today
<leon-p>
I wouldn't be that paranoid in a self-contained project, but since the entire goal here is to encourage experimentation, some QoL is a good idea I think
<leon-p>
also kinda hard sometimes to figure out whether antares segfaults are indirectly caused by river segfaults 🐈⬛
<sewn>
I'm stealing thx
<leon-p>
don't get too excited over configuring river, 1100 get's closer every day which will throw out all the old configs :)
<szgy>
heheh! at that point you will be able to use lua to configure it but without doing weird shelling out and just calling functions from a module :)
<ifreund>
leon-p: feel free to ping me with a antares commit that reproduces a river crash whenever :)
<leon-p>
the crashes aren't deterministic :/
<ifreund>
oh that's no fun :/
<leon-p>
sometimes it's opening / closing foot a lot, sometimes it's resizing the river window...
<ifreund>
well I guess I shouldn't be surprised that I have some races in my relatively untested complex async state machine
<leon-p>
fair :)
<leon-p>
fwiw at least the illegal instruction error went away after getting rid of another core-dump, so it probably just was guiles stack unwinding not playing well with the FFI code gen and whatever unholy dark magic libffi does in libwayland
<leon-p>
ifreund: would rivers crash logs help you? I can collect a few
<szgy>
leon-p: seeing all the handlers you added, I'm guessing passing all of them (in a specific order) is going to be the less _ergonomic_ part of antares
<leon-p>
yes, as I said that's the one ugly bit of the library
<leon-p>
and why language bindings should be part of the library
<szgy>
right. have you thought of passing them as structs of function pointers? (so like, a struct for all `output` handlers, another with `window` handlers, etc.)?
<leon-p>
I would of course prefer to wrap all the handlers in a struct, but I don't think guiles FFI can do that 🤷
<szgy>
ohh, you beat me to it...
<leon-p>
I'll re-visit that again later I think, but the documentation of guiles FFI is outdated and full of things which are now actually discouraged, so I need to read the source everytime I want to know something
<szgy>
I see you mentioned river crashing when spawning foot, are you spawning it inside? and if so, how?
ramblurr has joined #river
<leon-p>
just as I launch antares: from a terminal by setting WAYLAND_DISPLAY
<szgy>
ooh, right, cool
<ifreund>
leon-p: I can no longer make river crash by resizing the window while antares is running
<ifreund>
antares does crash though
<ifreund>
river will also send an update immediately when the window manager global is bound now
<leon-p>
nice!
<leon-p>
let's find out what valgrind thinks about that crash
<ifreund>
river commit 0b071f4ef122, antares commit 93ff7cd46
<ifreund>
anyhow, I will need a stack trace or be able to reproduce the crash myself in order to be able to do anything about it, please do share if you get more info!
<leon-p>
kinda weird, heap corruption is not exactly a common issue
elshize has quit [Ping timeout: 265 seconds]
<leon-p>
huh, so xfdesktop now works with river, which means you could now have desktop icons (no idea why you would want to though) and a wallpaper cycling through a directory (this is neat)
<leon-p>
in theory the panel also works, but without foreign toplevel activation support and without that over engineered workspace protocol it's not very useful I think