<jack>
leon-p: "riverctl keyboard-layout -options caps:swapescape" gives me error and says not enough arguments
haliucinas has quit [Ping timeout: 252 seconds]
Snetry has quit [Ping timeout: 245 seconds]
Snetry has joined #river
rossabaker has quit [Remote host closed the connection]
rossabaker has joined #river
kaizo2 has joined #river
br0qn has quit [Read error: Connection reset by peer]
<kaizo2>
i think keyboard-layout has a required argument of which layout at the end (for example i have "us") so i believe it should be "riverctl keyboard-layout -options caps:swapescape $LAYOUT",
kaizo2 has quit [Client Quit]
kaizo2 has joined #river
kaizo2 has quit [Client Quit]
kaizo2 has joined #river
kaizo2 has quit [Client Quit]
kaizo2 has joined #river
kaizo2 has quit [Client Quit]
kaizoplant has joined #river
jack has quit [Remote host closed the connection]
br0qn has joined #river
br0qn has quit [Changing host]
br0qn has joined #river
kaizoplant has quit [Quit: WeeChat 4.6.2]
br0qn has quit [Remote host closed the connection]
haliucinas has joined #river
<ifreund>
leon-p: it should actually reduce complexity of the WM in many less basic cases. Take for example interactively changing the main ratio of the default rivertile layout with the mouse
<ifreund>
before the wm would need to add all windows to the operation with the appropriate resize edges set and then sorta guess the new main ratio at the end of the operation based on the size of the windows
<ifreund>
with the new architecture, the wm can modify the main ratio directly based on op_delta and reuse its existing layout code, which should be much less awkward
<ifreund>
and is also more correct as its easy to handle newly opened windows joining the layout during the resize
<ifreund>
and for the basic resize/move one window cases I dont expect more than 40-50 lines of pretty basic code
<ifreund>
maybe less
Keeto has joined #river
ximon has joined #river
ximon has quit [Quit: Client closed]
deadcade_ has joined #river
deadcade_ has quit [Remote host closed the connection]
deadcade has quit [Ping timeout: 276 seconds]
deadcade has joined #river
pixavi has joined #river
pixavi has quit [Client Quit]
pixavi has joined #river
alexherbo2 has joined #river
flower_ has joined #river
pixavi has quit [Quit: pixavi]
pixavi has joined #river
pixavi has quit [Quit: pixavi]
alexherbo2 has quit [Remote host closed the connection]
Ireozar has quit [Read error: Connection reset by peer]
Ireozar has joined #river
alexherbo2 has joined #river
<lordmzte>
I'm having the issue where librewolf running under river has a larger window that it's supposed to have. The window is bigger than it's border and it renders outside its window border on the right and bottom. This is sometimes fixed by resizing the window. Could this be river's bug?
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
<ifreund>
its probably librewolfs bug
<ifreund>
in theory it could be river's fault, but the last few bug reports of that sort have all turned out to be client bugs
<lordmzte>
Maybe river should clamp the window to it's actual size, cutting off the extra bits instead of drawing them outside the window bounds?
<ifreund>
it could, that would cut off e.g. drop shadows though
<lordmzte>
Well I believe that client side shadows are a bit of a cursed concept anyways :P
<ifreund>
clients commiting a window geometry that doesn't match their buffer is a pretty serious bug though
<ifreund>
lordmzte: with the rwm protocol you will be free to crop them off as you like :)
<lordmzte>
oooh awesome
<lordmzte>
I'm really excited for that one :P
Szadek72 has quit [Ping timeout: 252 seconds]
Keeto has quit [Ping timeout: 260 seconds]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
<leon-p>
a windows "actual size" is a bit of a philosophical issue. most places in wayland, the "actual size" is the size of the attached surface (or the viewported destination geometry)
<leon-p>
client side decoration and shadows is arguably the cleanest / sanest solution IFF all applications use the same toolkit which has decent integration with the display server
<leon-p>
not that any of that matters for firefox and its forks, since they do very cursed things anyway
<leon-p>
currently deciding which is more painful: specificing all 9 * 5 colours of the window decorations by hand, or learning colour space transformation to automatically generate bezel colours from a single specified colour...
<ifreund>
I'm now curious what a window decoration with 45 colors looks like, is it a gradient or something?
<leon-p>
each decoration has two bezels: one inner one outer, each with 4 colours for all directions. Then there is a center colour between the bezels, mimicking the window decoration style of CDE / Motif. Then there are five different decoration "levels" (?): normal, active, hint, slected, important
<ifreund>
ah, I see
<ifreund>
by the way, I think I'm going down the janet path for my personal window manager. I want to play with the nice embedding API rather than going through FFI
<leon-p>
sounds reasonable. you'll get closer integration, won't have to think too much about API and can probably just define some datastructures so that janet code can access them directly
<leon-p>
and you can avoid having to go through the C ABI if you can define janet functions directly from zig code
<ifreund>
janet allows the zig/C side of the program to define its own "abstract types" with custom methods and what not
<leon-p>
I'll stick with bindings for now, but I do have the option later to define scheme functions from zig directly and scratch all the ugly C bits
<ifreund>
it looks pretty comfy
<leon-p>
yeah I saw
<leon-p>
looking forward to whatever magic you'll do :)
<leon-p>
do you go for the pure function approach of updating windowing / rendering state with two functions?
<leon-p>
so far I found the approach of using hooks to be easiely extendable, but it's pretty imperative and might get very messy very quickly when users configure too much weirdness
<ifreund>
I haven't actually gotten to writing any janet code for my wm yet, I've just convinced myself that it's the path I want to seriously try first :D
<leon-p>
yeah, fair :)
<ifreund>
All I've done so far is wrangle my dependency. I plan to write idiomatic bindings for the janet API as I need them: https://codeberg.org/ifreund/zig-janet
<leon-p>
mostly i look forward to seeing how you manage lifetimes across zig/wayland/janet
<ifreund>
I think I'll probably use generational indexes as well, not 100% sure yet
<leon-p>
speaking of, I found that if you add a third field to the key which indicate the object type, you can get typesafety across lists
<ifreund>
hmm, why not just use distinct types for the keys?
<ifreund>
ah, that won't work across the ffi boundry of course
<leon-p>
as far as chicken is concerned, they are all unsigned-integer64
<ifreund>
I think I can get away without that runtime type tag without loosing type safety because of how janet's abstract type API works
<leon-p>
neat
<ifreund>
but yeah, a tag is smart for libantares :)
<leon-p>
although you'll loose typesafety if the key ever leaves your process temporarily, i.e. if it's piped through fuzzel to implement a window switcher
<ifreund>
heh, I hadn't thought of that use-case
<ifreund>
I plan to do everything in my janet process currently
<leon-p>
yeah same
<ifreund>
including bar (if any) notifications (if any) idle mangement, etc
<leon-p>
do you plan on also wrapping dbus to get notifications?
<leon-p>
I am currently thinking about it
<ifreund>
I might just not have any notifications
<ifreund>
I haven't had any for ages currently and I don't miss them
<leon-p>
fair
<ifreund>
but yeah, my wm might talk to dbus
<ifreund>
if there turns out to be a good reason to do so I have nothing against it
deadcade has quit [Ping timeout: 272 seconds]
deadcade has joined #river
alexherbo2 has joined #river
ximon has joined #river
Keeto has quit [Ping timeout: 276 seconds]
Cornelius-Figgle has quit [Ping timeout: 252 seconds]
Cornelius-Figgle has joined #river
ptrckd has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
<leon-p>
turns out I already wrote code to change the luminance of RGB colours once before and forgot. this makes themes a lot easier
ximon has quit [Quit: Client closed]
alexherbo2 has quit [Remote host closed the connection]
<leon-p>
wait... it's literally just multiplying rgb by a factor? why did my mind immediately jump to coordinate transformation when I thought about this?
Keeto has joined #river
Keeto has quit [Remote host closed the connection]
<leon-p>
ok, now that that's solved, coming up with a nice theme isn't painful anymore
ccha1 has joined #river
mx08 has joined #river
ccha has quit [Ping timeout: 272 seconds]
flower_ has quit [Quit: Lost terminal]
crumpet has quit [Remote host closed the connection]
crumpet has joined #river
deadcade has quit [Remote host closed the connection]