<sewn>
yeah but im quite a bit dissapointed there isn't one place where good wayland software can be shared
<sewn>
each compositor seems to have it's own page
waleee has quit [Ping timeout: 256 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 240 seconds]
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 268 seconds]
Guest49 has joined #river
Guest49 has quit [Quit: Client closed]
Guest49 has joined #river
<Guest49>
can anyone help me use wofi i tried adding this line in the init file riverctl map normal Super D "wofi --show run" but i get nothing and when i run river in a terminal i get command not found although when i use wofi --show run in a terminal it runs fine
Guest49 has quit [Quit: Client closed]
<sewn>
is there a way to get a 'list' of modes?
leopoldek has quit [Remote host closed the connection]
The_Buhs6 has joined #river
The_Buhs has quit [Ping timeout: 264 seconds]
The_Buhs6 is now known as The_Buhs
<NickH>
sewn: doesn't seem to be
<sewn>
lame
<sewn>
would be a nice to have in the status protocol
<sewn>
so statusbars dont have to guess modes or let the user give a list of modes
<NickH>
Guest49: probably best to upload your config somewhere and report the *exact* error message
<NickH>
The current mode is reported, but not all the defined modes.
<sewn>
that, and status bars can have a ability to select a mode
<sewn>
like how you can select tags
<NickH>
In fact I don't think that is how modes work in river. I think river just knows the name of the mode it is currently in.
<NickH>
Hmm, but it does knows about them in terms of if a mapping has been made for a given mode
<NickH>
sewn: "lame"? really? Might want to tone it down a bit.
<sewn>
didn't mean it that way, sorry.
<sewn>
NickH: it does have to keep track of the bindings of a mode to be able to switch to it right?
hmht_ has joined #river
angry_vincent has joined #river
hmht_ has quit [Ping timeout: 252 seconds]
flatlander has joined #river
<flatlander>
Guest49: you're missing the word 'spawn', should be riverctl map normal Super D spawn "wofi --show run"
<leon-p>
sewn: NickH: I think the status protocol may get deprecated with once the WM protocol lands
<sewn>
the whaaaaat
<sewn>
whats the WM protocol
<leon-p>
basically moving all window managing to the layout generator
<sewn>
oh
<sewn>
wait what
<sewn>
but why
<leon-p>
to allow more flexibility
<sewn>
like, does it really handle toplevel requests and size hints and stuff like that too
<leon-p>
likely yes
<leon-p>
I suppose the status protocol could survive in a limited form, since f.e. the name of the focused window is still something river knows and could expose. But other things like tags will be moved completely client side, so river will know nothing about it
<leon-p>
ifreund: what's your opinion on river-status? Do you want to remove it completely or keep it around for the few things river still knows server side?
<leon-p>
kinda wondering about that, since on the one hand it would be easy to have it, on the other hand it will only ever expose limited data so any status display thing will always want to interface with the WM directly anyway
<leon-p>
or maybe we just enter the era of status bars built into the WMs, at least in my case
<ifreund>
leon-p: funny that you should ask, I just deleted it like an hour ago xD
<sewn>
but why was it removed before something could even replace it
<ifreund>
that commit is not on master branch...
<sewn>
oh
<sewn>
hey i blame codeberg
<ifreund>
git show works the same way, I don't blame codeberg
<sewn>
but anyway now that we are on this topic will river be able to give back a list of modes just so the statusbar can have an interface where the user can choose a mode
<leon-p>
likely that will depend on the WM
<sewn>
ifreund: codeberg hides the branch unless you click on the 'more information' button
<leon-p>
f.e., If you want key chords, like an emacs-esque "S-c 2" to spawn a split for example, you need a mode entered by S-c which has a 2 bind. Entering the S-c mode via a status bar makes no sense, so a WM that works like this likely will not expose its modes nor allow changing them externally
<leon-p>
(although I think the better option for the WM is to open a widget surface on S-c and focus that and then handle all following key presses via the normal wayland way)
flatlander has quit [Quit: Client closed]
fitrh has joined #river
fitrh has quit [Remote host closed the connection]
<ifreund>
open question for the window management protocol: how to decide which output to open new layer surfaces on?
<ifreund>
sure we could have a request that gives the compositor an output hint, but I don't want to tie the window management protocol to the unstable layer shell protocol
<ifreund>
it's tempting to delete layer shell from the compositor and implement it in the window manager (which become a proxy compositor for layer shell clients)
<leon-p>
I'd say use the output the last focused window is/was on
<ifreund>
we won't strictly tie window to a single output anymore in the compositor either
<ifreund>
(though we will still use heuristics to decide which output will be considered "primary" for frame callbacks and presentation timings if the window overlaps multiple outputs)
<leon-p>
we could add a request to the WM protocol that allows the WM to indicate which output should be considered focused
<ifreund>
I think "output focus" is an artificial window management concept, and not really something the compositor should need to know about though
<leon-p>
I agree, however we could document that it's only meant as a hint to place layer-shell or other non-WM widget
<ifreund>
I mean, pragmatically a output_hint request would give the compositor the information needed and be pretty simple
<leon-p>
are there any other things that require the server to chose an output that the WM isn't involved in?
<ifreund>
In my ideal world I don't think my compositor supports layer shell though, all my desktop shell elements are handled by my WM
<ifreund>
leon-p: not that I've thought of yet
<leon-p>
I agree with that as well
<leon-p>
i am a bit desillusioned about the "lego" design w.r.t. desktop shells
<ifreund>
anyhow, I'll just TODO this for now and keep ruminating on it while I delete thngs
<leon-p>
FWIW a output hint request is easy to deprecate should you choose to remove the layer-shell from river
<ifreund>
true
<leon-p>
hmm... I think for some widgets it does make sense to keep them separate. I.e. I see no upsides to integrating something like fuzzel in my WMs desktop shell directly
<leon-p>
the only integration between it and the rest of my desktop I want are visual
<ifreund>
leon-p: One upside from integrating fuzzel would be race-free pid tracking of the launched process by the wm
<leon-p>
that I would have done with xdg-activation
<ifreund>
doesn't that require everything launched to support xdg-activation?
<ifreund>
I don't really have any sense of how widespread that is in clients
<leon-p>
well, I usually only launch foot, emacs and firefox. thats 1/3 confirmed and I am somewhat sure GTK4 will have support for that so for the other two I only need to wait like four years to get it...
<leon-p>
although window<->pid tracking is more relevant for people who want to clone plan9's window management I guess
AlmostSurelyRob has joined #river
<ifreund>
So for sending frame callbacks and presentation timings we associate each window with exactly one output
<ifreund>
this output is chosen by checking which output the window has the largest overlap in area with
<ifreund>
we can probably use the same heuristic along with the knowledge of which window/shell surface is focused to determine where new layer surfaces without an explicit output should be placed
<ifreund>
we also need this information to send wlr-foreign-toplevel-management output enter/leave events (though I am again tempted to just remove that protocol)
leopoldek has joined #river
<ifreund>
it's also useful to keep xdg popups within the bounds of the output I guess
hush has joined #river
<leon-p>
+1 for removing wlr-foreign-toplevel-management. the ext- version of that protocol should be used instead
<leon-p>
and is general enough that it should not interfer with the WM protocol in any way
hush has quit [Quit: WeeChat 4.3.2]
hush has joined #river
leopoldek has quit [Remote host closed the connection]
angry_vincent has quit [Ping timeout: 240 seconds]
kotto has quit [Ping timeout: 268 seconds]
kotto has joined #river
talismanick has joined #river
talismanick has quit [Ping timeout: 268 seconds]
talismanick has joined #river
talismanick is now known as Guest4674
Guest4674 has quit [Client Quit]
talismanick has joined #river
Guest3 has joined #river
<Guest3>
Hi, I have some problems configuring River on Void Linux on a Thinkpad x201. I followed most of the instructions on voidlinux.org, installed the intel graphics drivers, elogind, seatd, enabled the services. I can start river, but can't launch any terminal. However, I can start firefox or chrome, but all characters are replaced with special chars. I
<Guest3>
used River on Arch before without issues (but on a different machine). Any tipps on debugging this issue?
talismanick has quit [Ping timeout: 255 seconds]
<ifreund>
Guest3: do you have any fonts installed?
<ifreund>
if not, try installing deja vu or something
plusgut has joined #river
<plusgut>
i'm seeing the progress of the rwm branch, and i'm so very excited
<ifreund>
plusgut: there's still a lot of work to do before anything is usable, slowly chipping away at it though :)
<plusgut>
definetly take your time get it right, i'll be waiting patiently for it
<plusgut>
and then i'll build tabs with river :D
<Guest3>
ifreund: thanks, it was as simple as that. But I actually searched in void docs for fonts and found no hint that they need to be installed seperately, but I still feel stupid
<ifreund>
no worries!
<ifreund>
I wouldn't feel stupid, void should probably pull in some font by default when installing programs that don't work without one
AlmostSurelyRob has quit [Quit: Client closed]
leopoldek has quit [Remote host closed the connection]