groknull has quit [Remote host closed the connection]
Guest81 has joined #river
Guest81 has quit [Client Quit]
Guest2972 has joined #river
<Guest2972>
hello, I'm trying river rn and my cursor disseapears as soon as I spawn foot
<Guest2972>
why could it be
<Guest2972>
gg
Guest2972 has quit [Quit: Client closed]
Guest2979 has joined #river
<Shinyzenith[m]>
River hides pointer on typing if you enabled it if I'm not mistaken.
<Shinyzenith[m]>
Check your config file
<Guest2979>
can't find anything
<Guest2979>
the cursor is invisible
Guest2979 has quit [Quit: Client closed]
Guest2979 has joined #river
Guest2979 has quit [Client Quit]
Guest2979 has joined #river
waleee has quit [Ping timeout: 255 seconds]
chipps__ has quit [Quit: WeeChat 3.5]
Guest2979 has quit [Client Quit]
Guest2979 has joined #river
<Guest2979>
fixed it, I'm dumb
Guest2979 has quit [Client Quit]
<tleydxdy[m]>
hmm emacs doesn't seem to be responding to my XKB_DEFAULT_OPTIONS
<tleydxdy[m]>
I swear this wasn't the case before, seem to happen after I started using emacs --daemon, but now that I tried vanilla emacs it's behaving the same
snakedye has quit [Ping timeout: 255 seconds]
vaivis has quit [Read error: Connection reset by peer]
<NickH>
tleydxdy[m]: make sure that you don't also have a ~/.emacs otherwise it will read that and ignore your ~/.config/emacs/init.el
<NickH>
It's working for me on an emacs 29 pgtk build.
edrex[m] has quit [Quit: You have been kicked for being idle]
snakedye has joined #river
talismanick has quit [Ping timeout: 255 seconds]
vaivis has joined #river
lxsameer has joined #river
bfiedler has quit [Ping timeout: 248 seconds]
bfiedler has joined #river
vaivis has quit [Read error: Connection reset by peer]
lxsameer has quit [Ping timeout: 255 seconds]
lxsameer has joined #river
<tiosgz>
looking into 444 (don't send release event for a mapping)
<tiosgz>
first, does it make sense to block a press event for a release-only mapping?
<tiosgz>
i believe that one would want to send both press and release if they map only release
<tiosgz>
(i.e. a pass-through mapping)
<tiosgz>
second, is it acceptable for Seat.handleMapping to return true even if it handled nothing, or should i try to make the keyboard store handled presses?
<tiosgz>
the issue with handleMapping is that it always looks at the current mode, rather than the one at the time of pressing the key (as noted in the issue)
<tiosgz>
oh nvm (re 2), forgot that i can't expect the mods to stay the same
<ifreund>
tiosgz: I'm not really sure trying to eat the press event for -release mappings is worth it
<ifreund>
I could be convinced otherwise with a concrete use-case I suppose
<ifreund>
I don't even really know what people use -release mappings for tbh
<tiosgz>
i'm trying to say it doesn't even make sense
<ifreund>
yeah, I agree
<tiosgz>
either you map both press and release and it's both eaten by press, or you want a -release mapping to pass the event through i believe
<ifreund>
does anyone here use -release mappings for anything?
<nor[m]>
Yeah me
<tiosgz>
ratherr: does anyone here use *unpaired* -release mappings for anything?
<nor[m]>
Basically making Caps an additional modifier
<ifreund>
interesting
<nor[m]>
forgot "None" between "caps" and "Menu" in the -release line sry
<tiosgz>
got that same idea today :D
<tiosgz>
but i meant 'unpaired' as: only the release is mapped to something, the press should ideally be dead
<tiosgz>
(or [the press] should be passed through)
<nor[m]>
Yeah so my example would be a "paired" one right?
<tiosgz>
yes. pressing Menu does something, releasing it does something
<nor[m]>
Even "riverctl map-pointer caps None BTN_LEFT move-view" works as intended lol
lxsameer has quit [Ping timeout: 246 seconds]
vaivis has joined #river
vaivis has quit [Read error: Connection reset by peer]
<tleydxdy[m]>
I used to use on release hotkeys for screenshot
<tleydxdy[m]>
but I didn't add it in river
<tiosgz>
why -release?
<tleydxdy[m]>
It's back in X, not under river. I forgot the exact reason but without it it was causing trouble
<tiosgz>
in that case i think it's because of grabs, therefore irrelevant on wayland
<tleydxdy[m]>
yeah, could be
snakedye has quit [Ping timeout: 246 seconds]
snakedye has joined #river
<tleydxdy[m]>
imo both would be "intuitive" but not eating the press event would give more options
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
vaivis has joined #river
anniehallmoon has joined #river
waleee has joined #river
<tleydxdy[m]>
<NickH> "It's working for me on an emacs..." <- hmm, I'm on emacs 28 still, and no pgtk
<tleydxdy[m]>
maybe it's a xwayland thing?
<tleydxdy[m]>
it does seem like it now, my escape was not working, pkill -9 Xwayland, escape working again
<leon-p>
A bit sad that emacs chose to port to GTK instead of having its own wayland backend. From what I know, the Wayland rendering model fits better to its internals than X11, so it would be possible to remove a lot of the cruft that build up around that part of the code. But then again, emacs is a bastion of nonsensicle backwards compatability, so that wouldn't happen either way...
<tleydxdy[m]>
and if I start fresh river, start emacs, escape works, fresh river start emacsclient, escape no work, and after that emacs also have escape not working
<tleydxdy[m]>
only way seem to be to kill Xwayland, wth
vaivis has quit [Read error: Connection reset by peer]
ayushnix has quit [Quit: Client closed]
lxsameer has joined #river
lxsameer has quit [Ping timeout: 246 seconds]
lxsameer has joined #river
<waleee>
tleydxdy[m]: you need to have a emacs compiled with the --with-pgtk (or similarily named) configure flag enabled
<mizzunet>
Hi
<mizzunet>
Can I run apps as different user in wayland? I want Wine to be started as different user.
<mizzunet>
There's a way for X mentioned in Wine Archwiki. I wonder if there's a way on wayland
<lordmzte>
do people tend to write river configs in zig or is that just a weird idea i had? :P
<nor[m]>
<ifreund> "nor: You'd need to have the same..." <- Missu: I asked this recently. I citated the answer I was given for you.
<mizzunet>
So, did that work?
<mizzunet>
What should WAYLAND_DISPLAY be?
snakedye has quit [Ping timeout: 246 seconds]
<nor[m]>
I did get it to work by chmodding stuff in /run rudimentarily, but it was a mess (worked for some apps and not for others).
<novakane>
nor[m]: note that when you quote a message with matrix we don't have it fully displayed on IRC
<nor[m]>
Yeah I guessed that could happen, Missu is a matrix user as well though, so i figured it would be fine.
<novakane>
lordmzte: most people probably use a shell scripts, I don't think a lot of people have tried something else, or maybe some simple things like lua or python
<nor[m]>
Missu: I'll dig out how I did it exactly, give me couple minutes.
<mizzunet>
👍
snakedye has joined #river
<nor[m]>
Ok so I used chmod to give the second user access to /run/user/1000/ and /run/user/1000/wayland-1 . *Be aware this might break stuff, especially might break isolation between users in ways you do not want. I am *not* a security expert, judge for yourself if you want to do this.* Then, after "su test" and launching foot/nautilus/pcmanfm, these appeared in the first users river session. Some things are broken though, I currently have paused
<nor[m]>
experimenting with this due to different priorities.
<mizzunet>
thank you (:
<nor[m]>
Tested on NixOS, in case Distribution matters/makes a difference here (probably doesnt)
<nor[m]>
I just made another -release binding: vlobal push-to-talk (mute on release), but also a "paired" one.
<nor[m]>
s/vlobal/globel/
<nor[m]>
I cant write xD
<tiosgz>
i mostly wanted to know if someone has a use case for '-release'-only and what behaviour is expected
notzmv has quit [Ping timeout: 244 seconds]
<tleydxdy[m]>
waleee: why won't emacs under X work?
<waleee>
it do work with xwayland (with or without pgtk) for me, but it sounded like you had some issues
<tleydxdy[m]>
yeah, it's not respecting the XKB_DEFAULT_OPTIONS for some reason, and only if I start with emacsclient
<Shinyzenith[m]>
Emacs gcc waylsnd devel bin package exists in aur
<Shinyzenith[m]>
For native emacs wayland experience
<tleydxdy[m]>
I suppose I should switch to X to see if it's a emacs thing or a Xwayland thing
<tiosgz>
i think i know what's wrong with the eaten_keycode, & my question is actually quite confusing without further context
<tiosgz>
i'm trying to avoid eaten keys to appear in wl_keyboard::enter
<tiosgz>
but since the mapping is handled (and focus switched) before it can be added to eaten_keycodes, it reports also the key that should be eaten
<tiosgz>
duh
<tiosgz>
not sure how i'd go about fixing this. but i'm not sending a PR without it, coz it breaks nested wlr compositors even more now without the release event
<tleydxdy[m]>
so the client only sees a key pressed but not key release?
<tiosgz>
yeah. if focus is switched to it due to the mapping
<tiosgz>
(it doesn't receive a key press event, but wl_keyboard::enter)
<tleydxdy[m]>
hmm what happens if the client is already the focus?
<tiosgz>
then it receives neither event and everything is okay
<tiosgz>
(with my patch, that is)
<tiosgz>
i think it can only be worked around by delaying the focus switch a little, but not sure how to do that cleanly
<tiosgz>
look up mappings first, execute them later?
<tleydxdy[m]>
why would the enter event be problematic?
<tiosgz>
because it includes info about what keys are currently held down
<tiosgz>
and with status quo i can't easily filter out that one key that early
<tleydxdy[m]>
aren't the keys already released?
<tiosgz>
1. key is pressed 2. river looks up and executes mappings, including the focus switch 3. river eats the key (4. the key is released, 5. river spits the key)
<tiosgz>
the problem is that 3. happens after 2.
<tiosgz>
but it cannot be before it because it doesn't know the key is mapped
<tleydxdy[m]>
so this is not a on-release thing then
<tiosgz>
no, this is another issue which is only connected to it
<tleydxdy[m]>
say I meta+j to switch to the next client, that client would see that meta and j are pressed, baaically
<tiosgz>
try running a nested river with a terminal in it, switch to another tag in the outer river and back to the original tag. the terminal will have a number in it
<tiosgz>
but now if the outer river eats the release event, the nested one supposes the key is still pressed
<tleydxdy[m]>
the number of the original tag or the other tag?
<tiosgz>
tleydxdy[m]: yeah, i think so
<tleydxdy[m]>
tleydxdy[m]: tbh this seem like a unnecessary leak
<tiosgz>
it's not important which number, but that it's there (but it's the current == original tag, fwiw)
<tleydxdy[m]>
yeah, to me it seem like the client shouldn't know these things to begin with
<tiosgz>
it shouldn't, but you must send the event because otherwise keyboard interaction would be broken
<tiosgz>
i only find filtering out the key quite hard in this case (see the numbered list above)
<tleydxdy[m]>
why? since the combination of those keys would always be intercepted by the compositor anyway
<tleydxdy[m]>
there's no way for the client to make use of them
<tiosgz>
modifiers (otoh, there's a separate event for them)
<tleydxdy[m]>
say I press meta+j to switch to the next client, the client sees that no keys are pressed currently (we filter those out), the client do have a function bind to meta key, what would the user do? they would release meta (client doesn't know it) and press meta again to trigger that function
<tiosgz>
only j is (should be) filtered out
<tleydxdy[m]>
hmm maybe some real examples, a game has ctrl to crouch, it would be kinda strange to be if say I switch focus with ctrl+j and suddenly the character crouched
<tleydxdy[m]>
it would be more error free if I need to release ctrl and press it again to trigger stuff for the client
<tiosgz>
usually clients only react to press, not enter or release, so you're okay
<tleydxdy[m]>
so you are saying thay the keys field in enter is not used
<tiosgz>
usually not. but some clients (ahem ahem wlroots with wayland backend) use it
<tleydxdy[m]>
okay, we can switch the example client to those then
<tleydxdy[m]>
same applies, to me it's more natural if I need to press the keys again after whatever I did to switch focus
<tiosgz>
i'm not sure how i'd handle it in that nested compositor given there's a lot of abstraction; i'd prolly keep it as it is
<tleydxdy[m]>
yeah, ig my position is that if the compositor handled some keys the client ought not to know they where pressed, so that we never get a single "key press" triggering two things
<tleydxdy[m]>
be it with key events or enter events
<tiosgz>
in your meta-j example, eating j completely is pretty much what i want to achieve
<tleydxdy[m]>
I think both meta and j should be eaten
<tiosgz>
but eating meta is not reasonable imo: 1. on pressing just meta, you can't know it's gonna be a mapping 2. once you notified about a press, you must notify about a release
<tleydxdy[m]>
yeah
<tleydxdy[m]>
send a fake release if needed
<tiosgz>
that would be confusing and the very least, both in code and in UX
<tleydxdy[m]>
so you are saying that we only eat the last pressed key?
<tiosgz>
it's better to send the release only once the key is actually released
<tiosgz>
yes, kind of
<tleydxdy[m]>
so if I do j+meta it eats meta instead?
<tiosgz>
we eat every key that triggered a mapping
<tiosgz>
j is a symbol key, meta is a modifier key
<tiosgz>
i don't think it would trigger a mapping (except perhaps release) at all
<tleydxdy[m]>
yeah that's kinda confusing
<lordmzte>
<novakane> "LordMZTE ⚡️: most people..." <- well, i mostly meant zig because river is written in it and it should be possible to directly use the IPC interface instead of calling riverctl. if you check the code, youll see that riverctl is actually pretty simple, so it should be easy to just do what it does and improve performance quite a bit by saving the overhead associated with spawning a child process and reestablishing a new connection
<lordmzte>
each command.
<tleydxdy[m]>
tleydxdy[m]: ig it doesn't really matter in this case
<tiosgz>
lordmzte: i do have a wip init in zig, but it isn't just a simple copy-paste for me. i may be dumb though
* tleydxdy[m]
just realized I can't have a two key binding
<tiosgz>
tleydxdy: like j-k? look at nor's Menu mode earlier today
<tleydxdy[m]>
yeah it would be some sort of hack ig
<tleydxdy[m]>
what would be the reason for a client to know the currently held keys when it gets keyboard focus?
<tleydxdy[m]>
like the usecase
<tiosgz>
ifreund: what would you say to `Seat.getMappings(...) *TailQueue(*Mapping)` or something alike instead of Seat.handleMapping?
<tiosgz>
tleydxdy: nested compositor :P
<tleydxdy[m]>
tiosgz: why?
<tiosgz>
e.g. file managers with their drag-and-drop (shift/ctrl mods)
<tleydxdy[m]>
ah
<tleydxdy[m]>
right, drag and drop is a thing
<tleydxdy[m]>
err
<tiosgz>
nested compositor coz it's a complex enough client