<nmeum>
is there any way to got the PID of the current window when using river?
<nmeum>
*get
mark- has quit [Ping timeout: 272 seconds]
Keeto has joined #river
Keeto has quit [Ping timeout: 245 seconds]
Keeto has joined #river
bitblt has joined #river
Keeto has quit [Ping timeout: 265 seconds]
Keeto has joined #river
alexherbo2 has joined #river
Keeto has quit [Ping timeout: 252 seconds]
<leon-p>
nmeum: no, there is not
<nmeum>
is there a reason for that? should be possible to obtain this information via wl_client_get_credentials from within the compositor and expose it via a river-specific protocol, no?
<nmeum>
context is: I would like to use https://github.com/blinry/ycwd#readme with river, but can't without being able to obtain the PID of the focused window
<leon-p>
usually the reason why river doesn't have some feature is "because no one implemented it"
<leon-p>
although in this case, a mapping between windows and PIDs isn't actually straight forward
<leon-p>
I don't have the details in my head right now, but IIRC you can't guarantee that the PID you get as the server is actually the process in control of the window
<leon-p>
f.e. with multi-process programs like firefox it's messy
<nmeum>
sure, not a problem for my use-case as wl_client_get_credentials will work correctly for single-window terminal emulators
<leon-p>
river generally doesn't implement half-baked, maybe-works-here-but-not-there features
<nmeum>
so, a patch adding that will likely not get accepted?
<leon-p>
possible workaround: have a keybind in your terminal which opens a new one. Pretty sure foot supports spawning a new instance with the same working dir as the current instance
<leon-p>
yes, I don't think so
<leon-p>
also also because riverctl isn't supposed to be a program used to get river status
<nmeum>
but this doesn't have to be part of riverctl
<leon-p>
sure, a custom protocol could be used, but that doesn't solve the other issue
<nmeum>
presently, the issue is that the PID is not exposed in any of the protocols. having it in a protocol should be sufficient
<leon-p>
it's not in any protocol for a good reason
alexherbo2 has quit [Remote host closed the connection]
<leon-p>
does your terminal set the window title to the current working dir?
<leon-p>
you could parse that f.e.
<leon-p>
still a bit hacky, but arguably possible
<nmeum>
I would personally prefer something that operates on the compositor level, that way (under the limitations outlined above) the functionality is not just limited to focused terminal emulator windows
<leon-p>
sure, but not by hoping the PID you get from the wl client is the right onw
<leon-p>
*one
<leon-p>
to properly support this, one would need a protocol which clients can use to set their PID, or better yet their current working directory
<leon-p>
you can of course patch river locally to have an extra get-focused-pid command, should be fairly simple
<leon-p>
but that isn't upstreamable IMO
<ifreund>
I don't have the details of wayland toplevel to PID mapping in my head right now so I can't say for sure whether I want this exposed by river or not
<ifreund>
the mapping is 100% not robust enough to use for security purposes due to races on client destroy
<leon-p>
there was an extensive thread on the wayland-devel mailing list about 1.5 years ago I think
<ifreund>
indeed, there was lots of discussion about this as security-context-v1 was designed
<nmeum>
would it be useful to move this discussion to a codeberg issue? could collect references to these ml posts there and would also be a good reference point to other users interested in this feature
<ifreund>
nmeum: sure, having an issue for this would be a good idea