groknull has quit [Remote host closed the connection]
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
waleee has quit [Ping timeout: 260 seconds]
snakedye has quit [Ping timeout: 276 seconds]
snakedye has joined #river
vaivis has joined #river
snakedye has quit [Ping timeout: 246 seconds]
Nulo has quit [Ping timeout: 240 seconds]
vaivis has quit [Read error: Connection reset by peer]
vaivis has joined #river
pkap has joined #river
<pkap>
tleydxdy[m]: This not feasible because layouts are very different. We must check both, I think.
<tleydxdy[m]>
would it be possible to lower all keybinds to key codes for checking?
<pkap>
Yes, we do that already. This is what I meant by "raw" keys. Without this,`Super+Shift 1` press would not even work if we only check for for translated `Super Exclam` in the mappings.
<pkap>
My question merely is if we want to have a clear order in which the two are checked or if the do not care about the order.
<tleydxdy[m]>
I mean to check for conflicts
<pkap>
E.g. when having a mapping defined for`Super+Shift 1` and `Super Exclam` and the users hits those keys, should we have a defined behaviour which one is executed.
<tleydxdy[m]>
so like, when receiving a new key bind, lower it to key codes, check if there's already a rule that matches. If there is and it is the same key bind, overwrite it. If it is some other keybind that uses the same keycode, error out
<pkap>
You mean making all mappings based on keycodes instead of symbols?
<tleydxdy[m]>
that could be one way of handling it, I guess
<tleydxdy[m]>
but I just mean when checking for conflicts
<tleydxdy[m]>
you know how if you want to check if two words are the same you case fold them first?
<tleydxdy[m]>
like that
<pkap>
Checking for conflicts would need a layout to base this check on. But layouts can change, so we cannot do that for the present regular mappings. We could do this for the new layout-pinned mappings.
<pkap>
If I understand correctly what you mean.
<tleydxdy[m]>
so you mean if someone binds a key under layout A, which was fine but then switch to layout B which creates a conflict?
<tleydxdy[m]>
just recheck key binds that uses keysyms when user switches layout I guess
<pkap>
No, this is not what I meant
<pkap>
What did you mean by "check conflicts"?
<pkap>
Check conflicts on mapping creation?
<tleydxdy[m]>
yes
<pkap>
Ok, this conflict check is based on a specific layout, correct?
<tleydxdy[m]>
yeah
<pkap>
So which layout would you use for this?
<tleydxdy[m]>
the layout that user has whey they bind that key
<tleydxdy[m]>
there's only a couple ways conflict can be created, when user creates a new bind, or when they switch layouts, so check it then, rather than at every key press
<pkap>
Ok I see what you mean. I don't think this is good idea. This would be quite hacky.
<tleydxdy[m]>
if all keybinds are lowered to keycodes, you'll need to recalculate them when user switch layouts, which is functionally the same ask checking for conflicts again
<tleydxdy[m]>
a/ask/as/
<tleydxdy[m]>
* s/ask/as/
<tleydxdy[m]>
lol
<pkap>
We don't want to translate keysyms to keycodes because it can be ambiguous. This was already discussed after the first iteration of my PR.
<tleydxdy[m]>
that's fine, but you'll still want to check for conflicts tho right?
<tleydxdy[m]>
rather than having the user go on a treasure hunt about why their binds aren't working
<pkap>
I would leave the conflicts.
<tleydxdy[m]>
that'll make one of the bind being disabled silently
<pkap>
Maybe make a clear order which one is triggered in case of a conflict.
<pkap>
Yes, that could happen. But you also could switch to a layout where both mappings are "enabled".
<pkap>
Because of this, it's not a real "conflict". They are different mappings that can happen to fall on the same keys depending on the layout.
<tleydxdy[m]>
I suppose
<tleydxdy[m]>
in that case keysym come before keycode would make more sense imo
lxsameer has joined #river
<pkap>
Hm I am not really talking about keycodes. Keycodes are always translated to Symbols in the current evolution of my PR. (This changed)
<pkap>
Sorry if this was confusing. Maybe I should have created a new PR instead of reworking it completely.
snakedye has joined #river
vaivis has quit [Read error: Connection reset by peer]
pkap has quit [Quit: Client closed]
pkap has joined #river
pkap has quit [Ping timeout: 250 seconds]
pkap has joined #river
pkap has quit [Quit: Client closed]
pkap has joined #river
pkap has quit [*.net *.split]
vaivis has joined #river
mizzunet has joined #river
<mizzunet>
I set Super+Shift+Return to start foot
<mizzunet>
But it doesn't start it
<mizzunet>
None of the mapping works. The config is from GitHub readme
<dnkl>
is your river build also from latest master?
<mizzunet>
No
<mizzunet>
I installed river package which is 0.1.3-2
<mizzunet>
I shall try git package, let me see
waleee has joined #river
<dnkl>
as always, it's important to use a template/example config that matches the version of what you're actually running
<mizzunet>
Same for river-git. I have Sway running tty1 and I started river at tty2
<mizzunet>
Do they conflict?
<dnkl>
doubt it
<dnkl>
is your ~/.config/river/init executable?
<mizzunet>
No
<mizzunet>
Has it to be?
<dnkl>
yes
<mizzunet>
oh
<dnkl>
it's in the man page ;)
<dnkl>
it's not really a config file. it's a bash script
<dnkl>
that runs a bunch of riverctl commands
<mizzunet>
I didn't read man page or anything :P
<mizzunet>
Got it
<mizzunet>
Now it works, thanks (:
pkap has joined #river
amnesiacsardine has joined #river
<amnesiacsardine>
Hello there! I'm pretty new to river. I've read through the docs but I didn't yet figure out how to auto-attribute tags on app launch: i.e. launch firefox with tag 2
<ifreund>
amnesiacsardine: we don't have any feature to do this yet, sorry
<amnesiacsardine>
Ah okay! No problem. It's only my second tiling WM after around a year with Sway so I'm still overwhelmed by all this info sometimes lol wasn't sure if I missed it
<ifreund>
totally understandable :D
<amnesiacsardine>
I very much enjoy the tags concept. Thanks a lot for your work
<ifreund>
glad you find river useful ^^
<amnesiacsardine>
Coming from sway, I wonder what is different with River that makes that issue with gtk decorations. It's not occurring on sway which is also wayland.
<amnesiacsardine>
Yeah it's been a lot of fun learning to use it! :D
<dnkl>
amnesiacsardine: sway implements a legacy, gtk custom Wayland protocol, while river implements the successor. unfortunately, gtk3 only implements the old protocol
pkap has quit [Quit: Client closed]
<amnesiacsardine>
I see. Is the solution the proposed patch to be approved or for more apps to use gtk4?
waleee has quit [Ping timeout: 260 seconds]
amnesiacsardine has quit [Quit: Client closed]
amnesiacsardine has joined #river
<ifreund>
amnesiacsardine: both would be fine, the proposed patch has bugs though iirc
<ifreund>
and I kinda lost interest in working on gtk code
Nulo has joined #river
Nulo has quit [Read error: Connection reset by peer]
Nulo has joined #river
Nulo has quit [Ping timeout: 256 seconds]
groknull has joined #river
groknull has quit [Remote host closed the connection]
waleee has joined #river
amnesiacsardine has quit [Quit: Client closed]
Nulo has joined #river
snakedye_real has joined #river
snakedye_real has quit [Remote host closed the connection]