<ifreund>
does entering a mode on Super L press and leaving it on Super L release not work?
<ifreund>
I certainly intend for that to work with the current river-xkb-keybinds-v1 prototype
<ifreund>
it might be racy with the currently exposed riverctl commands, not sue
<ThatGuestAgain>
Well.. poorly. I'd have to map release on several combinations of modifiers, In case I let go of Super to early/late. I might enter that mode with 3 'true' modifiers. I've had that leave me in the mode accidantally, it is certainly not 'fearless letting go of all". Also, it still doesn't compose. Yes, I am a crazy person with already about 200
<ThatGuestAgain>
bindings who dreams about adding just as many more...
<ThatGuestAgain>
I've tried hacky 'mode-switch-on-release' things for a while, burnt me too often with being stuck in wrong modes, partially to wrong order of releasing keys, partially because it is tricky to get the conf right. Burnt all modes now at the cost of some biindings.
<ifreund>
sounds like a way to completely ignore modifiers for the release mapping would be sufficient to fix that
<ThatGuestAgain>
Fix, probably. Would still feel like a limiting system for me, but I'm obviously the only one there. So yes, I would be grateful for that.
<ifreund>
limiting in what way? I think at that the semantics are the same as what you want and it's just a question of API/user interface
<ThatGuestAgain>
I can freely combine Ctrl, Super, Alt modifiers, but not freely combine ModeB, ModeN, ModeM. There, suddenly order of pressing them matters, I can't just releas one of them to use another mapping, etc. Unless I explicitly set up a mode for every combination of virtMods implemented with modes, including the transistions between them.
<tiosgz>
not sure to whom to direct this question: how should passing super+modlaunch (or whatever) as modifier be handled? either this is valid and makes the timing matter, or it is invalid and... and what
<tiosgz>
this also relates to what exactly these virtmods are
<ThatGuestAgain>
Modes are (if release is improved) sufficient to arrange mappings in a tree. Virtual modifiers would allow arranging mappings in a multidimensional table (mentally). I would celebrate the table, but I will take the tree if thats all there is.
<ThatGuestAgain>
tiosgz If I understand you correctly, that mapping would just be accassible before releasing Super, not after releasing, again when pressed. (All while L is kept helt, which was pressed while Super was held)
<tiosgz>
so if i only have a mapping for modlaunch t and press super l, t, release everything, the t will be ignored?
<ThatGuestAgain>
Yes. Sent to the window. If you are not touching the keyboard, no modifier is down. No real one, not physical one.
<ThatGuestAgain>
s/physical/virtual oops :)
<tiosgz>
i feel like there's desire for fuzziness here (which i understand and happens to me often too), but the fuzziness somewhat contradicts itself
<tiosgz>
ThatGuestAgain: with the press/release sequence i meant that the t is pressed while both super and l are held. which should activate super+modlaunch t which isn't bound in that example
<ThatGuestAgain>
Oh ok. Well, what happens when you press super+control L, which is not mapped either? Consistently, the window sees it (though it does not now anything about modlaunch, it only sees Super and T)
<tiosgz>
therefore i think timing still matters here?
<ThatGuestAgain>
Wether Super is released before or after T is pressed you mean?
<tiosgz>
yes, this is what the example is trying to make clear
<ThatGuestAgain>
Well... the set of currently pressed keys matters. As it already matters with the modifiers we have. Nothing new here.
<tiosgz>
there is at least one new thing here: one modifier includes another (in a sense)
<ThatGuestAgain>
You get the same 'issue' if you switch to a mode with Super L and then press T. Though I don't see an issue there, realizing what keys I'm actively holding is quasi automatic (in my brain at least).
AlmostSurelyRob has joined #river
<tiosgz>
i'm still not convinced (though you don't need to convince me). with the current state of modes, you need to define many possible variants (as you say as well). how do you predictably know what all these are?
<ThatGuestAgain>
That upcoming window manager thing that was mentioned a few times... will the keybinding system be up to the window manager or remain part of river itself?
<tiosgz>
it's partly river and partly the client. river still keeps track of modes and needs to know all mappings (as far as i recall the current version)
<ThatGuestAgain>
tiosgz I currently can't know that's one of the problems leading to this discussion. Unless I cover all combinations of modifiers (which is ugly) I sometimes end up stuck in a mode that taking the hands comletely off the keyboard whout take me out of.
<ThatGuestAgain>
s/whout/should/
<ifreund>
implementing the "ignore all modifiers for this mapping" to make exiting modes with release mappings reliable should be no problem fwiw
<ifreund>
I'm not yet convinced by rest of the proposal, especially since it seems to me that it should be possible to write a "keybindings compiler" that takes input in your proposed format and tells river how to setup the modes and mappings to implement it
<ThatGuestAgain>
ifreund Just so I have the right takeaway/a clear answer: In contrast, implementing virt. mods *is* a problem, right?
<ifreund>
I'm mostly just not terribly excited about the complexity vs new functionality tradeoff
<ThatGuestAgain>
ifreund Nope. There is a definite difference in expressive power. But I am apparently incapable of explaining it. Or of understanding you. How would you compose modes? They are mutually exclusive.
<tiosgz>
ThatGuestAgain: if you can't know then river can't know either. what i was pointing towards was the "keybindings compiler", anyway.
<tiosgz>
ThatGuestAgain: compose modes by creating another mode that's probably named by the two (or more)
<ThatGuestAgain>
I hope I don't come off as nagging. I'm a little frustrated (by technology, not by you guys)
<ifreund>
I feel like these two concepts should map cleanly to the difference between a deterministic finite automata vs a non-deterministic finite automata
<ThatGuestAgain>
tiosgz That 'compiler' is as limited to the tools river provides as I am.
<ifreund>
it's possible to losslessly convert between a DFA and a NFA
<ThatGuestAgain>
I'm confused. I did not propose anything undeterministic XD. On the contrary, my prior mappings kinda where
<ifreund>
the DFA will possibly have 2^N more states than the equivalent NFA though
<ifreund>
ThatGuestAgain: if that's confusing to you just ignore it. I think it's a pretty useful way to model the problem if you're familiar with the theoretical CS concepts though
<ThatGuestAgain>
You are using words I don't know here... I give up. I did'nt want to start a fight, I'll try to make my explanations clearer before suggesting things again, hopefully then the misunderstandings are avoided.
<ifreund>
(modes = automata states)
<ifreund>
I'm not saying your idea is bad or anything, on the contray I find this quite productive to think about
* tiosgz
happens to have been silent since the mention of "guys" but is otherwise also in a good mood
<ThatGuestAgain>
The problem is every connection between two states has to be *explicitly* mapped, except for 2^(modifiers)*2 implicitly mapped by pressing/releasing modifiers.
<tiosgz>
i suggest to ignore the complexity for a moment and focus on whether it's possible to predictably create (i.e. to have that "compiler")
<ThatGuestAgain>
tiosgz Sorry, I may have the wrong translation there. I thought it meant the same as 'people' but more casual. Now I see it does not and I need to double check every word my (btw female) english teacher tought me :(
<tiosgz>
because i'm still not sure if _that_ is true. if so, my mind can move on
<tiosgz>
ThatGuestAgain: that's okay, i just like to point it out to people cos i probably couldn't stand them using it all the time :)
<ThatGuestAgain>
@' compiler: Maybe. I think not, it feels like no. But I have to properly thoroughly check. It might be possible.
<ThatGuestAgain>
But if it is, the amount of compilerOutputMappings would be `const^(compilerInputMappings / otherConst)` or something similar. (That is when safeguarding against cats walking on keyboards. Optimisations may be possible).
<ThatGuestAgain>
But I'm making estimations here. All I evidently know is I attemted that compiler a few weeks ago in shell, concluded impossibility in frustration, deleted it and touched grass. Which I'll do now.
ThatGuestAgain has left #river [#river]
<ifreund>
I wonder if anyone's made a diagram of the xkbcommon-internal state machine/automata
<ifreund>
I've got modes which can be seen as equivalent to states in an automaton
<ifreund>
I've got transitions defined by keybinds. I notably forgot to specify the behavior of duplicate keybinds so the current draft could be interpreted as a NFA
<ifreund>
If I added epsilon transitions I think it would be trivial to compile ThatGuestAgain's virtual modifiers proposal to this state machine
<ifreund>
allowing duplicate keybind transitions and epsilion transitions would mean that implementing this protocol requires executing arbitrary NFAs in the compositor process though
<ifreund>
I'm not sure that's necessary. I think what I'll do is restrict it to DFAs for now but make sure it can be extended to support NFAs in the future if I want
<tiosgz>
i think i need to read up on this a bit before i'll be able to comment on that nfa thing (having the notion of epsilon/delta from analysis doesn't help here does it)
<tiosgz>
but somewhat related to duplicate mappings i wonder if it makes sense to restrict everything to a single layout (i.e. everything is either mapped to symbols or to codes)
<tiosgz>
(or was this the problem? i don't recall right now)
<ifreund>
I think that problem is solved. The thing I just mentioned is that I don't specify the behavior if the client creates two Super+S keybinds that each transition to a different mode
<ifreund>
I intend to specify that the behavior if two keybinds have the same modifiers, keysym, layout, and trigger is undefined and the compositor is free to send the trigger event to only one of the keybinds
<ifreund>
the Implementation section would probably help get a more concrete mental model
tiosgz has quit [Quit: nyaa~]
<pinpoxIRC>
Heyho, I know this might be controversial but is there any chance (optional) window decorations could be implemented?
<pinpoxIRC>
I'm trying to imitate something like i3's "tabbed" layout.
<ifreund>
pinpoxIRC: it will be possible for window managers to implement server side window decorations when the window management protocol is done
<ifreund>
(they are already supported in the draft protocol, but nothing implements the protocol yet)
<pinpoxIRC>
I'm not sure I understand, sway already has window decorations?
<pinpoxIRC>
ifreund: maybe I'm using the wrong term, I mean this ones (example from sway) https://imgur.com/a/fIlgVnm
<ifreund>
pinpoxIRC: I'm not interested in implementing window decorations in the compositor process. I am interested in moving as much window management state as possible out of the river compositor process into a separate window manager process
<ifreund>
think layout generator on steroids
<pinpoxIRC>
Oh I see. Sorry I think I'm confusing window manager with compositor
<ifreund>
to be fair, they have been the same process in practice on wayland for a while now :D
<pinpoxIRC>
I see, so what today is my layout manager something like stacktile e.g. would be then in charge of the decorations
<pinpoxIRC>
That's even better actually, as I would like to enable and disable them based on the layout
<ifreund>
yep, the window management protocol is a lot of work but will make a lot of cool things possible
<pinpoxIRC>
ifreund: does that also imply that it will be possible to arbitrarily style them? e.g. have the decoration be a different form or 50% widht of the window or such?
<ifreund>
yes, the window manager could render absolutely whatever it wants wherever it wants for window decorations
<pinpoxIRC>
Woahhh that's awesome *.*
<pinpoxIRC>
I want windows95 window borders, while also being a tiling window manager
osaut has quit [Ping timeout: 252 seconds]
osaut has joined #river
<pinpoxIRC>
ifreund: Is there already a roadmap/todo-list for the change yet? If there are some not too complicated tasks I might look into sending a few PRs to help out
<ifreund>
pinpoxIRC: not really, it's currently blocked on me doing the hard, upfront design work
<pinpoxIRC>
Pretty excited for this, sounds too good to be true
<ifreund>
note that there's a lot of relatively straightforward missing stuff as I've been focusing on making sure the trickiest bits are solid first
<pinpoxIRC>
Sounds reasonable
ThatGuestAgain has joined #river
<ifreund>
I'm wondering if -release mappings should be change to check their modifiers when the key is pressed rather than released
<ifreund>
I think that behavior would just be better in general
<ifreund>
I think I'll see what implementing that looks like later
<ThatGuestAgain>
I earlier failed to express that you not wanting the complexity virtMods would bring in the compositor is completely understandable and I accept that of course. Hence, If I want virtMods, I have to implement them outside of river.
<ThatGuestAgain>
Well... I now know it currently cannot be done without an external living process that takes virtMod mapping commands at runtime and utilizes the map command at runtime. That external process might leverage modes, but being alive (not oneshot at init) and using rctl map at runtime is necessary.
<ThatGuestAgain>
I am not going to do that with the current river since the shell detours lead to timing issues. I've been down that rabbit hole. So my new questions:
<ThatGuestAgain>
1. Will the window manager be able to manage keybindings at runtime without the shell detours? 2. My programming experience is limited to scripting. What language should I learn to implement a wm once wms are here? (I guess Zig, do I have other options to choose from?) 3. Crazy idea: might separating window manager and keybinding manager be a
<ThatGuestAgain>
doable thing then?
<ifreund>
ThatGuestAgain: yeah, the current enter-mode command is poorly thought out and inherently racy if used from a script
AlmostSurelyRob has quit [Ping timeout: 250 seconds]
<ifreund>
it avoids the race condition you're currently hitting with enter-mode
<ifreund>
Separating a window manager and keybinding manager may be technically feasible but I don't know if it would really bring benefits or not. I suspect that global complexity would be reduced by keeping those tasks in the same process
<ifreund>
as for what language to learn, any language should be able to interact with the compositor over the wayland protocol
<ThatGuestAgain>
It is not just enter-mode, but one mapping triggering dozens of map calls which might be used in the next split second. So 1. phrased more precisely: Will the wm be able to _create_ mappings at runtime without shell detours?
<ThatGuestAgain>
Yeah well any language that implements wayland-protocol speaking, right? Which are probably not all? Idk, I never quite understood how protocols operate :/
leopoldek has joined #river
<ifreund>
the current design of the protocol is that the client defines a deterministic state machine on the compositor side where states are sets of keybinds and transitions are triggered by pre-defined keybinds
<ifreund>
modifying the state machine may race with incoming key events and this is considered acceptable
<ifreund>
I'm quite confident that your preferred keybinding setup can be translated into such a state machine and am open to extending the protocol to make such a translation easier in the future if needed
<ThatGuestAgain>
And those states are mutually exclusive? I have basically only one variable 'currentState' and I can't compose multiple 'variables' (I'm aware my language here is really unfitting).
<ifreund>
right now the states are indeed mutually exclusive (this is what it means to be a DFA) as I said earlier, your approach of non-mutually exclusive states maps quite directly to a NFA
<ThatGuestAgain>
Oh I see the modifiers are hardcoded in a bitfield there...
tiosgz has joined #river
<ifreund>
and transforming a NFA to a DFA is not terribly complex, it causes a potentially exponential explosion in the number of states though
osaut has quit [Ping timeout: 260 seconds]
<ifreund>
my current vague plan is to keep the protocol restricted to DFAs for now until I can determine whether the memory overhead of translating NFAs to DFAs is too high in practice
<ifreund>
if so, it would make more sense to model an NFA in the protocol and accept that the compositor implementation must get more complex
<ifreund>
I'm sorry if my theoretical computer science terminology makes this hard to understand, it's the most precise way I know to communicate these concepts
<tiosgz>
ifreund: re checking mods at press-time, i think it only needs another field in Keyboard.Pressed.Key? (you probably already know this though)
<ThatGuestAgain>
Well now we can point at why rivers mapping system feels so limiting to me. All state needs to be crammed into that one variable (the mode name).
<ThatGuestAgain>
And the worst part is: there is no way to query what modes (or better, what mappings) exist. If riverctl could just print out a list of all existing bindings, maybe (not sure) an invokable script might be enough for me and I could scratch the living process.
<ThatGuestAgain>
But river is a black hole of information. I need to keep track of all I told it externally. That one variable river gives me is even write-only, no reading.
<ifreund>
tiosgz: that indeed sounds like a good way to implement it :)
<tiosgz>
ifreund: nooo, already force-pushing on a draft branch? :P (well it does make things harder to track)
<tiosgz>
anyway, i think you've missed the possibility of layout-dependent duplicates: e.g. having one binding for d on qwerty and one for s on whatever's current layout, then switching to colemak
<tiosgz>
or maybe i'm misreading. too unfocused today to know for sure
ThatGuestAgain has quit [Quit: Client closed]
ThatGuestAgain has joined #river
osaut has joined #river
<ifreund>
tiosgz: ah, yeah I should probably be specific about that case as well
<ifreund>
I intend to maintain river's current behavior there
<ifreund>
and I only force pushed because I changed a lot of formatting (for some reason I had hardwrapped to 72 instead of 80) so the diff was useless anyways :p
ThatGuestAgain has quit [Quit: Client closed]
ThatGuestAgain has joined #river
<ThatGuestAgain>
I am not sure if I understand that protocol XML correctly. But quickly going over it, it seems it mostly corresponds to what is currently possible with riverctl, right? Nothing new?
<ifreund>
well aside from the fact that transitions between modes can't be racy it's pretty much the same
<ifreund>
and it's actually not sufficient to implement `riverctl enter-mode` for that reason... probably going to need either a breaking change or compat hack to fix that eventually
<ThatGuestAgain>
So no access to the current state of the mapping system either. Well, trying to get my wishes mapped (pun intended) onto the tools river provides wil stick in my head, but I'm off to finish todays 'actual productivity goal'. Have a nice day all!
ThatGuestAgain has quit [Quit: Client closed]
ThatGuestAgain has joined #river
<ifreund>
take care o7
<ThatGuestAgain>
Oh one last thing, I'll try better with the 'implementing myself' from now on instead of suggesting complex things so fast, sorry for that. I'll tell if my virtMod script ever actually ends up working, bye
ThatGuestAgain has quit [Client Quit]
belanthor has joined #river
leopoldek has quit [Remote host closed the connection]
osaut has quit [Quit: WeeChat 4.3.0]
tiosgz has quit [Quit: nyaa~]
waleee has joined #river
hmht has quit [Ping timeout: 272 seconds]
waleee has quit [Ping timeout: 256 seconds]
angry_vincent has joined #river
leopoldek has joined #river
waleee has joined #river
Guest77 has joined #river
<Guest77>
hello i was wondering how to use something like slstatus with river
Guest77 has quit [Client Quit]
osaut has joined #river
osaut has quit [Quit: WeeChat 4.3.0]
angry_vincent has quit [Ping timeout: 272 seconds]
belanthor has quit [Quit: Leaving]
ninewise has quit [Remote host closed the connection]
ninewise has joined #river
talismanick has quit [Remote host closed the connection]