Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dunst does not display JPEG icons without a filename extension #540

Closed
eadmund opened this issue Sep 4, 2018 · 20 comments
Closed

dunst does not display JPEG icons without a filename extension #540

eadmund opened this issue Sep 4, 2018 · 20 comments

Comments

@eadmund
Copy link

eadmund commented Sep 4, 2018

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
Copy link
Member

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
Copy link
Member

bebehei commented Sep 4, 2018

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?


[0]: Dunst reloads the notification icon whenever it's drawing a notification complete freshly. So if you mv the file and trigger a reload, the icon disappears.

@eadmund
Copy link
Author

eadmund commented Sep 5, 2018

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
Copy link
Member

bebehei commented Sep 5, 2018

@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
Copy link
Author

eadmund commented Sep 6, 2018

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
Copy link
Member

bebehei commented Sep 6, 2018

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
Copy link
Author

eadmund commented Sep 10, 2018

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
Copy link
Member

bebehei commented Sep 10, 2018

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

@eadmund
Copy link
Author

eadmund commented Sep 11, 2018

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
Copy link
Author

eadmund commented Sep 11, 2018

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
Copy link
Author

eadmund commented Sep 11, 2018

@bebehei
Copy link
Member

bebehei commented Sep 11, 2018

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
Copy link
Member

bebehei commented Sep 11, 2018

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
Copy link
Member

knopwob commented Sep 17, 2018

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
Copy link
Member

knopwob commented Sep 17, 2018

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 bebehei added this to the v1.4.0 milestone Sep 17, 2018
@bebehei
Copy link
Member

bebehei commented Sep 17, 2018

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

@knopwob
Copy link
Member

knopwob commented Sep 17, 2018

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
Copy link
Author

eadmund commented Sep 18, 2018

Awesome job finding this guys, thanks much.

@bebehei
Copy link
Member

bebehei commented Sep 18, 2018

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

@eadmund
Copy link
Author

eadmund commented Sep 20, 2018

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

tsipinakis pushed a commit to knopwob/dunst that referenced this issue Feb 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants