waleee-cl has quit [Remote host closed the connection]
waleee-cl has joined #river
waleee-cl has quit [Ping timeout: 268 seconds]
Evo2 has quit [Remote host closed the connection]
Evo2 has joined #river
awildthorp has quit [Quit: Leaving]
Evo2 has quit [Remote host closed the connection]
Evo2 has joined #river
snakedye has quit [Ping timeout: 250 seconds]
notzmv has quit [Ping timeout: 268 seconds]
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 268 seconds]
mekss has quit [Remote host closed the connection]
mekss has joined #river
mon_aaraj has joined #river
notzmv has joined #river
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #river
snakedye has joined #river
pkap has joined #river
s1dsq has joined #river
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
_whitelogger has joined #river
dbuckley has joined #river
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
elshize has quit [Remote host closed the connection]
trav41228 is now known as travankor
<novakane>
I was thinking about the view manager protocol design, what if we have 2 more interface like river_view_decoration_manager and river_view_decoration to handle borders color, width...
<novakane>
I was thinking about the view manager protocol design, what if we have 2 more interface like river_view_decoration_manager and river_view_decoration to handle borders color, width...
<novakane>
sorry for the double message... shitty neighbour's wifi ^^
pkap has quit [Ping timeout: 256 seconds]
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
<tiosgz`>
leon-p: re 399, View.shouldTrackConfigure returns false for floating views; i guess it has to be rethought now that there's something to sync with
<tiosgz`>
(changed to check that pending.{x,y} == current.{x,y} and it's somewhat smoother now)
<leon-p>
tiosgz`: I'll read the PR again real quick to remember what I did and get in the right head space, I'll get back to you later
<leon-p>
has been some time since I touched that :D
<leon-p>
note though that 399 is blocked by some funky business in the transaction system
<leon-p>
and I am definitely not touching that right now ^^
<ifreund>
tiosgz`: river's transaction system currently works a bit differently than sway's, there is no queue only a single pending state
<ifreund>
which means if another change occurs while a transaction is in progress that new change is foleded into the pending state and new configures are sent
<ifreund>
the transaction timeout isn't reset though
<ifreund>
this works great for views in the layout and is a lot simpler than what sway does IMO
<ifreund>
however this does not handle interactive resize well at all if you try and push that through the transaction system
<ifreund>
so we just ignore views that don't affect the layout while performing transactions currently
<ifreund>
But since #399 changes things so that the x/y coordinate of views can change due to resize instead of just the width/height, our current approach of immediately applying the pending state no longer works
<tiosgz`>
ifreund: i don't know how sway's system works, don't compare anything to that :D
<ifreund>
noted :D
<ifreund>
anyhow, this is a non-trivial problem and I'll probably want to solve this myself
<ifreund>
the obvious immediate/least invasive solution would be to add a queue of pending configures that we use for floating views
<ifreund>
however then we might want to just go all the way and have a transaction queue like sway instead of a single pending state for each view
<tiosgz`>
if i understand correctly, the transaction system is only designed to work with tiled views, and new code should be written for floating?
<leon-p>
let's just remove floating views entirely
<ifreund>
it was designed to work for floating views too, but we only had simple bottom right corner resize back then which didn't touch the x/y coords
<tiosgz`>
yeah, they're crap :P
<ifreund>
I think we actually did have the transaction system before we had floating views though yeah
<leon-p>
well, when there eventually is a window management protocol, all windows will be floating as far as river is concerned
<ifreund>
that's not set in stone, but yeah river probably won't know any difference between tiled/floating
<ifreund>
which means that making the transaction system use a transaction queue is probably the right long term solution
<ifreund>
I also want to incorporate *everything* into the transaction system though, including outputs and layer surfaces
<ifreund>
I think the scene graph refactor should probably come first though before I get into the weeds there
<tiosgz`>
won't mess into 399 for now then (leon, you bad advisor! :D)
<tiosgz`>
thanks for the lecture!
<ifreund>
no problem! This is the trickiest part of river's code for sure
<ifreund>
it's worth it though for that addicting frame perfection :D
<ifreund>
now what might be really fun is figuring out why that wlr_output is failing...
<novakane>
ifreund: speaking about thath, you had time to works on the scene graph for river?
<ifreund>
novakane: no, I haven't started yet but hope to break ground on that in the next few days
<ifreund>
#508 is annoying to debug too as it won't reproduce in a nested session afaict
<ifreund>
only with the DRM backend
<ifreund>
pretty sure a wlroots change from 0.14 to 0.15 triggered it, but river could very well be doing something wrong
<novakane>
cool, I assume you already know what you need to do broadly speaking since you worked on the PR upstream
<ifreund>
novakane: yep, I'm pretty familiar with how the scene graph works and how to use it. Porting river to it will mostly be relatively easy refactoring for me, but still a lot of work.
notzmv has quit [Ping timeout: 268 seconds]
<leon-p>
I decided to go through with that protocol; would not have guessed that the biggest hurdle is finding the merge request button -_-
<novakane>
ifreund: yeah I imagine this is still a lot, exciting stuff though
<novakane>
leon-p: on gitlab?
<leon-p>
yep. I found it now, but I did search for a while :P
<leon-p>
A client impl is trivial and I should find some time for a server impl this weekend.
<novakane>
leon-p: not surprising, with all the things there is on this UI
<ifreund>
leon-p: Nice! Might want to wait a bit for people to leave comments and see whether there is consensus on the general direction before starting the server impl
<leon-p>
yeah, that makes sense
snakedye has quit [Ping timeout: 256 seconds]
snakedye has joined #river
<ghostbuster>
i turned my river session into horizontal tiling and not sure how to get it back vertical
<novakane>
ghostbuster: you use rivertile?
<novakane>
if you use the example config IIRC the keybinds are 'super' <arrow>
<novakane>
or `riverctl send-layout-cmd rivertile "main-location top"`
<ghostbuster>
thanks that did it
<ghostbuster>
very confusing that main-location top means your primary window goes on the right...
<ifreund>
hrm? no it doesn't
<ghostbuster>
with two windows, main-location top makes it split so one window is on the left and one is on the right
<ghostbuster>
main-location left splits so one is on top and one bottom
<ifreund>
That's not what happens on my end
<ghostbuster>
heh
<ghostbuster>
i've created an interesting bug then
<leon-p>
did you maybe set the main count to a number higher than 1?
<novakane>
yeah that what I thought too
<ghostbuster>
is there a way to query the current value of the rivertile vars?
<ifreund>
nope
<leon-p>
just set it to 1 and see if something changes :P
<ghostbuster>
setting the count higher also changed the split ratio so it was 50/50 instead of 66/33
<ifreund>
honestly I never use main-count of anything other than 1
<ghostbuster>
i haven't dug into rivertile so i don't even know what it means
<ifreund>
the main ratio is separate
<ifreund>
check out the man page, it explains things fairly well
<leon-p>
ghostbuster: it does not change the split ratio, instead it split the main window again, orthogonal to the main split
<novakane>
same, just accidentally lol
<novakane>
for main-count
<leon-p>
try opening four or five windows and play around with the values, you should see what they do rather well then
<novakane>
also attach-mode change a bit the way of how it works
<ghostbuster>
ooh i get it
<novakane>
but evrything is pretty explicit tbh
<ghostbuster>
number of tiles in the main split
<ghostbuster>
oh maybe this was what was causing my xkb mapping weirdness also
<ghostbuster>
working well now, thanks all
<ifreund>
cheers!
mon_aaraj has quit [Ping timeout: 240 seconds]
snakedye has quit [Ping timeout: 240 seconds]
snakedye has joined #river
<ghostbuster>
i've only been using river for a couple of days but I can already tell that it's going to be super powerful once i get my workflow dialed in a bit more
<novakane>
and that's only the beginning of river :D
snakedye has quit [Ping timeout: 240 seconds]
snakedye has joined #river
<ghostbuster>
yeah, it feels like vim.. steep learning curve but worth it
snakedye has quit [Ping timeout: 240 seconds]
snakedye has joined #river
<novakane>
tags take some time to get used to it but after you can't live without it
<leon-p>
tags are also mostly "backwards compatible" with more typical workspace implementations, if you are used to that, so you don't have to learn them immediately.
<ghostbuster>
i'd love to hear some of the ways everyone has integrated tagging into their workflows
<ghostbuster>
so far I'm just adding my irc window to my main browser window instead of switch between them
<leon-p>
ghostbuster: the wiki on github as an example of how to create a scratchpad with tags
<ghostbuster>
but i can see it being useful for coding, when you sometimes want the code, sometimes the output, sometimes the debugger, and sometimes a combination
<ghostbuster>
hmm interesting
<ghostbuster>
so is the idea you open a window on your scratchpad before deciding whether/where to assign it a more permanent home?
<leon-p>
although the way I personally use it is very boring. I have the normal keybinds, but for 18 tags (1-9 and F1-F9). 80% of the time I am just viewing a single tag at a time
<leon-p>
ghostbuster: the idea of a scratchpad is more like having a space to put special windows, like for example some communication thing, with the ability to bring them up and hide them again regardless of where you are without interfering with your currentl scene.
<leon-p>
I don't use a scratchpad myself though
<ghostbuster>
cool
<leon-p>
if you are /really/ bored, you can even try using something other than a shell script for init
<leon-p>
I am actually in the middle of moving my init to C, because this is an old laptop and on startup I have a bit of a thundering herd problem
<novakane>
oh, and how is this going?
<novakane>
is your config still simple or you need to add a lot of things around
<leon-p>
it's going pretty well, I'll probably push it to my config repo soon-ish
<leon-p>
I am also pretty the thing that makes it faster is not the speed of C vs bash, but rather that it connects to the socket only once
<leon-p>
s/pretty/pretty sure/
<ghostbuster>
how do you call into riverctl from C?
<novakane>
nice, I'll look into that when you push it then
<novakane>
it was kinda on my to-do list to use an other language but probably never be motivated for thid
<leon-p>
ghostbuster: I don't call riverctl from C, I let the program talk the necessary Wayland protocols directly
<leon-p>
river uses Wayland protocol extensions for IPC, which works quite well
<ghostbuster>
i see
<leon-p>
if you are interested in learning more, see the protocols/ directory in rivers repo
<ghostbuster>
xml eh
<leon-p>
Wayland protos are defined in XML and then a generator is used to generate binding.
<leon-p>
Yeah, it seems a bit convoluted at first, but if you work with it for some time, you won't really mind it
<novakane>
getting ride of riverctl calls in the config would probably be my best motivation to use an other language
<leon-p>
Wayland is pretty low on the XM-Hell scale, so it really is not /that/ bad :P
<novakane>
yeah that could be way worse like fontconfig lol