loureir-or-not has quit [Remote host closed the connection]
loureir-or-not has joined #river
loureir-or-not has joined #river
loureir-or-not has quit [Changing host]
loureir-or-not has quit [Remote host closed the connection]
notzmv has quit [Ping timeout: 265 seconds]
sentry has quit [Ping timeout: 246 seconds]
Snetry has joined #river
notzmv has joined #river
Guest0 has joined #river
Guest0 has quit [Client Quit]
fitrh has joined #river
fitrh_ has joined #river
fitrh has quit [Ping timeout: 265 seconds]
dumbmf has joined #river
fitrh_ has quit [Ping timeout: 252 seconds]
fitrh has joined #river
fitrh has quit [Ping timeout: 248 seconds]
notzmv has quit [Ping timeout: 265 seconds]
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #river
fitrh has joined #river
lordmzte5 has joined #river
lordmzte has quit [Ping timeout: 248 seconds]
lordmzte has joined #river
lordmzte5 has quit [Ping timeout: 252 seconds]
notzmv has joined #river
fitrh_ has joined #river
fitrh has quit [Ping timeout: 248 seconds]
<larstiq>
leon-p: I might do silly things with it, like animating the window sizes to visualize computation state ;)
fitrh_ has quit [Ping timeout: 244 seconds]
fitrh has joined #river
Keeto has joined #river
hush has joined #river
hush has quit [Client Quit]
hush has joined #river
<leon-p>
once that new screen copy protocol is a thing and clients can get per-window screen-shots, I am reasonably sure that some amount of animations are doable client side
<leon-p>
although I also wouldn't be opposed to river itself eventually supporting very simple fade-in/out animations of course
Keeto has quit [Ping timeout: 244 seconds]
mtm has quit [Ping timeout: 252 seconds]
mtm has joined #river
hush has quit [Ping timeout: 260 seconds]
fitrh_ has joined #river
fitrh has quit [Ping timeout: 265 seconds]
notzmv has quit [Ping timeout: 265 seconds]
fitrh_ has quit [Ping timeout: 248 seconds]
fitrh has joined #river
fitrh has quit [Read error: Connection reset by peer]
fitrh has joined #river
fitrh has quit [Ping timeout: 248 seconds]
fitrh has joined #river
elshize has joined #river
notzmv has joined #river
<larstiq>
ah, I meant the geometry
<leon-p>
ah, yes of course, I too want my windows to wiggle
<leon-p>
very important for my workflow
fitrh has quit [Ping timeout: 272 seconds]
Keeto has joined #river
talismanick has quit [Remote host closed the connection]
Keeto has quit [Remote host closed the connection]
notzmv has quit [Ping timeout: 252 seconds]
<szgy>
leon-p: pulled from antares/master and updated the code so as to use structs of function pointers and it kinda workss. Declaring that from lua is a little finicky and I don't know if I'm setting up myself for trouble, but we'll see
<leon-p>
I am also fine with adding helper functions to the C lib to simplify writing libraries
<leon-p>
s/writing libraries/writing bindings/
<szgy>
what was on your mind?
<leon-p>
nothing yet, I am waiting for people to complain first :)
<leon-p>
btw, if you want to try how ergonomic your bindings are, try listening for seat-window-interaction and calling antares-window-raise-to-top
<szgy>
I mean, this looks IMO simple enough - and not limiting - . The trickiest part is the ffi to lua, and I imagine some garbage collection stuff
<leon-p>
yeah, I had to wrestle guiles garbage collector as well :)
<szgy>
well, I can't see windows yet. Like, if I spawn foot, the callback for new window gets called, but nothing on the screen (is that expected?)
<leon-p>
you have to explicitly set them to visible and set a size plus position for new windows
<leon-p>
note that river doesn't yet send the position and dimension events for windows, so if you want to use those you'll have to save the ones you proposed to the window
<szgy>
oohw, I forgot about set_geometry!
<szgy>
right, so for now I need to track window 'states', thats fine
<szgy>
do you have a use for that user_data that you added to every hook?
<leon-p>
If you want you can use the user_pointer thing I introduced today for that
<leon-p>
for example if you have a struct with state for a new window, you could set a pointer to that to the user pointer
<leon-p>
it's not very idiomatic for scheme, so in the guile bindings i just ignore it
<leon-p>
and use an alist instead
<szgy>
mhm, handling state manually through the ffi is kind of a drag probably. I think just handling on the lua side for playing makes sense - for now at least -
<leon-p>
if you check the guile bindings, I added three macros to help: object-add, object-drop, object-set-property
<leon-p>
oh, not the bindings, the actual guile WM
<leon-p>
the library shouldn't handle state I think
<szgy>
but the idea for that user_data is to hold arbitrary stuff and every hook recieves a pointer to the same thing?
<szgy>
right
<leon-p>
not the same
<leon-p>
it's per object
<szgy>
object being window, seat, output respectively?
<leon-p>
the global context has one, each window has one, each output has one, each seat has one
<szgy>
cool
<szgy>
makes sense
<szgy>
so much more to exploree
<leon-p>
I borrowed that design idea from libwayland. makes using the lib in C more ergonomic
<szgy>
I find weird that context is recieved and passed everywhere, but not 'actually' used by the bindings
<szgy>
is that to avoid having some internal state?
<leon-p>
it's for things that I have not yet implemented
<szgy>
oooh
<szgy>
I hope is just for a set of wiggle effects
<szgy>
woah, so magical to see a foot window appear. seat callbacks (like pointer interaction) are not triggering yet though...
<szgy>
I lied, win_interaction is being called, but pointer stuff no...
<szgy>
ooh, probably because I havent added seat_focus_window and seat_clear_focus
<szgy>
oh, seat_focus_window crashes it (it seems that same happens to you looking at the comment on antares/antares.scm:101)
<leon-p>
note that river doesn't actually send all events yet
<szgy>
right, as usual, getting ahead of myself :P
<szgy>
ok, good, session for a sunday, gonna go to a park and look at the sun for a while
<szgy>
thanks!
<leon-p>
have fun
notzmv has joined #river
<ifreund>
pointer bindings now work, and i fixed something I broke shortly before committing the xkb_binding support yesterday
lordmzte has quit [Quit: Ping timeout (120 seconds)]
<ifreund>
szgy, leon-p: the only thing the window manager needs to do to make a window appear on the screen is propose dimensions and commit
<ifreund>
windows are not hidden by default, but they cant't be mapped/rendered until initial dimensions are proposed
<ifreund>
I don't think I have the energy to start on pointer move/resize today so I'll probably just fill out some of the simpler missing features
<ifreund>
I'm happy to take requests if there's something in particular you're already trying to use but cant
<leon-p>
I'll take things as they come
<leon-p>
I am already occupied with trying out algorithms for initial window positions
<leon-p>
and trying tiling based on bin packing
lordmzte has joined #river
<ifreund>
seems like sending window position/dimensions would be useful
<leon-p>
true, although I can get by with just storing the proposed geometry
<leon-p>
I would appreciate getting windows preferred size though
<ifreund>
hmm, I have code in river to send river_window_v1.dimensions but it doesn't seem to be working
<ifreund>
or maybe my deduplication is too aggressie
<ifreund>
leon-p: river should now properly send the dimensions event
<leon-p>
nice!
<leon-p>
Although I need a break now myself. I am apparently very good at overengineering an initial window placement algorithm that ends up pretty mediocre in the end...
<leon-p>
Also I just discovered that I want more expressive function dispatch for scheme, i.e. I want to define the same function but which can possible be called (foo '(arg1 arg2...)) and (foor arg1 arg2 ...)
<leon-p>
Probably doable with some macro magic I guess
<ifreund>
leon-p: does scheme not have a "splice" operator?
<leon-p>
it has apply
<leon-p>
(apply function '(arg1 arg2 arg3))
<ifreund>
(+ ;(1 2 3)) expands to (+ 1 2 3) in janet for example
<leon-p>
But working with coords a lot right now what I'd like is being able to call (foo (x y) w h), (foo (x y w h)) and (foo x y w h) interchangibly
<ifreund>
same as (+ (splice (1 2 3))
<leon-p>
I don't think splice that way is possible with scheme, it would break macro hygiene
<ifreund>
ah, makes sense
<leon-p>
what may be possible is a (call-with-common-sense function args) macro, I guess
<leon-p>
would abbreviate to (c/cs ...), fitting in neatly with all the other call-with-... functions scheme already has
<leon-p>
anyway, enough coords for today
<leon-p>
I've simplified the algorithm a bit now, trying to take into account window sizes didn't work out that well, need to try again tomorrow
<leon-p>
or I could search for "largest unoccupied rectangle in area" and read a few papers :)
Alterexe3 has quit [Quit: Client closed]
<ifreund>
computational geometry is a whole field :D
<ifreund>
I should probably expose the min/max size set by the xdg_toplevel to make your life even more complicated :P
<leon-p>
thanks, I appreciate it :)
<leon-p>
ok, those papers aren't light reading, I'll postpone that to tomorrow
talismanick has quit [Remote host closed the connection]
talismanick has joined #river
<ifreund>
there was a subtle bug here that I probably never would have caught if I didn't add that assertion, yay assertions!
talismanick has quit [Remote host closed the connection]
talismanick has joined #river
<ifreund>
leon-p: fixed
<leon-p>
can confirm, nice!
<leon-p>
oh no, I just discovered that emacs, when click-dragging on the internal border, completely bypasses the resize request mechanism and just resizes it's window
<leon-p>
every day a new abyss awaits
<ifreund>
classic :D
<ifreund>
I just pushed a new river_window_v1.dimensions_hint event and an implementation
<ifreund>
that's it for today though, pretty productive :)
<leon-p>
very nice!
<leon-p>
does setting a dimension of 0,0 and letting the client choose its windows dimensions itself also work if the window is not visible?
<leon-p>
Because I'd like to wait until the client has decided on a size before calculating initial position