<ifreund>
daurnimator: am now, are you missing wlroots developement headers somehow?
<ifreund>
daurnimator: am now, are you missing wlroots developement headers somehow?
snakedye has joined #river
snakedye has joined #river
<ifreund>
snakedye: you can map "spawn riverctl mod-option ..." as seen in the default init script on the layout branch
<ifreund>
snakedye: you can map "spawn riverctl mod-option ..." as seen in the default init script on the layout branch
<novakane[m]>
any reasons why you use `std.heap.c_allocator` instead of like `std.heap.GeneralPurposeAllocator`? Performance ?
<novakane[m]>
any reasons why you use `std.heap.c_allocator` instead of like `std.heap.GeneralPurposeAllocator`? Performance ?
<novakane[m]>
can't really find any doc about `c_allocator`
<novakane[m]>
can't really find any doc about `c_allocator`
<ifreund>
novakane[m]: c_allocator is a thin wrapper over libc's malloc, which we are already linking in since we depend on C libraries that use it
<ifreund>
novakane[m]: c_allocator is a thin wrapper over libc's malloc, which we are already linking in since we depend on C libraries that use it
<ifreund>
it definitely faster than the current zig std gpa which is at the moment much more focused on debug safety than performance
<ifreund>
it definitely faster than the current zig std gpa which is at the moment much more focused on debug safety than performance
<ifreund>
the idea is to switch out the implementation depending on zig build mode in the future, but that work has not yet been implemented
<ifreund>
the idea is to switch out the implementation depending on zig build mode in the future, but that work has not yet been implemented
<ifreund>
also using malloc/free means that valgrind works with river which is awesome
<ifreund>
also using malloc/free means that valgrind works with river which is awesome
<novakane[m]>
oh ok make sense then, thanks
<novakane[m]>
oh ok make sense then, thanks
<novakane[m]>
never used valgrind
<novakane[m]>
never used valgrind
<yyp>
river uses GPA in some places though, or not?
<yyp>
river uses GPA in some places though, or not?
<yyp>
util.gpa it was
<yyp>
util.gpa it was
<ifreund>
go look at the definition of util.gpa :P
<ifreund>
go look at the definition of util.gpa :P
<yyp>
-.-
<yyp>
-.-
<yyp>
That name is so confusing
<yyp>
That name is so confusing
<ifreund>
why? it's libc's allocator is a gpa
<ifreund>
why? it's libc's allocator is a gpa
<ifreund>
s/it's//
<ifreund>
s/it's//
<yyp>
When I see gpa, I think of std.heap.GeneralPurposeAllocator
<yyp>
When I see gpa, I think of std.heap.GeneralPurposeAllocator
<yyp>
util.allocator would make more sense
<yyp>
util.allocator would make more sense
<ifreund>
disagree, gpa is more descriptive
<ifreund>
disagree, gpa is more descriptive
<yyp>
util.c_allocator :P
<yyp>
util.c_allocator :P
yyp has left #river [#river]
yyp has left #river [#river]
yyp has joined #river
yyp has joined #river
<ifreund>
and what if I want to swap in the std's gpa at some point for testing?
<ifreund>
and what if I want to swap in the std's gpa at some point for testing?
<ifreund>
util.gpa is the right name here
<ifreund>
util.gpa is the right name here
<ifreund>
it doesn't really matter what gpa implementation is behind it, they all have the same semantics
<ifreund>
it doesn't really matter what gpa implementation is behind it, they all have the same semantics
<yyp>
¯\_(ツ)_/¯
<yyp>
¯\_(ツ)_/¯
snakedye62 has joined #river
snakedye62 has joined #river
drumfreakk has joined #river
drumfreakk has joined #river
drumfreakk77 has joined #river
drumfreakk77 has joined #river
drumfreakk77 has quit [Client Quit]
drumfreakk77 has quit [Client Quit]
<skuzzymiglet>
how would you go about implementing window swallowing in river, since there's no way to associate a window with a pid?
<skuzzymiglet>
how would you go about implementing window swallowing in river, since there's no way to associate a window with a pid?
<ifreund>
first step would be logging the pid of wayland clients that connect to our socket and mapping those to xdg toplevels
<ifreund>
first step would be logging the pid of wayland clients that connect to our socket and mapping those to xdg toplevels
<skuzzymiglet>
would this have to be in the core or could it be a tiler?
<skuzzymiglet>
would this have to be in the core or could it be a tiler?
<ifreund>
that infrastructure would need to be implemented in river itself
<ifreund>
that infrastructure would need to be implemented in river itself
<ifreund>
we probably want it to improve how river assigns tags to views on spawn, currently if a client is started and then the user focuses a different set of tags before the client maps an xdg toplevel the new set of tags is assigned
<ifreund>
we probably want it to improve how river assigns tags to views on spawn, currently if a client is started and then the user focuses a different set of tags before the client maps an xdg toplevel the new set of tags is assigned
<skuzzymiglet>
yeah that would be nice
<skuzzymiglet>
yeah that would be nice
<skuzzymiglet>
I saw on the toplevel-info protocol you wrote, the idea for PIDs got rejected because pids don't map to toplevels
<skuzzymiglet>
I saw on the toplevel-info protocol you wrote, the idea for PIDs got rejected because pids don't map to toplevels
<drumfreakk>
Is natural scrolling on touchpads possible in river? As far as I can tell it is supported by libinput but it requires the window manager to actually configure it, unlike x where you can use xinput or something, and I couldnt see the option in river
<drumfreakk>
Is natural scrolling on touchpads possible in river? As far as I can tell it is supported by libinput but it requires the window manager to actually configure it, unlike x where you can use xinput or something, and I couldnt see the option in river
<novakane[m]>
I don't think there is natural scrolling or tap-to-click on river and I don't think there is libinput support
<novakane[m]>
I don't think there is natural scrolling or tap-to-click on river and I don't think there is libinput support
<novakane[m]>
ifreund: is it hard to support? or is it for an other reason? Cause tbh I missed tap-to-click more than I though and I Iooked how dwl did it and it look liked it was only like 5 more lines
<novakane[m]>
ifreund: is it hard to support? or is it for an other reason? Cause tbh I missed tap-to-click more than I though and I Iooked how dwl did it and it look liked it was only like 5 more lines
<novakane[m]>
probably missed something tho
<novakane[m]>
probably missed something tho
<ifreund>
novakane[m]: implementing any specific libinput config option globally for all devices is trivial
<ifreund>
novakane[m]: implementing any specific libinput config option globally for all devices is trivial
<ifreund>
what I want for river is a input management protocol similar to wlr-output-management
<ifreund>
what I want for river is a input management protocol similar to wlr-output-management
<ifreund>
that is a lot more work, but very worth it especially if I can do the implementation mostly in wlroots and other compositors adopt support
<ifreund>
that is a lot more work, but very worth it especially if I can do the implementation mostly in wlroots and other compositors adopt support
<ifreund>
until then, the libinput-config hack and XKB_* environment variables should be ok
<ifreund>
until then, the libinput-config hack and XKB_* environment variables should be ok
<novakane[m]>
ok good excuse then :P
<novakane[m]>
ok good excuse then :P
<novakane[m]>
didn't know about the workaround tho so I'm gonna try it, thanks
<novakane[m]>
didn't know about the workaround tho so I'm gonna try it, thanks