Age | Commit message (Collapse) | Author | Lines |
|
Closes #754
Closes #740
Squashed commit of the following:
commit 7770f4cf1a1e7ff86238d67053b22b066e3d38ec
Author: wwsmiff <arnav0872@gmail.com>
Date: Sun Mar 17 01:54:55 2024 +0530
Remove font file
commit 70bc5864817e308d44fea51a409ef68c2bb9e574
Author: wwsmiff <arnav0872@gmail.com>
Date: Sun Mar 17 01:54:23 2024 +0530
Fix rotate by 180 degrees bug
|
|
|
|
|
|
The default user agent is empty, which is not that friendly.
Closes #660
|
|
Add a global `magic_t magic` and initialize it just once.
Also `feh_is_image()` now calls itself to check compressed files, saving
some duplicate code.
|
|
Writing our own magic bytes detection is prone to errors and an
everlasting catch-up-game. Let's use libmagic to get things right,
this is less code and makes things more reliable.
Building without libmagic is still possible. That will make the code
act like specifying FEH_SKIP_MAGIC=1, effectively passing everything
to imlib2.
|
|
|
|
Imlib2 v1.7.5 introduces automatic (and transparent) orientation adjustment
based on EXIF orientation tags. This makes feh's --auto-rotate function
both superfluous and erroneous: It doesn't know about Imlib2's adjustments,
so it rotates an image which is already correctly oriented, leading to
incorrect orientation.
I am not aware of a simple run-time check for detecting whethen running
Imlib2 < 1.7.5 or ≥ 1.7.5. For now, feh disables --auto-rotate entirely when
compiled on a system with Imlib2 1.7.5+ and outputs a warning when the
option is used.
Rationale: The Imlib2 version available at run-time should in most cases be
at least as recent as the Imlib2 version used at compile-time. So, while there
may be cases where feh was compiled with Imlib2 1.7.4 and exhibits erroneous
auto-rotate behaviour on an Imlib2 1.7.5 system, the inverse case
(a feh with disabled auto-rotate support running on Imlib2 1.7.4) should be
sufficiently rare. If it does occur, it can be remedied by compiling feh
from source locally.
Possible caveat: Imlib2 only adjusts for EXIF orientation when loading JPEG
and TIFF images. If there are additional EXIF-aware file formats supported by
feh, but not Imlib2, they lose auto-rotate support.
Reference: GitHub issue #642
|
|
This allows feh to load .gif images via libcurl, as some imlib2 versions only
load gif images if the suffix is correct. It's also more convenient when using
--keep-http.
To achieve this, feh needs to use mkstemps. mkstemps is a non-standard
extension that is available on several systems. Compile feh with
"mkstemps=0" to use mkstemp instead.
Closes #630
|
|
The snprintf string argument should not be duplicated.
It is not needed and also not released afterwards.
|
|
|
|
* Fix out of boundary access
The while-loop is not finished when pos is set to EXIF_MAX_DATA.
Instead, the loop continues and therefore tries to access data outside
of the array.
This is triggered when compiled with exif=1 and asan:
$ feh --draw-exif image.jpg
* Fixed formatting
No functional change but makes previous commit easier verifiable
(independent of tab space setup).
* Call break; instead of setting pos2 to a magic value
This is in line with the following else clause
* Another cosmetic adjustment
Co-authored-by: Daniel Friesel <derf@finalrewind.org>
|
|
|
|
Note that Imlib2 does not support JXL images out of the box. However, the
imlib2-jxl loader (https://github.com/alistair7/imlib2-jxl) does.
|
|
Fix some warnings from `gcc`.
|
|
|
|
Fixes https://github.com/derf/feh/issues/580
|
|
Note that Imlib2 does not support HEIC/HEIF images out of the box. However, the
imlib2-heic loader (https://github.com/vi/imlib2-heic) does.
Closes #579
|
|
|
|
|
|
|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
sig_exit may be changed by a signal handler, so its value should always be
read from RAM.
|
|
See also #435
|
|
|
|
|
|
|
|
ulteq-no-inplace-edit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes non-random behaviour when randomizing file lists several times per
second.
Closes #349
|
|
Uses the camera-generated thumbnail to display RAW images that could otherwise not be loaded.
|
|
This introduces a new feh_should_ignore_image function which is called
at appropriate places in those modes to skip images which are loadable but
undesired.
|