Age | Commit message (Collapse) | Author | Lines |
|
This works around a regression in Imlib2, which makes (un)loadable file
detection quite slow when handling e.g. large video files. See
<https://phab.enlightenment.org/T8739> and
<https://github.com/derf/feh/issues/505> for details.
Closes #505
|
|
|
|
feh.1:588:33: WARNING: new sentence, new line
|
|
|
|
Closes #545
|
|
|
|
|
|
|
|
|
|
|
|
Issue:
* start feh --multiwindow --reload 5
* close a window with "x"
* wait up to 5 seconds
* segfault
The issue was caused by the closed window's reload timer still being active
even after the winwidget was free'd.
|
|
Introduced in 3fa39154f089a6fadc1a14eb6b206e2d2875be71
|
|
This lets `feh` draw the background pixmap of an existing window,
opening the door for use with tools like `xscreensaver` or `xsecurelock`
|
|
add option 'a' to show play/paused information in slideshow mode
|
|
When the slideshow state is toggled, the info line needs to be redrawn as it
may use the %a format specifier (which shows whether the slideshow is running
or paused). feh_reload_image does this, but also resets all pan and zoom
options and reloads the image from disk. winwidget_render_image only redraws
info, caption and similar lines in this case, which is more efficient and does
not incur unwanted side-effects.
|
|
Enable --version-sort on systems without strverscmp()
|
|
|
|
|
|
|
|
|
|
The --version-sort option requires strverscmp(), but this is a glibc
extension that does not exist on OpenBSD and other systems. To enable
--version-sort on those systems, provide an internal implementation of
strverscmp(). The implementation is from the musl C library and is
MIT-licensed.
The build process remains the same: the verscmp flag should be set to 1
only if strverscmp() is available in libc. If verscmp is 0, then the
internal implementation is used.
|
|
|
|
|
|
Closes #532
|
|
|
|
|
|
|
|
Closes #521
|
|
|
|
|
|
|
|
feh_file_info_load is called even if file_info is already populated, so
the original file_info struct is never freed. This results in a leak of
~44 Byte for each subsequenc image load
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's called conversion-cache for now, as it will also be used for
ImageMagick/dcraw-sourced images in the future. This should also help
avoid confusion between HTTP/ImageMagick/dcraw cache (files on disk),
Imlib2 cache (images in memory), and thumbnail cache.
|
|
|
|
|
|
|
|
|
|
into iglosiggio-start-at-supports-urls
|
|
|
|
GreenLunar-patch-3
|
|
|
|
|
|
Building feh 3.3 on CentOS 7 x86_64 warns `curl_quit_function` in `imlib.c` is unused:
```
cc -g -O2 -Wall -Wextra -pedantic -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -DHAVE_LIBCURL -DHAVE_VERSCMP -DHAVE_LIBXINERAMA -DHAVE_LIBEXIF -DPREFIX=\"/usr/local\" -DPACKAGE=\"feh\" -DVERSION=\"3.3\" -c -o imlib.o imlib.c
imlib.c:545:12: warning: ‘curl_quit_function’ defined but not used [-Wunused-function]
static int curl_quit_function(void *clientp, curl_off_t dltotal, curl_off_t dlnow, curl_off_t ultotal, curl_off_t ulnow)
^
```
The `curl_quit_function` code was added in response to pull [#435](https://github.com/derf/feh/pull/435)
In issue [#485](https://github.com/derf/feh/issues/485) a fellow CentOS 7 user had an error building feh because CentOS 7 is locked into an old version of libcurl. In the fix, a version guard was wrapped around the `curl_easy_setopt` call, but the rest of the code was unchanged.
Since I don't want to maintain a local build of libcurl, I looked at the curl docs and noticed there is an older callback which serves the same purpose: https://curl.haxx.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html
The difference between `PROGRESS` and `XFERINFO` is the callback's argument types, with `PROGRESS` using `double` and `XFERINFO` using `curl_off_t`: https://curl.haxx.se/libcurl/c/CURLOPT_XFERINFOFUNCTION.html
The callback's return value logic and use of `CURLOPT_NOPROGRESS` is the same.
For context, the latest libcurl RPM I'm getting from yum updates is `libcurl-7.29.0-54.el7_7.2.x86_64`. The "stable" versions of other distros may encounter similar issues. The CentOS 7 "End of Life" date is 2024-06-30 so you should hear the end of this by then, at least from us pesky CentOS users.
|
|
Closes #506
|