Toqozz / wired-notify

Lightweight notification daemon with highly customizable layout blocks, written in Rust.
MIT License
571 stars 27 forks source link

Feature: SVG Support #53

Closed BeyondMagic closed 2 years ago

BeyondMagic commented 2 years ago

I know SVG isn't easy to play with, but many notification servers have it, so I'm just asking.


Pretty innovative idea though, thank you very much for it.

lukelex commented 2 years ago

+1

I've exported the entire FontAwesome library as png in order to have them work with Wired but not without its quirks.

Another thing to think about is having the container be flexible as not to squish or stretch the image.

Toqozz commented 2 years ago

Where do you want support for it? If in image block, do some apps send notification hint images or app images as SVG?

@lukelex Do you mean you would want to be able to specify that we just present the image as-is without any scaling? So e.g. set scale_width/scale_height to -1 for no scaling on that dimension?

BeyondMagic commented 2 years ago

Where do you want support for it?

Image blocks.

do some apps send notification hint images or app images as SVG?

Hard to tell, if there's a way to verify this, I'd help, but I can guess that no. Telegram, for example, caches the images as JPG, and then sends to the server with the hint images along the new message.

Not sure exactly the reasoning behind the question though, is it about recognizing the image being sent as SVG or (PNG, JPG, ...)? I thought many image-rendering libraries already had this 'built-in'.

Toqozz commented 2 years ago

Not sure exactly the reasoning behind the question though

I'm trying to understand the use-case. If all notify clients send PNGs, why do we need SVG support? Just now I'm remembering that users can manually send images, which is probably the use case.

I thought many image-rendering libraries already had this 'built-in'.

Unfortunately image-rs does not (which is surprising because it's massive!!!). I'd have to pull in another library, all of which seem non-trivial. Will keep looking at options though.

BeyondMagic commented 2 years ago

I'm trying to understand the use-case. If all notify clients send PNGs, why do we need SVG support?

My bad, I should've made it clear before. I mostly use notification servers for Shell scripts, it's easier to automate certain processes, such as: recording with a keybind, and display a notification with a timer until it begins. I have a lot, really a lot, of those, and I think many people who uses Linux for ricing and making things easier for them send those notifications directly from scripts as well. The icons, in those cases, would help differentiating them.


Could I ask though if the --icon option (from notification-senders) shouldn't read it as an image-path as well?

# Instead of only this:
notify-call --hint string:image-path:"$icons/definition.svg" "Love" "Means ..."
# Read as well:
notify-call --icon "$icons/definition.svg" "Love" "Means ..."
Toqozz commented 2 years ago

We should be handling this case. IIRC we handle the --icon param as an "App" image, and the other ones as "Hint" images, which is adjusted in the ImageBlock settings.

https://github.com/Toqozz/wired-notify/blob/52dd38c93fceca54c0ecf47ec5c63476577be873/src/bus/dbus.rs#L364

My guess is that it's just not loading the SVG, but should handle that icon param fine.

Toqozz commented 2 years ago

SVG support has been added in master. Naturally it only works when loading images from a path (e.g. notify-send -i /home/user/img/ferris.svg "summary" "body"), but if the sender sends a path it should work.

Let me know if you run into any issues.

lukelex commented 2 years ago

@lukelex Do you mean you would want to be able to specify that we just present the image as-is without any scaling? So e.g. set scale_width/scale_height to -1 for no scaling on that dimension?

Exactly. It's often the case that opposing images aren't the same size. (e.g. Volume & Mute) volume-svg