nsxiv, branch master

Merge branch 'nsxiv-master'

2023-06-11T16:07:49Z

what the actual fuck?

2023-06-11T16:05:47Z

update documentation (#448)

2023-05-28T06:49:07Z

the fedora copr repo is no longer being updated since the maintainer of it, mamg22, no longer uses nsxiv in his daily setup (and thus stopped contributing to nsxiv as well). he has requested the repo and his email to be removed from the project. so go ahead and honor that request. also take this as an opportunity to remove some long inactive maintainers from the CURRENT MAINTAINERS section of the manpage. Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/448 Reviewed-by: explosion-mental

make assertions opt-in (#447)

2023-05-26T07:06:17Z

slight addendum to 657080a7e55843e351fa6ce41e4ce315eab62b67 instead of disabling asserts by adding -DNDEBUG to config.mk, this disables asserts by default in the source code itself. this way, if someone compiles with `make CFLAGS="-O3 -march=native"` without knowing about asserts/-DNDEBUG then he won't accidentally get a build with assertions in it. this basically makes the assertions opt-in, if someone wants it, he'll need to *explicitly* set `-DDEBUG` to get it. so that it's not possible to accidentally end up with assertions enabled. Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/447 Reviewed-by: TAAPArthur

set a default delay if delay is 0 (#445)

2023-05-23T11:36:41Z

gif spec [0] doesn't mention what to do when "Delay Time" is 0. apng spec [1] states: | If the the value of the numerator is 0 the decoder should render the | next frame as quickly as possible, though viewers may impose a | reasonable lower bound. webp spec [2]: | the interpretation of frame duration of 0 (and often <= 10) is | implementation defined. so it seems that it's safe to set a default delay for 0 delay frames, which is what the older gif and webp loaders were already doing. do the same for the imlib2 multi-frame loader as well. [0]: https://www.w3.org/Graphics/GIF/spec-gif89a.txt [1]: https://wiki.mozilla.org/APNG_Specification [2]: https://developers.google.com/speed/webp/docs/riff_container#animation Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/445 Reviewed-by: eylles

move load/cache messages to right side (#446)

2023-05-23T03:01:44Z

this avoids overwriting the left side bar, which might contain more important information, for e.g output of the thumb-info script. Co-authored-by: A1337Xyz Co-authored-by: NRK Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/446 Reviewed-by: eylles Reviewed-by: NRK Co-authored-by: a1337xyz Co-committed-by: a1337xyz

fix: memory leak in `win_draw_bar` (#444)

2023-05-19T13:17:02Z

Closes: https://codeberg.org/nsxiv/nsxiv/issues/410 Co-authored-by: blk_750 Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/444 Reviewed-by: NRK Co-authored-by: blk_750 Co-committed-by: blk_750

fix: calling imlib2 with color modifier being NULL (#440)

2023-05-18T15:06:44Z

the multiframe loaders sets the color modifier to NULL but doesn't restore it before returning. this results in a imlib2 developer warning if you try to change brightness/contrast on a multiframe image (which doesn't have alpha). ensure that the color modifier is restored before returning under all paths. Reported-by: Madhu Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/440 Reviewed-by: eylles

fix: loading old frames due to multi-frame cache (#437)

2023-05-18T15:05:45Z

by default imlib2 doesn't check the file's timestamp to avoid disk activity when loading from cache. however, this ends up breaking our autoreload functionality on multi-frame images. the reason why single frame images weren't broken was because `img_load()` calls `imlib_image_set_changes_on_disk()`, which tells imlib2 to check the timestamp before loading from cache. do the same thing for the multi-frame loader as well. additionally add a comment to img_load() explaining what's going on. Closes: https://codeberg.org/nsxiv/nsxiv/issues/436 Reviewed-on: https://codeberg.org/nsxiv/nsxiv/pulls/437 Reviewed-by: eylles

[ci]: silence false positive warning

2023-05-13T17:28:27Z

clang-tidy currently flags the following: util.c:57:8: error: 'ptr' may be set to null if 'realloc' fails, which may result in a leak of the original buffer [bugprone-suspicious-realloc-usage,-warnings-as-errors] ptr = realloc(ptr, size); the analysis here is correct, but if realloc fails, we simply exit so there's no real "leak". moreover this check is not very useful for nsxiv's codebase because we do not use naked realloc(), instead we use the erealloc wrapper that exits on failure. so just disable the warning entirely instead of changing the source code to silence the false positive.