ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
CodeSpelunker has joined #wayland
Calandracas_ has joined #wayland
ryanneph has quit [Ping timeout: 480 seconds]
Calandracas__ has quit [Ping timeout: 480 seconds]
Orko[m] is now known as OrkobackAug5[m]
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
Brainium has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
bindu has quit [Remote host closed the connection]
Guest21913 has quit [Remote host closed the connection]
tzafrir_laptop has joined #wayland
glennk has joined #wayland
wfidna has joined #wayland
karenw has joined #wayland
karenw_ has joined #wayland
karenw has quit [Read error: Connection reset by peer]
wfidna has quit [Remote host closed the connection]
__0x1eaf has joined #wayland
coldfeet has joined #wayland
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
alarumbe has quit [Remote host closed the connection]
coldfeet has quit [Quit: Lost terminal]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
karenw_ has quit [Quit: Deep into that darkness peering...]
kts has joined #wayland
leon-anavi has joined #wayland
valpackett_ has quit [Remote host closed the connection]
mvlad has joined #wayland
sally_ has joined #wayland
sally has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
dcz has joined #wayland
kts has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
diniamo has joined #wayland
sima has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
fatal has quit [Remote host closed the connection]
fatal has joined #wayland
fatal has quit []
fatal has joined #wayland
coldfeet has joined #wayland
fatal has quit [Remote host closed the connection]
dcz has quit [Read error: No route to host]
dcz has joined #wayland
dcz_ has joined #wayland
dcz has quit [Read error: Connection reset by peer]
<diniamo>
With the wl_keyboard.modifiers event always being sent after wl_keyboard.key, how can clients that need both the active modifiers and the key whose state changed in the key event deal with modifier key events? If I have to track the modifier state on the client side, is there a way to get a mod name from a keysym with libxkbcommon?
fatal has joined #wayland
<kennylevinsen>
diniamo: This only affects the modifier keys themselves, i.e. that pressing left shift first sends the left shift key event, then a modifiers event including shift
<kennylevinsen>
I don't see how this would be a problem - the shift modifier shouldn't affect the behaviour of the shift *key*....
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #wayland
<diniamo>
Well, it is in my case. The code is for an abstraction layer that is supposed to send keyboard events for modifier keys (too) with the right active modifiers.
<soreau>
diniamo: you get key events for modifiers in addition to modifier event
<soreau>
but you will need to track modifier state because modifier event can be sent while the client doesn't have keyboard focus
<kennylevinsen>
diniamo: ... but a modifier is still only active *after* the key press that activated it. The shift modifier does not activate until after the shift keypress, and it's a logical error for that shift press to be affected by a modifier change that it caused itself
<soreau>
and on keyboard enter, there's a modifiers array too
<diniamo>
kennylevinsen: that makes sense, I guess I'll leave it like this then. Thanks.
<kennylevinsen>
say, ctrl-alt-delete yields: ctrl down, ctrl modifier, alt down (subject to ctrl), ctrl+alt modifier, delete down (subject to ctrl+alt), delete up, alt up, ctrl modifier, ctrl up, no modifiers
<diniamo>
👍
Moprius has joined #wayland
realsessioneight has quit [Remote host closed the connection]
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
paulk has joined #wayland
coldfeet has quit [Quit: Lost terminal]
feaneron has joined #wayland
alarumbe has joined #wayland
nerdopolis has joined #wayland
diniamo has quit [Quit: diniamo]
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #wayland
narodnik has quit [Quit: WeeChat 4.7.0]
narodnik has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
<dcz_>
so... what's the usual course of action where someone wrote a protocol so badly that people are implementing it different than it's actually written?
<llyyr>
dcz_: i dont think such a thing is documented but everyone agrees on the "different" implementation then just bump the xml to be that version?
Drakulix has joined #wayland
kts has joined #wayland
lileo_ has quit []
lileo_ has joined #wayland
lileo_ has quit []
lileo has joined #wayland
<Consolatis>
dcz_: what protocol is this about? Another option would be to amend the protocol to clear up those points and notify the compositors / clients about it so they can fix their implementation
<dcz_>
yeah, I'm having trouble understanding which of the options would be the desired one
moxie has quit [Quit: WeeChat 4.6.3]
moxie has joined #wayland
moxie has quit [Quit: WeeChat 4.7.0]
moxie has joined #wayland
__0x1eaf has joined #wayland
<Consolatis>
text input / input method is not exactly an area I know much about but it sounds like this is client specific and the two big client UI frameworks do the same thing so maybe the easiest route of action would be to amend to protocol to properly define this behavior
<dcz_>
sounds reasonable. I have to think if there are going to be knock-on effects from that later
ryanneph has joined #wayland
kts has quit [Quit: Konversation terminated!]
leon-anavi has quit [Quit: Leaving]
Spawns_Carpeting has quit []
dcz_ has quit [Quit: Konversation terminated!]
kts has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
coldfeet has joined #wayland
akyoto has quit [Remote host closed the connection]
akyoto has joined #wayland
Brainium has joined #wayland
kts has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
<olivial>
is there a way to correlate ids from ext_foreign_toplevel_list with the toplevels created by your own process?
<olivial>
ie write a client with an interface like "pass me a foreign toplevel identifier referencing one of my toplevels, and I know which one you're talking about"
<Consolatis>
so you want a foreign-toplevel-list handle to get the pid to get the first child of that pid and then its current working directory to open a terminal emulator in the same directory?
<olivial>
yeah, exactly
<olivial>
more generally, want to be able to write something like xcwd that works with daemon terminal emulators (and so requires some cooperation from the terminal)
<Consolatis>
a ext-foreign-toplevel-list handle doesn't provide you the PID of the process
<Consolatis>
in general this sounds more like a terminal emulator feature
<Consolatis>
and doesn't really have anything to do with wayland
<olivial>
it doesn't, the idea was that the terminal emulator would have a mechanism to get the shell pid given a window identifier
<olivial>
the part where wayland comes in is having a notion of "window identifier" that can be used across processes
Drakulix has joined #wayland
<Consolatis>
why does it need any shell pid based on some window identifier? the window already handles the Ctrl-Alt-t keypress and also knows what it started?