Age | Commit message (Collapse) | Author | Lines |
|
This fixes two memory bugs that only manifest with exif=1 and long-running
slideshows.
* when feh loads an image, it writes exif data to file->ed. Previously, this
data was never free'd, causing a memory leak on subsequent loads of the same
file.
* As file->ed is never free'd, the accumulated EXIF data consumes a significant
amount of memory over time. with slideshow-delay = 10 and two days of
runtime, feh may exceed 1 GB of memory usage. If the slideshow is so large
that feh does not encounter the same image twice in this time, this is not
detected as a memory leak, as each EXIF data chunk is referenced from the
filelist.
See <https://github.com/derf/feh/issues/553> for details.
Closes #553
|
|
If --edit is set, it is indeed "Edit in Place". Otherwise, it changes the
view, but not the image on the disk.
|
|
|
|
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
|
|
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
into iglosiggio-start-at-supports-urls
|
|
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 #485
|
|
Ferada-x11-properties
|
|
This can happen with images that have ridiculous dimensions.
|
|
|
|
This ensures that X11 layout or other changes do not affect the .fehbg
contents, which are meant to only be updated when a --bg-option is used
manually.
Closes #482
|
|
When setting wallpapers without --no-fehbg option, a ~/.fehbg file is
created. This file is set to be an executable for later re-use.
Calling stat() without checking the return value can lead to issues.
If the call fails, then s.st_mode is undefined and excessive permissions
could be set to .fehbg, at worst even setuid/setgid bits for a world
writable file.
While adjusting this, I changed the code to use fstat() and fchmod() to
avoid a further -- but very unlikely -- issue: race condition in form of
TOCTOU. If the file ~/.fehsetbg is replaced by a symlink right before
the chmod call, then a different file would be set executable + the
default mode of the (newly created) file. I don't expect this to be a
real world issue but changed this part "while at it" anyway for more
robust code and a good example on how to handle files.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
|
|
CrackedP0t-geometry
|
|
That part slipped through while reviewing the PR...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #463
|
|
|
|
|
|
|
|
|
|
|
|
|