<edrex[m]>
Any interest in supporting it in river?
<edrex[m]>
not sure how tags would map. if they don't though, would be good to have that feedback for the protocol PR early
BlueDuDe has quit [Quit: Client closed]
Guest41 has quit [Quit: Client closed]
taupiqueur has joined #river
<ifreund>
edrex[m]: not really, I think that protocol brings more accidental complexity that its worth
<ifreund>
and waybar/hyperland supporting a protocol that's not been accepted into wayland-protocols yet is pretty shoddy practice
smach has joined #river
smach has quit [Remote host closed the connection]
sav10 has joined #river
alexherbo2 has joined #river
sav10 has quit [Remote host closed the connection]
jao has joined #river
<scorpion2185[m]>
codedotjs has a wacom tablet I think.
<scorpion2185[m]>
kraem ^
<ifreund>
alright, 0.2.1 and 0.2.2 are tagged, now on to waylock
<novakane>
zig 0.10 \o/
<ifreund>
yeah, zig 0.10 unlocked a quite a bit of code cleanup
<ifreund>
just minor warts here and there which are no longer needed :)
<plumeus>
yay
<plumeus>
Kind of depressing that NixOS has yet to package LLVM 15, but I guess such is life.
<ifreund>
void's still on llvm 12 and zig 0.8
<plumeus>
isn't that painful when you develop Zig? Or does that not matter if you need to build all the stuff from source? I guess it doesn't matter anymore at least.
<ifreund>
plumeus: I just build llvm from source yeah
<plumeus>
or well, actually, it still matters because of release builds
<ifreund>
"just" is only possible on my beefy desktop though
<plumeus>
sad
<ifreund>
on my laptop I can't reasonably build llvm from source and thus switched to alpine
<plumeus>
could use Guix
<plumeus>
has llvm 15 and can be used on any distro in an ad-hoc manner
<ifreund>
true, I did that with nix once
<plumeus>
I think Guix is pretty nice but I kind of want my hardware to work and don't want to use GRUB on my laptop because it kind of sucks as far as LUKS support goes.
<plumeus>
But that's not an issue with an ad-hoc installation.
<plumeus>
I wonder if I can use the stable releases of River once it comes out. I was always on master for features I wanted here and there.
<plumeus>
I presume Waylock could also be stable.
<ifreund>
plumeus: by stable do you mean 1.0?
<plumeus>
err, point/tagged releases
<ifreund>
river just got several of those, as did waylock :D
<plumeus>
Yeah
<ifreund>
ah, "once llvm 15 comes out"?
<plumeus>
But River kept getting cool features, how awful
<ifreund>
this release cycle probably won't be as feature-focused and likely more breaking
<plumeus>
I was just thinking Waylock could be more "boring" in that sense.
<ifreund>
the goal is to move to the wlroots scene graph AI for 0.3.0
<ifreund>
waylock should be far more boring, yes :D
<ifreund>
s/AI/API/, don't want none of that AI stuff here
<ifreund>
it doesn't even need llvm 15 yet, though I'll be releasing a version compatible with zig 0.10 shortly
<plumeus>
Yeah
<ifreund>
I think it's kinda funny that someone put the crappy old rust version of waylock in the Arch community repo
<plumeus>
I think there was a guy on Guix that was trying to add support for packaging Zig programs idiomatically. If so, that would put Guix ahead of NixOS in terms of Zig support and that would be interesting to see.
<plumeus>
NixOS's situation with Zig is everyone just making their own package by mimicking existing Zig packages, and none of it utilises the abstractions Nix could provide.
<plumeus>
Wasn't Rivertile in Rust at one point? I forget.
<ifreund>
nope, I never wrote anything directly river related in rust
<plumeus>
oh, then it must have been waylock
captain_chaos has joined #river
<ifreund>
probably yeah
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
Lemanr has joined #river
<Lemanr>
not sure why my brightness keys are not working, can anyone give me a sanity check? https://bpa.st/X2E32
<leon-p>
LemanR: look at line 107
<plumeus>
ha
<leon-p>
rivertile is a long-running program, not a oneshot thing
<Lemanr>
107 is rivertile -view-padding 2 -outer-padding 2. I think that was from a default
<plumeus>
yeah
<plumeus>
make it the last line
<ifreund>
the lastest example init file has a & at the end of that line to run it in the backgrou
<plumeus>
huh, didn't know that that also works
<Lemanr>
oh, this is a more fundamentals of bash scripting concept I don't know about isn't it
<plumeus>
well, it's fairly simple
<leon-p>
rivertile simply won't return until it's done
<plumeus>
`riverctl` is like `cat`. It runs once and ends quickly, and is called a "one-shot" in this context.
<Lemanr>
read it again and I think I know what you mean. As a 'long-running process" you mean the line runs continuously and so never moves past line 107
<Lemanr>
*read what you had said again
<plumeus>
rivertile just runs continuously like less or something. Nothing after that line will be processed until the thing ends, or the program is ran in the background
<plumeus>
yep
<plumeus>
so try moving it to the last line or making it a background process with `&`
<edrex[m]>
<ifreund> "and waybar/hyperland supporting..." <- idk if i'd agree with that. there's something to be said for exercising a proposed protocol by implementing some use cases before it's finalized. It's easy enough to patch when changes come along, and everyone's rolling release these days. Anyway it shows that there's a need for a cross-compositor protocol for getting workspace info.
<plumeus>
I always wondered how well a reply on Matrix looks through the IRC bridge
<plumeus>
been too afraid to ever try it
<ifreund>
edrex[m]: it's absolutely necessary to implement and test protocols before they are finalized. It is not good practice to include such protocols as default-enabled in software releases
<ifreund>
this will likely lead to certain released waybar crashing once the protocol is properly implemented
<ifreund>
which is the kind of incompatiblity that wayland-protocols exists to prevent
<plumeus>
This is why everyone should switch to Windows /s
<Lemanr>
did both. But this makes sense. I read the rivertile doc just now but it doesn't say much as to how it actually works. But it makes sense that if it is generating the layout, which gets changed over time, then you wouldn't want it to be a one-shot program. Out of curiosity though, does this basically mean that in the background rivertile is on a
<Lemanr>
loop and re-runs it'self (specifically generating the current layout) just really fast making it appear as though it's continuous? If so, is this a broad GUI concept (like do all GUI do this in some respect).
<edrex[m]>
i think folks are impatient for more rapid progress in the wayland space. I don't think there is one set of "best practices" that fit everyone's goals here.
<plumeus>
You should read a short brief on OS and CPU scheduling
<plumeus>
but this isn't a GUI concept, it's used pretty much everywhere
<ifreund>
edrex[m]: the proper solution for hyperland to "move faster" would be to implement the protocol under their own namespace, e.g. hypr-workspace-v1
<plumeus>
think about your browser, text editor, or anything that's "interactive".
<ifreund>
standardization can be slow, and there's no real way to shortcut that
<Lemanr>
I actually plan on LFS this summer. I think that's when I will attempt to level up my linux wizardry. but I'll glance & bookmark that link now and read it should time permit.
<plumeus>
All interactive programs do is that they run for a very short time and give control back to the OS once their job is done.
<ifreund>
LemanR: if you want some insight on what rivertile is doing, you could kill your currently running instance and run it in a terminal with WAYLAND_DEBUG=1 set
<ifreund>
then you can see the messages it and river are sending back and forth
<Lemanr>
totally doing that
<leon-p>
LemanR: the concept you are looking for right now is probably the event loop. I remember when i first learned what that was suddenly a lot of things made sense
<plumeus>
btw, every single program actually just makes it appear to be continuous. The scheduler (managed by the kernel in the case of Linux) just gives each process a very short time to work on what they want, and moves on to a different program. Assuming a single core CPU, only one process can be active at a given time. The scheduler just cycles between processes so quickly that you might not notice unless you look into it.
<leon-p>
von-Neumann and Landau strike again!
<plumeus>
Also, I personally never did LFS but I doubt it would teach you too much about OS design? I'm not saying it's a waste of time but if you want to know how the OS works in general, it would probably be more constructive to read about that instead.
<plumeus>
need to find all the cool songs related to bodies of water
<Lemanr>
That does make sense. If the debug will look how I think it will then I may just alias it for a while to remind me about this lesson as it's a very important one.
<leon-p>
edrex[m]: whether people are impatient is effectively irrelevant, as it does not change the best practices. Yes, having to wait for things you want sucks (where the hell is landlock support in glibc?!), but what sucks a lot more is a system which is fundamentally broken because someone tried to skip a few steps
Lemanr has quit [Quit: Client closed]
<plumeus>
Where the hell is my commercial sold, open-hardware RISC-V desktop?
<plumeus>
or WebGPU support in WASI
<leon-p>
well, my pool of water related songs is pretty much empty (heh), so good to see someone else taking up that job
<plumeus>
Sadly, I don't really listen to music. All the music I know are stuff I've heard in video games.
<ifreund>
the real river theme song is The River by King Gizzard and the Lizard Wizard
<ifreund>
SLIFT and particularly Altitude Lake are just what I've had on repeat the past month
<plumeus>
Water related music: Serenade of Water from The Legend of Zelda: Ocarina of Time
<leon-p>
ooh, KGatLW will always be a+1 from me
Lemanr has joined #river
<ifreund>
I saw them live back in 2018 in a super small venue and most recently this past summer on the main stage of a big festival, amazing band
<edrex[m]>
i'm not trying to troll you all, but the idea that everyone needs to follow some "best practices" handed down from on high, which are somehow going to protect us from system instability is to me, seems to me rather silly. If waybar and hyperland implement the protocol early, that's them voting "we want this, and we are willing to bear the instability to push for it to happen". Gatekeepers are a huge problem in the free software world.
<plumeus>
why can't they make a protocol under their own namespace?
<ifreund>
^
<plumeus>
They could rename the protocol to a more general one if it's good enough for it to get formally adopted.
<plumeus>
That is, propose it and rename to it once it does get adopted.
<ifreund>
it's not gatekeeping, standardization processes are necessary for interoperabilty whether we like it or not
<edrex[m]>
that would totally work. it's not what they did, and yes, given that the unmerged protocol isn't merged it could cause runtime issues when the versions don't line up.
<edrex[m]>
but we already expect our users to edit config files in multiple formats, read logs, dig through issue trackers etc.
<ifreund>
it can do worse than that, it can cause more software to support an unmerged protocol version and hurt the ecosystem
<plumeus>
And now they can be confused by inconsistent protocol names!
<ifreund>
worse than that, inconsistent protocols with the same name
<plumeus>
What would even be the standardisation analogue of gatekeeping? I don't think this is one of them, however.
<plumeus>
EEE of standardisation
<leon-p>
developing a protocol while simultaneously already using /does/ work, you just have to make sure to rename the protocol for all breaking changes (that's the -v1 postfix you'll sometimes see)
<leon-p>
but the workspace protocol is not developed that way
<leon-p>
if we wish to create an ecosystem of acceptable quality, gatekeeping sometimes is necessary
<edrex[m]>
the fact is that users want their bars to be able to report workspaces. I need a visual representation of the workspaces that exist and whether they're populated. i'm willing to keep track of the state of play of the protocol proposal
<leon-p>
also this is not true gatekeeping. no one says "don't do this", we are saying "do it if you like, but please in a slightly different way"
<edrex[m]>
wlroots users have been dealing with broken shit for a long time
<leon-p>
only on certain compositors
<leon-p>
sway is fine, river has been fine
<leon-p>
because we follow certain standards others aren't willing to follow
<leon-p>
not to throw shade at other projects, but most don't have a strict protocol hygiene
<leon-p>
and unless they are willing to fox that, their stuff will remain broken
<leon-p>
if we want to move past the age of needing to double-check whether some program /actually/ supports the compositor you are using, we need strict adherence to the protocols and their development cycle
<edrex[m]>
more than that, we need them to exist
<leon-p>
it does exist though. and they can use it. just make it part of their own namespace, otherwise their software is practically broken
<edrex[m]>
it seems like protocol PRs could just carry a unique version tag for each change.
<leon-p>
no, because the protocol is developed in the understanding that no one is actually using it right now, so that breaking changes are fine
<edrex[m]>
the point of the protocol is interop. waybar and hyprland would have to get together and decide on a namespace.
<leon-p>
this can be avoided by just importing it into your own namespace
<leon-p>
one change later and suddenly you have to go hunting for the right git commits to get that interop working again
<ifreund>
I think the main reason that this protocol in particular hasn't been merged yet is because it is extreemly ambitious and complex
<leon-p>
it's the equivalent of throwing your hands up and saying "it works on my machine. no on yours? tough luck"
Lemanr has left #river [#river]
<ifreund>
I personally don't think trying to abstract over all possible window management workspace styles is possible or desireable
<ifreund>
what you end up with is status bars that are so generic as to be useless
<ifreund>
I want tight coupling between my window manager and status bar
<leon-p>
also no matter how generic they manage to design it, it will never describe all possible workspace-like concepts people /will/ implement on their compositors
<plumeus>
tbh, I kind of like dwm or i3 where the basic features like workspace/tag display is provided out of the box and the status bar merely displays information that is fairly agnostic to the wm
<ifreund>
plumeus: that's kinda where I'm planning on going longer term with river, don't expect that to happen soon though
<edrex[m]>
i really like leon's tag overlay ui, and had wondered if it might ship with river in some form down the road. i generally dislike big rectangles that hang around and display mostly irrelevant information. an overlay that only shows on change is nice.
<plumeus>
And here I was, wondering if rivertile will ever be moved to a different repo/package
<ifreund>
plumeus: probably, but it might be quite a while
<ifreund>
and it will probably be more like riverwm than rivertile at that point
<ifreund>
maybe I can come up with a better name
<plumeus>
maybe when river and riverctl hits 1.0 or 2.0, or something like that
<leon-p>
I propose raft as a new name, or anything else that floats on water
<ifreund>
raft is a consensus protocol
<leon-p>
dammit
<ifreund>
canoe is what I'd been thinking of
<plumeus>
Is it weird that my first thought was a decaying corpse?
<ifreund>
xD
<plumeus>
I was just thinking about how corpses sink initially and float as gas builds up from the decomposition.
<leon-p>
edrex[m]: I don't think river will ever bundle anything that specific. Also I am mildily interested in also adding support for other compositors, in which case it would no longer be a purely river related tool
<captain_chaos>
Question about modes: why do they need to be declared first? And more improtantly: Can a binding be in all modes? Useful especially for the mapping to return to normal mode, but also for some other mappings.
<leon-p>
a binding can only be in a single mode
<leon-p>
but you can define the same binding in mulitple modes individually, as we do in the example init
<ifreund>
captain_chaos: modes are pretty much the way they are because it was the simplest set of commands that got me the features I wanted way back when
<leon-p>
btw, since the keychords thing came up recently, we could pretty easiely support keychords by having modes that automatically exit back to normal after a single bind was used
<plumeus>
what's a keychord?
<leon-p>
plumeus: think of keybinds, but you can also bind sequences, not just simultaneous presses
<plumeus>
wouldn't that be better addressed by implementing input_method_v2 and working from there?
<leon-p>
I don't see how? FWIW this is strictly about river binds, not things inside applications
<captain_chaos>
So maybe I can have a function in my init called "create-mode" which takes a mode name as argument, and then declares it and sets up some in-all-modes mappings like "map $mode Mod4 Escape enter-mode normal".
<plumeus>
Oh, okay. The idea was to just implement input_method_v2 and have someone make a IME for expressing chords.
<captain_chaos>
Is that a good idea?
<leon-p>
plumeus: application level chords already work, otherwise we'd have no emacs users here
<captain_chaos>
Could make the init less confusing and reduces errors because of forgetting the mode reset or the declare-mode for a mode
<plumeus>
But chords don't work between applications
<leon-p>
captain_chaos: whether that's a good idea is up to you. If it works, solves your problem and makes things more maintainable for you, it certainly might be worth a try
<leon-p>
plumeus: I have never heard of key chords that are split between applications, do you have an example?
<plumeus>
Well, IMEs in general.
<leon-p>
that's a totally different thing, though
<plumeus>
Yeah, well, I wasn't thinking about the chords being River-specific at first.
<leon-p>
with cheychords, you press C-x and emacs knows that you enter some other level of keybinds, with IME, you type things and some magical daemon somewhere replaces them with something else without the application that you typing into knowing what is going on
<leon-p>
different use cases, I see no overlap
waleee has joined #river
<plumeus>
I was thinking of a generic solution that works across all applications, so yeah. Different thing.
<novakane>
that new flags.zig is pretty nice!
<ifreund>
:)
<leon-p>
hmm... never thought about it about technically what you do in kakoune (/ vim) are also chords, just with visual feedback
<plumeus>
How's Kakoune?
<plumeus>
I've been sticking to Neovim but maybe I should try something else one of these days.
<leon-p>
neat, although not only the keybinds are different, the ideology as well a bit
<leon-p>
the typical vim modus-operandi is reaching for plugins, in kakoune youre first instinct is to search for some CLI tool you can pipe through
<plumeus>
That's an interesting approach.
<leon-p>
and since you can have sessions spanning multiple clients inside multiple terminals, it also does not have its own window management that conflicts with your desktop
<plumeus>
So, LSP works just by putting them in PATH and a few lines of configs?
<leon-p>
it feels a lot more integrated over all
<leon-p>
plumeus: kakoune does have plugins, this is how LSP works, but I don't use it so I can't tell you the specifics
<captain_chaos>
Im curious. What attach-mode do some of you use and espeacially why?
<leon-p>
tpo, the default. If I open a window it should get a prominent placement in the layout
<leon-p>
*top
<ifreund>
I've never used anything other than top
<ifreund>
kakoune is great, I use clangd with kak-lsp and it was pretty easy to set up
<plumeus>
If I were to write a program, I would think it would have configs in Scheme or just something like WASI.
<leon-p>
git blame says I implemented the command initially, no idea why I did though. maybe it was a feature request?
<captain_chaos>
Same. But thought using bottom allows one to leave it there or to instantly zoom it. Using top that choice is taken away so maybe bottom is useful...
<captain_chaos>
"Same" about using top
<leon-p>
plumeus: i think there is a certain elegance to opinionated software, which is meant to do a thing just a single specific way, so that it does not need a lot of configuration and a simple INI file is fine
<captain_chaos>
Kakoune seems interesting. But I am not sure if I want to confuse my vim muscle memory
<leon-p>
although I also think if everyone just wrote scheme / lua libraries and all main application logic was in those languages as well, we'd all be having a lot more fun
<waleee>
plumeus: helix (editor) is going down that path iirc
<plumeus>
I am not a big fan of Lua, yet. I don't quite get the appeal.
<leon-p>
s/lua/whatever scripting language you like/
<plumeus>
Surely, Haskell
<leon-p>
that was the original idea behind GNU guile as well, although unfortunately everyone other than andy wingo forgot about it, it seems
<plumeus>
Wouldn't be sarcastic if Haskell's bootstrapping story isn't so horrendous
<waleee>
leon-p: wasn't the problem there that they got bogged down in the idea of having it super-tightly integrated into gnu hurd?
<waleee>
* the hypothetical system that was to use hurd
<leon-p>
I don't think there is any guile code in hurd or vise-versa
<leon-p>
guile is used in guix though, extensively
<waleee>
not in the kernel, but as the main language for configuration etc
<leon-p>
hurd is only C, IIRC
<plumeus>
GNU Shepherd is configured in Guile
<plumeus>
so maybe that's what you mean?
<plumeus>
If not, you are likely referring to Guix
<waleee>
well, it was supposed to be used with gnu hurd so yes
<plumeus>
which is doing fine and supports Hurd for VMs
<waleee>
(I'm aware of guix, but that was a lot later than the OG hurd stuff)
<plumeus>
well, it's not like all the effort went to waste
<plumeus>
Not that I know the history of Hurd
<waleee>
guile as a widespread scripting language kind of died though
<plumeus>
Probably doesn't help that Guile isn't particularly fast either.
captain_chaos has quit [Ping timeout: 260 seconds]
captain_chaos has joined #river
<captain_chaos>
I just noticed "riverctl keyboard-layout" exists. Does this mean I don't need the environment varaible anymore?
<ifreund>
yes
<captain_chaos>
Nice. Bringing configuration together in one place. I like that
<ifreund>
new waylock releases done, off for the day now :)
<andrea>
zig has just entered staging repo in archlinux. can't wait to update the aur package :)
<andrea>
zig 0.10.0 obv
captain_chaos has quit [Ping timeout: 260 seconds]
talismanick has joined #river
<kraem_>
ifreund: woah thanks for showing SLIFT - favourtied :)
<kraem_>
scorpion2185: thanks. i think i'm just going to buy one and see if it's usable, otherwise i'll just sell it :)
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
muirrum has quit [Quit: WeeChat 3.7.1]
talismanick has quit [Read error: Connection reset by peer]
<novakane>
obviously I tagged a new version of rivercarro for zig 0.10 and just after that I find the fix for the only known problem in it lol
shaunsingh has joined #river
<shaunsingh>
Hi, sorry to bother. Using the default `rivertile`, is it possible to add left padding so that river can stop overlapping with my vertical bar? if not, is there a recommended alternative layout generator. I checked `man rivertile` and didn't find anything
shaunsingh has quit [Quit: Client closed]
<novakane>
shaunsingh: no, that is something that should be taken care by your bar, check if you can change the layer in it
shaunsingh has joined #river
<novakane>
or in rivertile you have an outer padding but that's not only on the left
<shaunsingh>
Thanks, I'll take a look at my bars seconds