It might be different in other file managers, but in Thunar both imv and
imv-dir are currently displayed as "imv" in the "open with" menu. This
makes them indisutinguishable and impossible to choose the one user
wants. This commit ensures that they have different names in the desktop
files.
This commit allows user to select a few files and open only them using
imv-dir. When user opens just one file (typically by double-clicking on
it in a file manager), imv-dir will behave like it used to and open
open the whole directory.
I think this behavior is more reasonable doesn't add much complexity to
imv-dir. Now imv-dir conveniently accomodates the three use-cases which
I think must be quite common:
1. If user wants to cycle through all files in current directory, they
can just double click on one of them.
2. If the user wants to cycle through just a few specific files (say,
if they have many files in this directory and don't want to see them
all), they select them and hit Enter.
3. If the user wants to see just one file and doesn't care about cycling
through them, they just click on one file. The cycling is available,
but they don't have to use it.
For me, 1 and 2 were the main use-cases and to accomodate them I had to
switch between imv and imv-dir as default image viewers, which is rather
suboptimal. Now both are cheaply accomodated by imv-dir.
Do not commit the surface with the new scale and the old buffer.
Leave it to the next rendering pass to commit the surface.
Fixes the following protocol error:
wl_surface@10: error 2: Buffer size (717x795) is not divisible by scale (2)
Closes: https://todo.sr.ht/~exec64/imv/20
imv is currently binding to the latest version of all the interfaces,
but should instead bind the latest version that it supports. imv is not
compatible with wl_output v4 and so was crashing when the latest wlroots
offered it.
This patch pins a maximum version for each wayland interface that is
bound.
https://todo.sr.ht/~exec64/imv/1
Before this commit, the background rectangle was drawn to cover only one line
of text (which was ok since multiline overlay text was not supported). Now
the code correctly calculates the dimensions on the rendered text and put the
rectangle of the right size under it.
This effectively splits the imv_canvas_printf function into two separate
functions, one to create a layout containing given text and the other one
to show it on the canvas. These functions can be useful for the future code
I will add to display text with a background rectangle behind it. Existing
imv_canvas_printf function does not allow this
This prevents wordexp function from splitting the output of shell expansion
into “words” and, as a consequence, removing the newlines from it. With this
commit applied, setting
overlay_text = $(echo -e 'hello\nworld!')
displays
hello
world!
in Imv window. Without this commit, the same overlay_text setting would display
hello world!
since wordexp splits the string "hello\nworld!" into two words and connects
them with a space.
This should not break any of the commands executed in $(), because the IFS
variable is *not* inherited by their shell. The commands don't see this change
and run with the default IFS value.
OpenGL is used for rendering because `cairo_rectangle` and
`cairo_pattern_t` had performance problems on zoomed and rotated images.
The size and contrast of the chequered pattern is also reduces to match
other image viewers and editors.
Closes#253
This changes make it more portable by removing bash dependency and not
using GNU-specific 'sort' syntax. Also this fixes issue with selected
image not being displayed first.
The current implementation of freeimage backend automatically rotates the
images based on EXIF info. Libjpeg backed doesn't do that (although libjpeg
itself may be able to, I didn't check). This commit makes Imv use freeimage for
jpeg files when both backends are available to enable automatic image rotation
when possible.
A cleaner solution could be to add automatic rotaiton functionality to libjpeg
backend as well, but this quick hack is better than nothing ☺
This seems to have a better behavior, this way, the fonts in Imv seem to have
the same size as the fonts in other programs (Sway, Waybar) when configured in
the same way.
Before this commit, the code in src/wl_window.c seemed to handle the Wayland
scaling [1] correctly, it was sending resize events to imv to update the buffer
size accordingly. One thing it didn't update is the scaling of fonts that Pango
renders on Cairo.
This commit simply forwards the scaling factor (computed as [1] requests)
together with updated buffer dimentions in resize event, and when the resize
event is handled it calls cairo_surface_set_device_scale to notify Pango/Cairo
of the scaling.
For X11, I simply assume the scaline factor is always 1. This seems to be what
the old code did: `grep scale src/x11_window.c` gives no matches. AFAIK, X11
does not have an established way of telling clients what scaling factor to use
(and never updates it at runtime).
[1]: https://wayland-book.com/surfaces-in-depth/hidpi.html
This includes the commands available in contrib/. It's enabled by
default.
I moved the manpage and desktop file to their regular locations to avoid
complicating the meson file too much. They won't be installed when you
disable the contrib commands.
`imv` now supports HEIC, but other applications (e.g.: file managers) cannot determine this, since it's not listed as a supported mime type.
Adding this entry allows such applications to determine that `imv` can handle HEIC files.