Comment by ~somini on ~scoopta/wofi
Thank you very much.
https://archlinux.org/packages/extra/x86_64/wofi/
Flagged the Arch package, should be picked up soon, hopefully.
Comment by ~somini on ~scoopta/wofi
Hi ~scoopta, I'm also waiting eagerly for the release that fixes #184, so I went through the commits since v1.4, here's a preliminary changelog:
New Features:
- Refactor key mapping modifier logic. See https://hg.sr.ht/~scoopta/wofi/rev/e04f796d67388a750f421a7c97c9124767b6afd5
- Add return codes for custom keys (20 slots) See https://hg.sr.ht/~scoopta/wofi/rev/1b2d92e8e8b32902eb1f525e7d933f9029494d55
- Add
#expander
selector so expanded actions can be themedChanges:
- Reorder default terminal search list
New Options:
- drun: disable_prime: Ignore
PrefersNonDefaultGPU
- drun: print_desktop_file: Print filename, instead of invoking it
- pre_display_exec
Bugfixes:
- drun respects
Hidden
See https://todo.sr.ht/~scoopta/wofi/193- Make sure that the first calculation of percent size is done when the window is visible
- Fixed segfault when running non shell safe inputs with --pre-display-cmd and --allow-images
- Fix sway crash with negative height See https://github.com/swaywm/sway/issues/7915
Comment by ~somini on ~scoopta/wofi
~scoopta Thanks for fixing this.
Comment by ~somini on ~scoopta/wofi
Not really, I usually use the arrow keys in those cases. It's still a problem.
I encountered the same problem. ~somini, did you manage to solve the problem, at least somehow?
Ticket created by ~somini on ~scoopta/wofi
When using
<Tab>
to cycle between entries, tabbing on the last entry scrolls to the text entry (this is also silly), then it moves to the second entry. The first one is skipped.When using
<Shift-Tab>
, it passes from the first entry to the text entry (another silly behaviour), then to the last one.
This is a bug, but also a request to avoid making the text entry selectable. It makes no sense, since writing text always writes on that widget, no matter what's selected.
Comment by ~somini on ~emersion/kimchi
https://pkg.go.dev/github.com/mkch/burrow/compress
This seems to implement this using only the standard library. But only for the on-the-fly case.
Ticket created by ~somini on ~emersion/kimchi
Most browser "Accept-Encoding": "gzip", so the server could do this on the fly. There are also other encodings.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
Another option is to have .gz files besides the "real" file and serve that instead, to save CPU.
This would be an option of "file_server", perhaps with a fallback in the global namespace.