nojob has quit [Read error: Connection reset by peer]
nojob has joined #foot
nojob has quit [Remote host closed the connection]
nojob has joined #foot
kmarius has quit [Ping timeout: 240 seconds]
nojob has quit [Quit: Quit]
kmarius has joined #foot
bapt has quit [Ping timeout: 252 seconds]
bapt has joined #foot
nojob has joined #foot
gtms has joined #foot
novakane has joined #foot
pflm has joined #foot
<pflm>
Hi! I have one question... what is the reason why are desktop notification inhibited when the terminal has focus?
<rumpelsepp>
I figure you do not want your e.g. chat client spaming notifications whan it has focus.
<rumpelsepp>
*when
<w0rm>
the idea is - if the window has focus you are likely looking at it and additional notifications are just noisy
<pflm>
My use case is actually a bit different. I have a long running task inside a tmux pane, such as a long compile. I want to be notified when it has finished while working on things on other panes.
<pflm>
Err, not panes, tmux windows ...
<pflm>
Would it make sense to add an option to not inhibit on focus?
<rumpelsepp>
I have the same usecase… 😀 But you can ring the terminal bell and I think you can then let foot issue a notification.
<rumpelsepp>
There is a tmux setting somewhere
<rumpelsepp>
disadvantage: no text payload
<pflm>
Curerntly I'm using "tmux display" to show a notification in tmux, but that's not really what I want.
<w0rm>
pflm: command-focused foot.ini config option is not enough?
<pflm>
w0rm: Is that just for the bell? The notifications do carry a title/body text attached to it, which is what I want really.
<pflm>
Wait, I'll try it.
<w0rm>
you can also just set up post-command handler in your shell to run a notify-send if you want and that will work regardless of focus
<w0rm>
and will actually have whatever information shell has (command that was running, how long it was running for etc)
<rumpelsepp>
notify-send doesn't work with SSH session. That's why the terminal notification feature is this sexy
<pflm>
w0rm: That's true, but I'm working 50% of the time remotely over SSH. That's why the desktop notification over terminal might really be good for tihs.
<w0rm>
well sure, but you can't really get more than "BEL was run in the terminal" over SSH unless you do weird tricks...
<pflm>
w0rm: Actually you can with OSC777
<pflm>
That's what I use: printf "\e]777;notify;%s;%s\a" "$title" "$*"
<pflm>
I can probably add an option to foot to ignore the "inhibit on focus" behavior, but does it have any chance of being integrated into foot? If not, I think I'll just live with the tmux notifications.
<w0rm>
ah, fair enough
<rumpelsepp>
I would be a user of this setting, too. :)
<dnkl>
pflm: w0rm: OSC777 is currently hardcoded to be ignored when we have keyboard focus. But having an option for that makes sense
<pflm>
dnkl: Should I try to submit a pull-request? It might take a long time though since I don't really have much free time.
<dnkl>
pflm: please do, we don't have any deadlines, so it's ok to take time :)
benbrown has quit [*.net *.split]
avane has quit [*.net *.split]
<pflm>
dnkl: Ok, in that case I might actually give it a try! thanks!
benbrown has joined #foot
avane has joined #foot
<dnkl>
pflm: hardest part is probably going to be figuring out what the new option should be called :D
<w0rm>
pflm, dnkl: maybe just have the "urgent" be a "yes/no/always"
<dnkl>
w0rm: urgent is related to BEL, while this is about OSC-777, which doesn't set the urgent state. Furthermore, "urgent" requests are typically ignored by the compositor when the window is already focused
<w0rm>
ah, right
nojob has quit [Ping timeout: 264 seconds]
nojob has joined #foot
nojob has quit [Ping timeout: 245 seconds]
nojob has joined #foot
nojob has quit [Read error: Connection reset by peer]
<dnkl>
ericonr: I was kind of expecting that reply... GNOME libraries, including librsvg are almost never valgrind clean. They don't seem to realize that 1000 false positives hide real bugs... but oh well.
nojob has quit [Quit: Quit]
<dnkl>
I'm going to leave that call in there, for now at least. It's the last thing we do before exiting. Asserting there is "ok"
<dnkl>
though, I guess we _could_ exclude it from release builds
<ericonr>
dnkl: lol, at least it isn't SDL2 :P
<ericonr>
I think excluding from release builds (or based on the value of NDEBUG?) makes sense, otherwise any core dump collector will get filled up for no reason
<dnkl>
Yeah, will do
<dnkl>
Will also take a look at adding nanosvg as an optional SVG backend. Or maybe even replace librsvg...
<dnkl>
In any case, it would allow fuzzel to render SVGs also when compiled without cairo support
<ifreund>
not depending on GNOME code is usually a good choice
<ericonr>
dnkl: did you read the entire issue? apparently nanosvg can't do <text> element
<ericonr>
so it isn't that the icon is broken, it just triggers edge cases...
<dnkl>
ifreund: that's why cairo+librsvg (and libpng, for that matter) is optional dependencies :)
<dnkl>
ericonr: I did... And yeah, saw that. Nanosvg _also_ didn't render the black border around the icon
<dnkl>
but that could of course be because it stops rendering when hitting the text element
<dnkl>
or because the border is another unimplemented feature in nanosvg
yyp has quit [Ping timeout: 250 seconds]
<ericonr>
might be unimplemented, since what made teh bug appear in librsvg was that text was the last element
<dnkl>
PR is up now, removing the cairo reset debug stats call in release builds, and resetting the cairo path before drawing the border
<ericonr>
anyway, most talk I've seen online seems to like pixman for rendering. is the api really taht good or is it just because it's a tiny thing?
<dnkl>
ericonr: it's what cairo's "image" backend uses
<dnkl>
and librsvg uses cairo, so...
<dnkl>
I use it extensively in all my projects
<dnkl>
but it doesn't do SVGs natively
yyp has joined #foot
tdeo has quit [Remote host closed the connection]
gtms has quit [Remote host closed the connection]
novakane has quit [Read error: Connection reset by peer]