dunst does not display JPEG icons without a filename extension

[eadmund]

dunst correctly displays icons from files whose names end in '.jpeg' or '.jpg,' but it does _not_ display them when they do not.

To reproduce:

$ notify-send --icon /path/to/jpeg-image Test "no image displays!"

Installation info

• Version: v1.3.2-143-g896c008
• Install type: manually
• Distro and version: Debian 9 (stretch)

[tsipinakis]

I cannot reproduce this on debian buster. I have a feeling this is something to do with gdk-pixbuf which we use to load icons.

Perhaps in the version that's in stretch it only looks at the extension? I will set up a stretch VM later this week to test.

[bebehei]

I can't reproduce it either. And I've tested it on Xenial, trusty and bionic now.

• What's your gdb pixbuf version?
• What does gdk-pixbuf-query-loaders spit out on your system? (Watch out, this program spits out much stuff. I'm only interested in the lines for the jpeg loader!)

@eadmund And to rule out a possible misbehavior[0] of dunst: How have you tested it? Have you executed any mv call while the notification had been shown?

---

[eadmund]

Looks like gdk-pixbuf is at 2.36.5-2+deb9u2

I get this from gdk-pixbuf-query-loaders:

…
"/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so"
"jpeg" 5 "gdk-pixbuf" "JPEG" "LGPL"
"image/jpeg" ""
"jpeg" "jpe" "jpg" ""
"\377\330" "" 100
…

I ran dunst, then used both notify-send and D-Bus directly to send notifications, using different JPEG files, with & without .jpeg/.jpg. I did not move any files in between sending the notification and seeing it drawn. I _did_ confirm that a file missing the final .jpeg works _with_ it (so it's _probably_ not a malformed file issue).

[bebehei]

@eadmund Thanks for the answer. Sadly nothing, which enlightens me.

I've written a small helper here: https://gist.github.com/bebehei/d1248deab8199ea93d877fdf126be588

Could you please clone the gist, build it and then run ./gdkpb <whateverfile> with files both recognized by dunst and not recognized? Thanks in advance.

PS: You may need to install libgdk-pixbuf2.0-dev for compilation.

[eadmund]

myhost ➜  d1248deab8199ea93d877fdf126be588-2638dba281a5e87346028f02a5fea73f07471ab9 ./gdkpb ~/image
Testing '/home/me/image'
Name: jpeg
Desc: JPEG
Disa: 0
Supported extensions: jpeg jpe jpg
Successfully loaded '/home/me/image'

myhost ➜  d1248deab8199ea93d877fdf126be588-2638dba281a5e87346028f02a5fea73f07471ab9 ./gdkpb ~/image.jpeg
Testing '/home/me/image.jpeg'
Name: jpeg
Desc: JPEG
Disa: 0
Supported extensions: jpeg jpe jpg
Successfully loaded '/home/me/image.jpeg'

It's weird, isn't it?

[bebehei]

Well, that's interesting. Some things have gone south somewhere.

So, the only thing, which still could help and give some clues: a logfile.

Could you please run dunst -print -verbosity info. Fire the notification and send the log?

[eadmund]

Here you go. notify-send --icon ~/image foobar door yields:

./dunst -print -verbosity info
MESSAGE: 'allow_markup' is deprecated, please use 'markup' instead.
MESSAGE: The option 'icon_folders' is deprecated, please use 'icon_path' instead.
MESSAGE: The frame section is deprecated, width has been renamed to frame_width and moved to the global section.
MESSAGE: The frame section is deprecated, color has been renamed to frame_color and moved to the global section.
{
        appname: 'notify-send'
        summary: 'foobar'
        body: 'door'
        icon: '/home/me/image'
        raw_icon set: false
        category:
        timeout: 10000
        urgency: NORMAL
        transient: 0
        formatted: '<b>foobar</b>
door'
        fg: #ffffff
        bg: #285577
        frame: #aaaaaa
        fullscreen: show
        progress: -1
        id: 2
        script: (null)
}

My only other guess is that the image in question is quite large (512×512). Maybe dunst (or the library it's using) doesn't know how to scale it?

[bebehei]

Would you bother to upload the image here!? That would be the necessary reproducer to fix it. Thanks for your reply.

[eadmund]

Unfortunately, it's a portrait of a friend, so I don't feel comfortable sharing it. I'll see if I can get a working test case on a similar picture.

[eadmund]

So, I have a working version, made by scaling http://repo.or.cz/cl-notify.git/blob/HEAD:/lisplogo_warning_128.png up with convert lisplogo_warning_128.png -resize 512x512 /tmp/qqq.jpg, but for some reason GitHub refuses to let me upload it. When I run notify-send --icon /tmp/qqq.jpg baz quux or notify-send --icon /tmp/qqq baz quux, I get a large dunst pop-up with no icon (since it happens both with & without the file extension, now I think maybe it's the image size).

I've tried uploading the JPEG, and a zip containing the JPEG, but to no avail.

[eadmund]

Try this: https://github.com/eadmund/dunst/blob/test-image/qqq.jpeg

[bebehei]

Sorry. I can't reproduce it on ArchLinux. I'm currently building a debian stretch VM.

The only thing left: Could you please paste your configuration, too!? Thanks in advance.

[bebehei]

I can't reproduce it either on an up to date Debian Stretch machine with the default config and dunst built from master and your given image.

[knopwob]

I think I can reproduce the issue.

dunstrc

notify-send --icon $(readlink -f qqq) test blub

The icon is displayed when icon_position is set to left but not when set to right

it also works when max_icon_size is something different than 0.

So my guess is, the icon position is wrongly calculated and the icon is moved outside of the window.

[knopwob]

in draw.c:

static void render_content(cairo_t *c, colored_layout *cl, int width)
{
    [...]
        if (cl->icon) {
                unsigned int image_width = cairo_image_surface_get_width(cl->icon),
                             image_height = cairo_image_surface_get_height(cl->icon),
                             image_x,
                             image_y = settings.padding + h/2 - image_height/2;

                if (settings.icon_position == icons_left) {
                        image_x = settings.h_padding;
                } else if (settings.icon_position == icons_right){
                        image_x = width - settings.h_padding - image_width;
                        LOG_I("width: %d", width);
                        LOG_I("h_padding: %d", settings.h_padding);
                        LOG_I("image_width: %d", image_width);
                        LOG_I("image_x: %d", image_x);
                } else {
                        LOG_E("Tried to draw icon but icon position is not valid. %s:%d", __FILE__, __LINE__);
                }

results in

INFO: width: 294
INFO: h_padding: 8
INFO: image_width: 332
INFO: image_x: -46

So the problem is, when dunst is configured to a fixed width and the image position is set to right aaaand
the image is bigger than the window, then the image position will be negative.

[bebehei]

@knopwob Wow. Thanks. Obviously a bug worth fixing!

[knopwob]

actually the layout is broken with icon_position = left as well. The icon takes up the whole window.

I think the best solution would be to scale the image down to a reasonable size when we have a fixed width or height.

[eadmund]

Awesome job finding this guys, thanks much.

[bebehei]

@eadmund Does the PR #548 fix the behavior you reported?

[eadmund]

It does. Thanks so much for the quick response, guys. Sounds like it was more than a little tricky to find.