leopoldek has quit [Remote host closed the connection]
TheAnachron has joined #river
alexherbo2 has joined #river
<cryptocode>
yeah it was evdev-proto, all good now
yiyu91 has quit [Ping timeout: 256 seconds]
yiyu79 has joined #river
ccha has quit [Quit: WeeChat 4.3.5]
ccha has joined #river
guest41 has joined #river
guest41 has quit [Quit: Client closed]
occivink has quit [Ping timeout: 252 seconds]
occivink has joined #river
waleee has joined #river
Guest95 has joined #river
Guest95 has quit [Client Quit]
revsuine has joined #river
<revsuine>
In my river init I spawn some startup programs. Is there any way I can control which output these programs go to without making a permanent rule for it? I've tried making a rule then deleting it after it spawns but I think as riverctl commands seem to run asynchronously it leads to the program spawning on a different output. I could just make the rule and not delete it but then I'd want to delete it manually after it spawns.
<leon-p>
revsuine: unfortunately no
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 252 seconds]
yiyu79 has quit [Ping timeout: 256 seconds]
angry_vincent has quit [Remote host closed the connection]
angry_vincent has joined #river
kotto has joined #river
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
<leon-p>
so while trying out how the WM protocol feels in code, I have been side-tracked trying to render sceumorphic UI elements, which lead to being in the pixman source knee-deep for two days. that didn't lead anywhere so I guess the GnuStep source ist next...
<leon-p>
(while wishing the GNUStep core would have won over GLib / GObject / GTK, but oh well)
waleee has quit [Ping timeout: 252 seconds]
<LarstiQ>
leon-p: it kinda did in OSX! :)
<leon-p>
for a while yes, although I doubt that's code I can look at :)
traidare has joined #river
traidare has quit [Client Quit]
traidare has joined #river
traidare has quit [Client Quit]
revsuine has quit [Quit: nyaa~]
traidare has joined #river
traidare has quit [Client Quit]
<leon-p>
huh... so fun fact: windowmaker doesn't actually render it's blocks. they are just an icon, an image file.
traidare has joined #river
ahmadraniri has joined #river
ahmadraniri has left #river [#river]
<TheAnachron>
I am on river 0.3.5 but I am not sure how to set up my cursor theme.
<TheAnachron>
there is xcursor-theme but that is only for Xwayland, right?
<leon-p>
that is also for server-side cursor images
<leon-p>
(all wayland servers just reused the old xcursor themes)
<leon-p>
and judging by me apparently having removed the cursor theme env var from my river launch script some time ago, it apparently also works for windows that set their own cursor image
<TheAnachron>
I have one theme inside ~/.icons/default and running "riverctl xcursor-theme default" does not change my cursors.
<leon-p>
perhaps because "default" isn't the correct name
<leon-p>
I also faintly remember there being an issue with ~/.icons vs ~/.local/share/icons
<TheAnachron>
well default links to nordzy-white. but even using the "real" name does not change
<TheAnachron>
not even putting it into ~/.local/share/icons changed anything.
<leon-p>
what's the Name= field in the themes index.theme file?
<vyivel>
Name is user-facing name
<leon-p>
as far as river is concered yes, but I remember GTK caring about it
<vyivel>
looking at its code, doesn't seem so
<leon-p>
🤷 I defer to the code then
<leon-p>
speaking of, I just looked at the river code and it does set the cursor env vars now when you use the xcursor-theme command
<TheAnachron>
I think something is wrong with my theme, it does not have theme.index and icons are missing. I will redownload :/
<vyivel>
yeah if there's no index.theme it's not recognized as a theme
<TheAnachron>
okay, I got it now and put it under ~/.local/share/icons/nordy-dark and made sure the nordzy-dark/index.theme has a Name=nordzy-dark and then used "riverctl xcursor-theme nordzy-dark" but no change? :/
<leon-p>
how are you testing it? over an empty background or in applications? some applications may need a restart before changing cursor themes
<TheAnachron>
Nah, I was just stupid. Made a mess with the folders, I nuked it and did it all again and now it works. :/ Sorry for bothering you. And thanks!
pixavi has joined #river
<TheAnachron>
As you said, Firefox and some programs dont automatically change the theme. So combine that with a messy execution and I probably had a working setup before but didnt notice it.
pixavi has quit [Client Quit]
<TheAnachron>
After restarting Firefox the cursor is smaller there. mpv, foot etc. are all equally sized
<TheAnachron>
ok, looks like Firefox does not honor the cursor size at all.
<dnkl>
TheAnachron: foot uses server side cursors, fwiw
<TheAnachron>
ok, makes sense. This command was able to change Firefox cursor size: gsettings set org.gnome.desktop.interface cursor-size <SIZE>
<TheAnachron>
So I will wrap riverctl and gsettings into a script that will call both.
<TheAnachron>
leon-p take a look at that note. It says Note: By default, on Wayland, GNOME applications should be unable to display your cursor themes located in ~/.local/share/icons. As a workaround, you can add that path to XCURSOR_PATH.
<TheAnachron>
which is exactly the other way around.
<leon-p>
huh
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]
TheAnachron has quit [Quit: TheAnachron]
revsuine has joined #river
TheAnachron has joined #river
<TheAnachron>
leon-p do you plan on tagging a new release for wayprompt?
<leon-p>
I have not tagged any wayprompt release ever, so it would be the first
<leon-p>
and I don't think it's ready for a first release yet
<leon-p>
there is some stuff that I want to do first, I have an entire list
<leon-p>
f.e. I am really not happy with how the styling works and I would prefer if it was a bit more flexible (like arbitrary buttons when used via CLI)
<TheAnachron>
well you did tag 0.1.0 which is what I have been using for 6 months now. :D
<leon-p>
did I? I forgot ... :)
<leon-p>
in that case I might be a bit more open to tagging 0.1.1
<TheAnachron>
I dont really mind breaking stuff, just wish I could maybe have some of those nice things you've added in the last months
<leon-p>
can you remind me again in ~1 week? If I haven't done any work on it by then, I'll tag 0.1.1
<TheAnachron>
Sure, I'll do.
<leon-p>
One thing I really want to include is the rest of the screen darkening while the prompt is visible. should be trivial and efficient with the single-pixel-buffer protocol
<TheAnachron>
and it would be great if that could be optional and configurable
<leon-p>
and it annoys me how the outer edges can be round, but the buttons not
<leon-p>
of course
<leon-p>
and since I am right now working on how to neatly draw skeumorphic borders and buttons using pixman, I'd love to have that in wayprompt as well, but that's a long-term goal
<TheAnachron>
Heh, you make it a seperate library?
<leon-p>
not sure yet. Right now it's just a .c / .h file in my river WM experiments repo
<leon-p>
more realistically I'll just copy the relevant functions over, I am not too keen on making the installation process of my stuff more annoying by adding a non-standard dependency
<TheAnachron>
heh, either would be fine with me.
<TheAnachron>
On another note, novakane I cant seem to be able to build zelbar on aarch, wayland-scanner is not being found, which is part of wayland-devel. Is that known? Do I need to dig deeper or wont work?
<TheAnachron>
heh, it was missing wayland-devel in hostmakedepends, it was so easy. Doh!
waleee has joined #river
angry_vincent has quit [Ping timeout: 248 seconds]
yiyu76 has joined #river
yiyu76 has quit [Ping timeout: 256 seconds]
Guest11 has joined #river
Guest11 has quit [Quit: Client closed]
vreskcin has joined #river
vreskcin has quit [Changing host]
vreskcin has joined #river
persona has joined #river
<persona>
hey is there a way to get/subscribe information using riverctl similar to bspc? every command seems like for "setting" stuff. i couldn't even find a way to get the currently focused tag bitmask.
Palanix has quit [Read error: Connection reset by peer]
<leon-p>
persona: river exposes some information via dedicated wayland protocols. you can either write a small wayland client for your use case or hope to find an already existing one.
<leon-p>
what exactly are you trying to do, anyway?
<persona>
configuring a workspaces widget in ags
<leon-p>
I have no idea what ags is
<TheAnachron>
I novakane still lounging around?
<persona>
leon-p ags is a widgets library like eww. contrary to something like waybar, you "script" the bar yourself so it is moer extensible.
<leon-p>
so what you want is a program that just outputs the tags whenever they change?
vreskcin has quit [Ping timeout: 256 seconds]
<persona>
leon-p yeah optimally that would be the case. bspwm had subscribe method in bspc cli and it was neat.
<vimproved>
if there's a wayland lib for javascript you could use that directly in the config to interface with river
<leon-p>
yeah, just tried and `river-bedload -watch focused` gives you the focused tags per output
<persona>
but ags is just an example. any case where we need to access river's data from outside really. like any script. i am just looking for some essential methods that bspc had to "get" options instead of "set"
<leon-p>
the reason these things are not in riverctl is because scripting via shell scripts is discouraged. for frame-perfection you want your entire script as one single contained wayland client
<TheAnachron>
I also want to do something similiar, but will probably wait until we have the first tag ...
<leon-p>
all of this will be in the WM domain anyway long-term. I'll probably just have mine expose a dbus interface for scripting
<TheAnachron>
well, shell scripts is simply the easiest way how to glue stuff together and having it work on several computers without having to touch it.
<leon-p>
easy != good
<leon-p>
the easiest way would be to just stick with whatever desktop comes pre-installed with your computer anyway. as such I think we have some leeway
<TheAnachron>
haha, I like to have things configurable and like I need it. which is why I went for a WM and bar that are not forced upon another.
<TheAnachron>
I like to write glue code. And have it very dynamic.
<leon-p>
that's fair. it's just that shell is a pretty terrible language for that :)
<TheAnachron>
Also I love simplicity. Piping stuff from here to there is simple and works. I can come back to my code after months and still understand what happens.
<ifreund>
I like robust, well integrated components and frame-perfection :)
Palanix has joined #river
<TheAnachron>
which is great and probably the reason why river is so welcome on my computer ;)
<TheAnachron>
leon-p so which language is? Does everybody need to turn to compiled languages to write a custom statusbar?
<leon-p>
nope, just something which can either speak wayland natively or can use libwayland via some FFI
<persona>
what status bar do y'all use with river?
<revsuine>
just waybar
<ifreund>
I expect highly dynamic scripting languages like lua, scheme, python, lisp to be popular for writing/configuring WMs
<TheAnachron>
leon-p which choices do we currently have which are non-compiled?
<vimproved>
i've been using waybar with sway but i want to switch to yambar when i migrate to river
<ifreund>
I used to use waybar but haven't been using any bar for a while
<TheAnachron>
persona I use zelbar.
<leon-p>
TheAnachron: people have been writing wayland clients in python (entire servers even). Lua as well and guile
<vimproved>
i wish the zig eclass PR for gentoo would just be merged already so i could float the idea of putting river in the main repository
<TheAnachron>
leon-p I dont understand how you can seriously consider python to be superior to shell. But to each his own :)
<vimproved>
leon-p: does guile have libwayland bindings? i couldnt find any
<leon-p>
vimproved: I don't think so, however you can just use the FFI
<vimproved>
ah
<vimproved>
i was considering trying to write a river config in racket lol
<leon-p>
TheAnachron: because types, proper control flow, non-arcane syntax, error handling that actually works, C compatible FFI, etc. I don't like python, but it's definitely better than shell
<TheAnachron>
I can't really find a good example of a wayland LUA client. There are some, but they are either abandomed or rely on other languages (like Rust) as interface.
<vimproved>
i used to not like python but the development experience has gotten very nice imo
<vimproved>
with mypy and type hints and such
<leon-p>
I deteste every minute I have to spend wrangling snakes, but it's still better than shell
<ifreund>
TheAnachron: I suspect that we will have a library for the wayland bits of the WM written in C or Zig that is easy to use from many scripting languages
<TheAnachron>
leon-p what do you need all of this for when you simply need to display some information from river inside a statusbar? Talking about unnecessary complexity.
<ifreund>
this is not about status bars, this is about moving all window management policy outside of the river compositor process
<TheAnachron>
ifreund I would love to have some kind of interface that can be used on any language. Even if just exposing some FIFO or something to allow for easy shell integration.
<leon-p>
TheAnachron: from a systems programming PoV going through shell is the unecessary complexity. A bar can just bind the protocol and be done with it. It needs to talk Wayland anyway, why make things more complicated by involving another wayland client?
<ifreund>
as a side effect, status bars that wish to display WM-specific information will need to either be part of the WM client or talk to the WM client not river
<TheAnachron>
ifreund yep, I wouldn't want to write a wayland client in shell. No matter how posix or well its done.
<ifreund>
anyhow, I'm off to bed
<leon-p>
night o7
<TheAnachron>
leon-p how would I be able to modify the information in a way that suits me if the statusbar hooks up to wayland directly?
<TheAnachron>
good night!
<vimproved>
as someone who uses bash as the primary language i end up writing, shell sucks
<leon-p>
TheAnachron: the bar could be configurable, like most are
<TheAnachron>
As in... you tell it which command to run? I dont see how you guarantee flexibility without harding things or allow some way of running arbitary commands.
<leon-p>
f.e. you implement the entire bar as a library which you then call from a high-level language. It would do all the Wayland bits, including showing the bar surface and talking to river to get the tags, but your high-level code is in control of arranging widgets
<TheAnachron>
Like my current statusbar: I collect a ton of information from different sources and modify a global cache which then gets read on update and pushed to my status-bar. It only displays entries that are urgent (like high CPU load, temps, network bandwidth, etc)
<TheAnachron>
I have another option to show/hide the values (so only icons are shown if wanted)
<leon-p>
for a lot of status things on linux there are ways to subscribe to events which is a lot more efficient and correct than repeatedly calling a command every x seconds
persona has quit [Quit: WeeChat 4.3.5]
<TheAnachron>
Nobody is going to argue about that.
<leon-p>
so why not make use of that? the bar has a river module, a pipewire module, etc. instead of calling commands
<leon-p>
in a properly designed bar that won't loose you anything
<TheAnachron>
Ok, my statusbar currently checks which values of those 61 I feed to my cache is urgent. Does that mean I have to add 61 modules to my statusbar?
<leon-p>
depends on the modules
<TheAnachron>
I don't think I want to sacrifice simplicity for the sake of a little faster execution time.
<leon-p>
the thing is, your way /adds/ complexity
<TheAnachron>
and modules do not? how is that any different? Its just another type of interface/glue.
<leon-p>
in the case of a river-module, suddenly you have two wayland clients instead of one
<leon-p>
also because you are going through shell
<leon-p>
and parsing text
<leon-p>
it's more moving parts
<TheAnachron>
Exactly, so I am not forced on something.
<TheAnachron>
If zelbar stops working, I change my glue and can use it on waybar or something
<leon-p>
sure, but you just can't argue it's less complexity
<TheAnachron>
Well, I can even change river and still use my current setup
<leon-p>
you know what got it right? DockApps
<leon-p>
they were the best of both worlds
<TheAnachron>
well, maybe we can agree on both having its pros and cons.
<leon-p>
but dock-apps are dead unfortunately :(
<TheAnachron>
heh, I didnt know about it. but it reminds me of something I had like 15 years ago but I forgot the name of it. it was basically a bar everybody wrote widgets for (not conky!)
<leon-p>
it's technically possible on wayland; there is a protocol extension to share surfaces to other clients, but I don't think it's widely supported
persona has joined #river
<leon-p>
maybe I can revive dockapps for my WM, but thats more like a long-term idea
<TheAnachron>
keep us updated! always excited for new things.
<leon-p>
first the protocol implementation needs to be usable. what I am doing right now is just playing around with rendering UI elements
<leon-p>
I have been kinda obsessing over rendering those windowmaker-esque blocks
<TheAnachron>
which repo are we talking about? Or is it not yet public?