Age | Commit message (Collapse) | Author | Lines |
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Otherwise, several --info switches will not properly override each other
|
|
This fixes "feh -D -1 -D 1" and similar starting the slideshow in paused mode
even though the last -D option specifies autostart.
|
|
Closes #456
Note that --randomize and directory names are not saved in fehbg. It only
contains the command line needed to recreate the wallpaper setup which
resulted from its invocation, i.e., after randomization etc. have been
applied. This is intentional.
|
|
closes #458
|
|
Use "extern volatile" instead of "volatile extern" to avoid "gcc" warning "'extern' is not at beginning of declaration [-Wold-style-declaration]".
|
|
There is no need to test ft against null
|
|
|
|
ft is already checked on line 153 so this condition is useless. Check https://github.com/derf/feh/issues/440 for more details
|
|
It is a naive way of fixing it :) Needs attentive review
|
|
sig_exit may be changed by a signal handler, so its value should always be
read from RAM.
|
|
See also #435
|
|
|
|
This changes the behaviour of "feh --start-at FILENAME" as follows:
Previously, this would cause feh to load all files in the current
working directory, since no files or filelists were specified on the command
line.
Now this is a special case: feh will extract the directory component from
FILENAME, load all files in that directory, and display FILENAME.
This way, it's possible to use "feh --start-at ~%f" in XDG Desktop files
and browse files in feh using the prev/next keys
Closes #372
Closes #420
|
|
This more closely resembles the expected behaviour of --start-at, but
may lead to mismatches if several files in the filelist have the same
basename.
Closes #206
Related to #372 and #420
|
|
|
|
https://github.com/Ferada/feh into Ferada-output-directory-for-image-saving
|
|
|