<lilblacky>
Is there an rss feed for the foot repo on codeberg to subscribe to? Like master.atom to track commits on github, or releases.atom to track releases.
<lilblacky>
Versus a bookmark to the codeberg site to follow activity, feeds to track dev would be much welcome.
<lilblacky>
I see. Very good. Hope it pushes through.
<lilblacky>
Lol
novakane has joined #foot
themainman has joined #foot
<lilblacky>
Anyone have a handy script to start foot server in the background on sway?
<dnkl>
lilblacky: why not just start it directly from the Sway config?
<ifreund>
^
<ifreund>
Is there any way to change the font settings of foot at runtime? I use a rather small bitmap font most of the time but it's too small for screen sharing. My current solution is to comment/uncomment lines in my foot config and restart foot but a keybind would be nicer if possible.
<dnkl>
ifreund: unfortunately not. What I do under those circumstances is to start foot fun the command line, specifying the font with the -f,--font option
<dnkl>
s/fun/from
<ifreund>
ah, I could totally have a separate binding in river to spawn a foot with large font size yeah
<dnkl>
(which you could create a custom river key binding for ;) )
<dnkl>
😂
* dnkl
is running notcurse-demo on the pinebook pro - and it's not too bad
<dnkl>
even (most of) the sixel stuff (which is CPU intense) is ok
<lilblacky>
dnkl: of course...start the server in the sway config...lol...up and running...thanks!
<dnkl>
lilblacky: you're welcome :)
<lilblacky>
One issue I noted and perhaps it is by design, mouse selection foreground/background does not apply to sections of text which are colored e.g. a syntax highlighted section bleeds colors through (for lack of a better description). I'll see if I can post a pic
<ifreund>
I'm pretty sure that's intentional...
<ifreund>
selection just swaps fg and bg
<lilblacky>
Aha...
<dnkl>
lilblacky: by default selection swaps fg/bg
<dnkl>
but you can override that
<dnkl>
by manually setting selection-background and selection-foreground
<dnkl>
lilblacky: that looks like it's swapping fg/bg. I.e. selection-foreground/selection-background hasn't been set?
<lilblacky>
Aha. Let me set and see...
<lilblacky>
Bingo! Thanks again.
<lilblacky>
Does footclient follow resize-delay-ms?
<dnkl>
lilblacky: it should, yes. But don't forget you need to restart the *server* after each config change
<dnkl>
footclient is basically just an IPC to the server, instructing it to open another window
<dnkl>
i.e. footclient doesn't use the config
<lilblacky>
I notice that when a window resizes that there is a delay before footclient resizes. No issues with foot.
<dnkl>
hmm, you mean the window itself, or the application running in the terminal?
<lilblacky>
App running in the term.
<lilblacky>
The window is immediately resized but the app centers itself fist and then resizes
<lilblacky>
Fist = first
<dnkl>
and just to double check... you did restart the foot server?
<lilblacky>
Say two windows are open. Close one and the window resizes. The app resizes after centering with a slight delay. Yes, server restarted, sway exited and restarted between changes.
<lilblacky>
1.8.2 +pgo -ime -graphmes if that matters
<dnkl>
lilblacky: centering... that should be foot's doing, not the app. You have pad=... center set?
<lilblacky>
No default 2x2. No issues with foot. App resizes as expected. Only footclient
<lilblacky>
Option is commented out. I'll include it explicitly and restart and see
<dnkl>
lilblacky: that's really weird, and should not be possible. It's the exact same code that runs in both the foot, and footclient cases
<lilblacky>
No go. The app centers itself before resizing to its window with footclient.
<lilblacky>
Foot is a-ok
<dnkl>
lilblacky: which app?
<lilblacky>
So far..kakoune. Links. Nano.
<lilblacky>
Tmux.
<dnkl>
I'll try to reproduce as soon as I get the opportunity.
<lilblacky>
Nnn. Cool.
<lilblacky>
Sway 1.6.1 for reference
<dnkl>
lilblacky: and you have resize-delay-ms=0?
<lilblacky>
Yes. Should set it back to default?
<lilblacky>
Lemme try
<lilblacky>
No go there
<lilblacky>
Debian sid. I'll try try the distro package (1.6.4) and see what happens
<dnkl>
lilblacky: there are a number of very confusing things here
<dnkl>
first, resize-delay-ms only applies to interactive resize, not instant resize like when closing/opening windows in sway
<dnkl>
(but then that explains why there's no difference when you revert to the default resize-delay-ms)
<dnkl>
but, also, "the app centers itself" shouldn't be happening...
<dnkl>
apps don't center themselves, afaik. Foot would do that, is you had pad=...center. But you don't
<dnkl>
unless I'm misunderstanding what you mean with "centers itself"
<dnkl>
and the fact that foot and footclient behaves differently is just bizarre... it shouldn't be possible.
<dnkl>
can you record a video?
<dnkl>
i've tried a couple of apps (nano, kakoune) in Sway master, with foot and footclient, and I don't see any delays at all, regardless of resize-delay-ms
<dnkl>
which is the expected behavior...
<dnkl>
lilblacky: in addition to a video, can you run "echo -e '\e[>c'" in both foot, and footclient, and check that a) they return the same result, and b), the result contains 010802 (for foot-1.8.2)?
<lilblacky>
Sure. Will record one now. I'll run the commands now
<lilblacky>
Both output 1;010802;0c
<lilblacky>
Ok
<lilblacky>
Before the vid
<lilblacky>
Closing apps gracefully e.g. q or ctrl-q then the app resizes with the window
<lilblacky>
It seems as if the issue is present when using the kill keybind in sway
<lilblacky>
So it may be sigterm/sigkill issue. Not sure. Can you try killing apps with the sway kill keybind to see?
<lilblacky>
Issue also occurs with 1.6.4 distro package
<dnkl>
aha... that suggests something different entirely. I haven't reproduced yet, as I'm currently in river, not Sway.
<dnkl>
but, this explains the centering
<dnkl>
it's not foot, or the app that is centering itself
<dnkl>
it's sway that centers foot's last rendered surface
<dnkl>
i.e. sway resizes the window, but for some reason, foot either hasn't rendered a new (resized) surface, or hasn't been told (by sway) to re-render itself
<dnkl>
i.e. the delay is in sway -> foot. Not foot -> app
<dnkl>
that might explain why there's a difference betweeen foot and footclient
<dnkl>
with foot, the entire process disappears and the wayland socket is closed when the window is closed
<dnkl>
but with footclient, the server process, which owns the wayland socket, is still alive
<dnkl>
it's possible this triggers a different behavior in Sway
<dnkl>
unfortunately I still cannot reproduce... tried with both Sway 1.6.1 (wlroots 0.14.1), and sway+wlroots master
<dnkl>
hmm, or maybe... when using Sway's kill binding, there's a quick flash of the wallpaper, that isn't there when exiting the application
<dnkl>
but then, for me there's no difference between foot and footclient. Both produce a flash of the wallpaper when killed via Sways key binding
<dnkl>
and I don't see anything like this in river
<dnkl>
so right now, I'd say this looks like a Sway issue. It's possible foot can/should do things differently when tearing down the window, but I don't know what would be
<dnkl>
lilblacky: no worries. I think your video fits into my assesment above
<dnkl>
lilblacky: fwiw, the delay is *much* longer than the short wallpaper flash I was seeing
<dnkl>
what happens if the remaining window is another wayland terminal (alacritty, kitty)? Do they behave the same when you close a foot/footclient window next to them?
<dnkl>
or what if the remaining window is a regular foot, and you close a footclient next to it?
<lilblacky>
Lemme try
<lilblacky>
Alacrity behaves as normal. Foot behaves as normal
<dnkl>
ok... final test ;) let the remaining window be a footclient, and the window you close a regular foot
<lilblacky>
Behaves as normal. Interesting.
<lilblacky>
Lemme double check that one
<lilblacky>
Yep. Triple checked. If remaining window is footclient and a foot window is closed, the footclient resizes as expected
<dnkl>
lilblacky: the wayland connection is shared between all footclients. So what happens is probably that something in the teardown process takes time, which blocks other footclients from processing *their* wayland events. A 'configure' event (i.e. to resize) in this case
<lilblacky>
I'll build foot/footclient on a few workstations in the next few days and report back. Perhaps my system is too slow even built minimally (less than 550 packages) as others have not reported the issue. Besides, foot is easily responsive enough not to have to run footclient :)
<lilblacky>
But what you propose as the issue is likely. However, this happens with just two instances of footclient. thanks for the awesome support! Foot needs more attention from the community. I have been on it for two weeks and aim to push this to others. 4-5x less mem per term instance than Alacritty is what I am seeing so far.
<dnkl>
thanks :) it _might_ be possible to move the termination of the client application from *after* the window has been destroyed, to *before*. If this can be done, it would mean a small delay from when you press the kill key til the window disappears, but other footclient windows should be able to respond to the resize events immediately. Assuming terminating the client application is what's taking
<dnkl>
time...
lechner has quit [Quit: WeeChat 3.0]
<lilblacky>
So I just built 1.8.2 +pgo -ime -graphmes on an i5 8-core w/ 32g ram. Sway 1.6.1. Wlroots 0.14.1. Reproduced the same issue.
lechner has joined #foot
<lilblacky>
Different workstation.
<lilblacky>
I'll have access to more stations tomorrow and see what happens under gnome 3.
<dnkl>
it's "WIP" because I've only tested it briefly, to ensure we're still shutting down properly
<dnkl>
if it does seem to fix your issue, then I'll run some more thorough testing on it
Lord has joined #foot
<lilblacky>
Will do after some zzzs
lilblacky has quit [Ping timeout: 276 seconds]
lilblacky has joined #foot
<lilblacky>
Lol..forget sleep...
<lilblacky>
What happens is exactly as you described; kill is delayed but the issue with the resizing is resolved.
<lilblacky>
Which is preferable to the visual distraction of the previous behavior. Unless you happen to want to quickly kill the pr0n you have been watching :)
<lilblacky>
The patch affects foot as well as footclient
<dnkl>
lilblacky: great, thanks! Yes, I think this is preferable. Let me just test it a bit more, especially all error paths, and then I'll merge it
<lilblacky>
Maybe introduce it as a option? That way those unaffected will retain the immediate kill behavior they are accustomed to. Dunno. Need some zzzs for real. Be back later!
<dnkl>
nah, I think this will go in as it is. It's more correct in a sense - we don't close the window until we've *actually* terminated everything.
<dnkl>
if people start complaining we can reconsider adding an option
fluix has left #foot [WeeChat 3.2]
ericonr has quit [Ping timeout: 240 seconds]
ericonr has joined #foot
lilblacky has quit [Ping timeout: 252 seconds]
<Arnavion>
Are the distros packaging yambar just enabling both backends? Feels like a waste to pull in the X deps if you just plan to use it with wayland
<ericonr>
eh, most people probably use xwayland too
<Arnavion>
Yes, but xwayland doesn't require all the deps that backend-x11 does
<Arnavion>
on my distro at least
<dnkl>
Arnavion: no idea actually. I guess one could provide two packages?
<Arnavion>
Yeah, that's what I'm thinking for OpenSUSE. yambar-x11 and tyambar-wayland
<ifreund>
honestly, if that kind of thing really matters to you you'd probably be happier on gentoo or something :P
<ifreund>
I don't think it makes enough of a difference to justify two separate packages
<ifreund>
(though the void package should probably have a build option)
<Arnavion>
I mean, from the packaging POV it's not hard or anything. rpm makes it easy to build multiple packages from the same source within the same specfile
<ericonr>
that is a thing I want to add to void at one point