kode54 has quit [Read error: Connection reset by peer]
kode547 is now known as kode54
cbb has joined #foot
mtm has quit [Ping timeout: 252 seconds]
mtm has joined #foot
<dnkl>
Consolatis: delthas: rockorager: enhanced notification support (implementation of the kitty desktop notification spec.): https://codeberg.org/dnkl/foot/pulls/1776
<dnkl>
do note the limitations wrt notification activation/clicking
<j`ey>
dnkl on fire recently!
<delthas>
wow!
<delthas>
> Since we don't trigger the notification ourselves (over D-Bus)
<delthas>
why?
<delthas>
oh it's sent with notify-send
<delthas>
hm.. from the notification pov the only difference now is that we support specifying the urgency now, right?
<dnkl>
delthas: two reasons: one, foot's design in general is to let user choose what happens, and two, we want to keep foot on the smaller/minimal side, and that means not pulling in too many dependencies
<dnkl>
urgency, and whether to always display the notification, or only when unfocused (though foot's config can override 'always')
<dnkl>
base64 might be nice, though not necessary for most notifications
<rockorager>
dnkl: awesome
<dnkl>
and then we'll see, if there's some way, that fits into foot's design, to add support for report-back events, then we'll add it
<dnkl>
this paves the way, and increases compatibility with other terminal emulators
<Consolatis>
really hacky but useful for testing, from what I remember there is some undocumented notify-send env var that writes the xdg-token to stdout
sewn has quit [Remote host closed the connection]
sewn has joined #foot
rockorager_ has joined #foot
<dnkl>
there are also the -p and -w options
<dnkl>
main issue is we're not hardcoded to notify-send
<Consolatis>
the FOOT_PTY change is likely unnecessary though and the 568 activation hack is obviously completely random
rockorager has quit [Remote host closed the connection]
rockorager_ is now known as rockorager
<dnkl>
Consolatis: the token is from the debug log output from GNOME's notification daemon?
<Consolatis>
from debug log output from notify-send
<dnkl>
ah, didn't know it was glib-based
<Consolatis>
didn't know either. Maybe it could be made to some actually supported command line option instead
<Consolatis>
then foot would only need some xdg activation OSC
<dnkl>
might not need an OSC either. As long as we can define a way to pass all necessary info over e.g. stdout, for example, that can preferrably be done using plain notify-send, then that'd be good enough
<Consolatis>
so foot reading stdout from the notify command directly?
<dnkl>
for example, notify-send as -w. But we have no way of knowing if the script/program we ran actually waited for the notification to close, or just closed right after displaying it
<dnkl>
not currently, but we could
<dnkl>
xdg activation could be passed over stdout
<Consolatis>
yeah, that would be an option indeed
<dnkl>
I guess one solution is to require the program to write the activation token on stdout
<dnkl>
if it does, then that's taken as proof the notification was waited for
<dnkl>
it stdout is empty, or at least has no valid token, then the notification was *not* waited for
<dnkl>
that way, we could support both "focus" and "report" (the 'a' parameter)
<dnkl>
I'll have to think about it for a while
<dnkl>
Regardless, I would also like to merge (or deny) the PR as it currently is, before implementing something like that
<dnkl>
it's a shame he intentionally left out icon support from the protocol... that's something all other notification OSCs also lack
<Consolatis>
yes, I don't understand that either
<Consolatis>
but at least it should be easy to add later on
<Consolatis>
(although "i" is already in use)
<dnkl>
yeah, I=name
<dnkl>
:)
<delthas>
when support for report is added, do you think adding support for dismissing notifications could also be possible?
<dnkl>
delthas: it's not part of the existing protocol. don't know what kovid's stance on it is
<dnkl>
there aren't any technical issues anyway
<Consolatis>
re: report feature: just a random idea, maybe the "waited" state could also be given back via exist code. That way a potential activation token is decoupled from the waiting state
<Consolatis>
exit code*
<Consolatis>
but that would require a user script and likely wouldn't work with notify-send directly.. hrm, nvm
<Consolatis>
(unless -w changes the exit code that is)