<leon-p>
if "staging" will be new standard, renaming rivers protocols makes sense to avoid unecessary fragmentation
<ifreund>
yep, agreed
<leon-p>
shoudl I open an Issue on Github?
<ifreund>
yeah sure, I'll mark it as a blocker for 0.1.0
<ifreund>
we could wait until everything else is done for 0.1.0 to avoid any breaking changes between the rename and release
<ifreund>
and then follow proper protocol versioning practices between releases
<leon-p>
sounds fine
<ifreund>
We should also add the suggested disclaimer to our xml to indicate that the protocols are in "staging" and are not yet "stable"
<leon-p>
but I think we can do it for the layout protocol right away, considering it is not on master branch yet
<ifreund>
yeah sure
<ifreund>
I'll do the same when I finally finish reworking the options protocol
<ifreund>
I think I've got the protocol figured out now, just need to do the implementation and write better descriptions in the xml
<leon-p>
also added another todo for the layout PR, regarding the status event ordering
<leon-p>
I'd like to get that PR done before I'll be overwhelmed with university work again :P
<leon-p>
btw, is the PR still based on my branch, or on yours? Github kinda confuses me here. Just asking so I know where to push things
<ifreund>
You can't actually change the base branch of a PR, so it's still your branch
<ifreund>
and yeah github's UI around this stuff sucks
<leon-p>
call me crazy, but I find gits native email based pull requests more intuitve :D
<leon-p>
(at least now that I actually read the book)
<novakane[m]>
wich book? I find it so impractical to use email
<novakane[m]>
but I can say I tried it a lot
<leon-p>
novakane[m]: the one linked on the git website. It's pretty decent.
<leon-p>
And email based workflow only is nice when you have a good mail client.
<novakane[m]>
yeah I use aerc so it's good
<novakane[m]>
but I guess that's a habit to take
<novakane[m]>
I almost just tried the tutorial by sourcehut
<leon-p>
novakane[m]: You may have only seen sending patches via email, but you can also do pull requests via email. It's seriously nice, mostly because it does not require the two repositories to be on the same host.
<leon-p>
ifreund: do you want tablet support for 0.1.0? If yes I can probably rush it this month. If not I'll be more lazy about it.
<ifreund>
leon-p: I don't care too much about tablet support much personally as I don't have any hardware. It would be nice to have though I certainly wouldn't block 0.1.0 on it
<ifreund>
I think I can slack off on other stuff and finish implement the options thing today
<ifreund>
then I should go fix that glibc linking issue for zig
<novakane[m]>
leon-p: oh yeah sound cool, but then github doesn't support this no?
<leon-p>
novakane[m]: It can not /not/ support it :D That's the beauty of git being centralized. You pull it to your local and push it to the remote.
<leon-p>
*decentralized
<leon-p>
github wants you to believe that git is centralized, but that is a lie.
<ifreund>
leon-p: what mail client do you use by the way?
<novakane[m]>
ifreund: btw building zig-master works without changing anything after many attempts, don't know why
<leon-p>
ifreund: I am on aerc currently, but still have neomutt configured because aerc often crashes when I try to send PDF attachments
<ifreund>
novakane[m]: probably some caching issue then
<ifreund>
I've tried aerc but found the builtin terminal kinda gimmicky and not very unix-philosophy
<leon-p>
kinda. But over time I came to prefer "one task per program" over "one functionality per program". My main gripes with it is that kakoune does not work well in it. The colours are messed up and because kaks curses interface updates more often that it technically needs to it flickers a lot
<ifreund>
you might want to try kakoune's builtin-terminal-ui branch
<leon-p>
I'll do that, thanks for the suggestion
<novakane[m]>
alot is really great too but I had problem with encrypted mail
<ifreund>
but yeah my take is that an email client has no business being a terminal emulator due to the complexity of terminals
<leon-p>
I am not disagreeing. Just in my opinion keeping functionality strictly separated often does not work if you want a decent user experience.
<ifreund>
alot does look nice
<ifreund>
leon-p: yeah there's definitely a balance to be struck
<leon-p>
ideality the UNIX philosophy should be redefined to "one functionality per library", so it would not matter what user facing tools supports what functionality
<leon-p>
and have a shell that can make use of those libraryies, but then we are a lisp machine and no longer UNIX
<novakane[m]>
ifreund yeah you need to use notmuch with alot but I like tag based system
josip has quit [Remote host closed the connection]
josip has joined #river
londoed has quit [Remote host closed the connection]
londoed has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
<leon-p>
ifreund: thinking about it, instead of changing when we send the output status, we could just add the pending focused tags to the layout demand. I don't particularly like having an additional source of truth, but it would be more seamless.
<leon-p>
That's something I'd like to fix today. I want to get done with that PR
yyp has joined #river
<leon-p>
actually, we /have/ to do it that way. Since layout_demands are all done before the transaction even starts
<ifreund>
Yeah I think if we want to allow layouts dependant on tags then we would have to send the pending tags in the layout_demand event
<leon-p>
thats what I am currently doing, I'll have something to push in a few minutes
<ifreund>
are we 100% sure we want to allow layouts dependant on tags?
<ifreund>
it's a lot easier to add information to a protocol later than to remove information
<leon-p>
I am pretty sure. For example, many users like to assign specific tags to tasks (f.e. I have tag 9 for communication stuff) and likely want a specialized layout for that. Another good use case is to switch to a more space efficient layout if all tags are active.
<ifreund>
yeah, I tend to agree
<leon-p>
also people will do it anyway. And if we don't support it first-class, they'll do it the hacky thing by sending parameters_changed when focused_tags is received.
<ifreund>
yeah that's definitely worse
<leon-p>
btw, I still saw a commented out line with a TODO in the transaction code. I think that was the line that made river crash for me when closing views. Can't remember why it was needed in the first place and if it has been fixed, but we should probably remove it.
<ifreund>
which line is that?
<ifreund>
oh in commitTransaction()? yeah that should be removed
<leon-p>
Root.zig +371
<leon-p>
yeah i think it is unecessary now. As far as I can see you made all layout demands finish before the transaction starts, so it serves no purpose anymore
<ifreund>
indeed
<leon-p>
I'll remove it. The commits need to be cleanued up anyway.
<novakane[m]>
maybe it come from something else in my setup, so I just want to be sure the river config is right before
<leon-p>
novakane[m]: what you do there is racy
<leon-p>
or is it?
<leon-p>
actually I think not. With any other option it would be, but "layout" is created for every output
<leon-p>
anyway, there will be some changes to river-options in the near-ish future, so I think we should wait for that
<leon-p>
by the way, river now works on my ultra wide screen thanks to custom display modes. It just freezes when you enable it :D
<novakane[m]>
alright, well it;s not really a problem I can wait
<novakane[m]>
what would be the best options to setup this instead then
<leon-p>
oh, and there is the small bug that I can have two separate cursors, one on each output. Probably because when I resized the output it now overlaps with the other one
<leon-p>
novakane[m]: have you tried setting the option before spawning rivertile?
<novakane[m]>
well with 2 cursors you will be twice as fast :p
<novakane[m]>
like adding `riverctl set-options -focused-output layout` before the 2 others line?
<leon-p>
novakane[m]: yes
<leon-p>
just pushed two minor UX improvements for when no layout is active. River should make a decent floating compositor now as well.
<novakane[m]>
leon-p: ok, I'll try, could be that since it's really random, sometimes it works sometimes I need to use my keybind to start it after booting
<ifreund>
that's exactly what one should expect from a race condtion :P
yyp_ is now known as yyp
<novakane[m]>
haha yeah well I like living dangerously :p
<novakane[m]>
no for real I thought this one was always set
<ifreund>
Finally getting started on the new river-options implementation, and I decided to try streaming it for fun if anyone wants to come hang out: https://www.twitch.tv/ifreund_
<leon-p>
I'll be there in a moment :D
<yyp>
ifreund: cool!
<emersion>
ifreund: protocols can have a <description> too, fwiw
<emersion>
i mean, protocol>description is valid
<emersion>
yup :)
<leon-p>
maybe there should be a blurb "this protocol defines a way to..." too?
<emersion>
the current set of protocols in wayland-protocols don't really use this, sadly
<emersion>
so they conflate the protocol and the global object
<emersion>
not a big deal, but
<leon-p>
btw, do you want me to fix up the layout protocol wrt s/unstable/staging, or do you want to do it?
<emersion>
tablet_unstable_v2 for example uses it
<leon-p>
I am on it
<novakane[m]>
damn I'm too late for the stream :/
<leon-p>
novakane[m]: I think he is still going, the stream just cut out
<novakane[m]>
leon-p: oh ok nice
sfreimuth has joined #river
<ifreund>
oh shit is my internet being bad?
<leon-p>
apparently. the stream is offline atm
<ifreund>
alright I *think* I'm live again :D
<leon-p>
yeah, you're back!
<sfreimuth>
hello! I'm new to river as a project, having watched @ifreund's insightful video about using Zig for Wayland. are there any videos demoing River's capabilities I can watch to see it in action?
<emersion>
a demo video would be nice
<leon-p>
sure, I'll add that to my todo list
<leon-p>
probably a good idea to explain layouts, options and tags in that format
<leon-p>
sfreimuth: the tl;dr version is: Basically you have a list of windows per output. Which of those are visible is determined by a bit field. Both windows and the output have one and they are AND'd to determinte visibility. The windows are arranged by layout generators which create positions and dimensions for the window list. Layouts can depend on an arbitrary amount of arbitrary user-defined live changeable
<leon-p>
options.
<leon-p>
basically dwm but on Wayland and on steroids.
<leon-p>
we also have animated opacity changes, for whatever reason :D
Chris218 has joined #river
<yyp>
ifreund: are you using ZLS for auto-completion?
c7s has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
<yyp>
ifreund: dunno, when I was using ZLS, it sometimes (quite frequently in fact) replaced completed stuff with `null`s which was quite annoying
<yyp>
Maybe vim-lsp is broken or something
Chris218 has quit [Quit: Connection closed]
Chris218 has joined #river
sfreimuth has quit [Quit: Connection closed]
<yyp>
ifreund: are you working on setting options (riverctl {set,get}-option) through a protocol right now? I've missed some parts of the stream
<yyp>
real programmers use 3 spaces :)
<yyp>
oh, that's quite useful thing to have
sfreimuth has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
yyp has quit [Client Quit]
Chris218 has quit [Quit: Connection closed]
sfreimuth has quit [Quit: Connection closed]
Chris218 has joined #river
Chris218 has quit [Client Quit]
<leon-p>
ifreund: pretty sure you just wanted to say that you are going to end the stream because you are tired. Twitch apparently already made that decission for you though, so I am not sure :)
<ifreund>
leon-p: nope, I'm still going though it appears the connection dropped again :D
<ifreund>
or maybe it's wlrobs cutting out, idk
<ifreund>
obs definitely seems to be frozen
<ifreund>
guess that's a sign that I should go to sleep though
<leon-p>
considering twitch tells me the stream in total was almost four hours, probably :D
cbix has quit [Ping timeout: 250 seconds]
cbix has joined #river
gspe has quit [Quit: gspe]
<ifreund>
leon-p: uh, the new naming convention from wayland-protocols is just river-layout-v1 not river-layout-staging-v1
<ifreund>
the point of this changes is to make stabilization non-breaking
<leon-p>
ah I see. I'll fix it in a moment
<leon-p>
done
<ifreund>
pushed my WIP river-options-v2 stuff to the layout branch on my repo for now. Will push it to your branch once its finished
<ifreund>
I river and riverctl now compile but rivertile needs to be updated
<ifreund>
hopefully will have time tomorrow to finish that up