Improve support for displaying Vorta's logo in Linux notifications

[SergioRAgostinho]

1. Moved logo icon from packaging content to a formal asset of the application, since the notification image benefits all Linux users, regardless of the installation method;
2. Renamed the logo to clarify its content, better fitting its new location.

A follow up on #563. A description of the problem can be found in here and it affected non-flatpack users.

[samuel-w]

This isn't working for me, bottom is this tree, top is master tree. Using XFCE4 Also has no icon in flatpak.

[SergioRAgostinho]

Let's break this in points, to figure out how to move next:

1. Are you in agreement that this icon needs to be promoted to regular asset and not just simply live in the packaging folder? Reason: it's an icon used in Linux notifications in general and thus agnostic to the packaging method.
2. Is the monochromatic logo being used anywhere other than for notifications? My assumption was that the flatpack logo was being served by this file.

[Hofer-Julian]

Let's break this in points, to figure out how to move next:

1. Are you in agreement that this icon needs to be promoted to regular asset and not just simply live in the packaging folder? Reason: it's an icon used in Linux notifications in general and thus agnostic to the packaging method.

2. Is the monochromatic logo being used anywhere other than for notifications?  My assumption was that the flatpack logo was being served by [this file](https://github.com/borgbase/vorta/blob/master/package/icon.svg).

I think the already existing implementation is the way to go. The assets are copied to the destinations according to the freedesktop specifications. This is already done with the flatpak, and debian, arch, ... will do the same. There was an attempt to allow something similar with pip alone, but we decided to drop it.

[SergioRAgostinho]

I think the already existing implementation is the way to go.

You're breaking the "separation of concerns". Having access to a notification logo in Linux should be agnostic of how vorta is installed and this includes pip/setuptools based installs. This is not a pip/setuptools imposed limitation like "having an application icon in an apps menu". This last one really requires os-friendly packaging mechanisms which pip does not support.

Furthermore, you're imposing an avoidable visual difference between the development environment, i.e. when you're working with vorta like this

$ python setup.py develop

, and how it is deployed.

So I'm just not really understanding why you'd rather keep it as is, instead of trying to modify this PR to ensure we have consistent notifications icons across all installation methods in the Linux ecosystem.

[Hofer-Julian]

I do see your point. If you provide something, which

• doesn't add too much complexity
• continues to work with flatpak&traditional packages
• works on macOS and linux we will most probably merge it.

We might also want to ping @sten0, how other python GUIs are currently handling this.

[sten0]

@Hofer-Julian @m3nu, sorry I missed this one (I was travelling to a wedding then). Here is what Vorta 0.7.5 using the Debian package looks like:

and it appears the primary outstanding issue is with the notification popup (third screenshot), which I think is probably supposed to look like https://community.kde.org/Plasma/Notifications

Here are the details to how I'm installing Vorta (dh_python3 is magic abstraction): https://salsa.debian.org/python-team/packages/vorta/-/blob/debian/master/debian/rules

What I find curious is the monochrome icon is used in the tray, and in the notification overview, as expected, despite the fact that I haven't installed package/icon-symbolic.svg to the Debian package; however, as noted, the popup doesn't contain the icon. Given that the Vorta icon used in the tray and notification overview is already monochrome, and that the notification popup examples given at community.kde.org have colour, I'm not sure what the purpose of icon-symbolic.svg is. Is it for a macOS special case?

[sten0]

P.S. Outside of the Makefile, I couldn't find any reference in the source (of 0.7.5) to icon-symbolic.svg, nor com.borgbase.Vorta-symbolic.svg

[m3nu]

Would be good to solve this, if it's simple.

The said icon is in the package folder https://github.com/borgbase/vorta/blob/master/package/icon-symbolic.svg

Though another size might be required.

So the remaining task is to move the icon into vorta/assets and adjust the Linux notification code?

[m3nu]

So what kind of icon do we need to ship to make it work in all notifications and how is it referenced?

[real-yfprojects]

Here are the details to how I'm installing Vorta (dh_python3 is magic abstraction): https://salsa.debian.org/python-team/packages/vorta/-/blob/debian/master/debian/rules

You aren't installing package/icon-symbolic.svg to share/icons/hicolor/symbolic/apps/com.borgbase.Vorta-symbolic.svg as the flatpack does: https://github.com/borgbase/vorta/blob/487176547edeaf591690cb60ea103b30ec60e66c/Makefile#L64

What I find curious is the monochrome icon is used in the tray, and in the notification overview, as expected, despite the fact that I haven't installed package/icon-symbolic.svg to the Debian package; however, as noted, the popup doesn't contain the icon. Given that the Vorta icon used in the tray and notification overview is already monochrome

The tray icon and such are managed by Qt which uses the hdd-o-*.png icons in the src/vorta/assets. The notifications are delivered through dbus and use the system installed symbolic icon.

and that the notification popup examples given at community.kde.org have colour, I'm not sure what the purpose of icon-symbolic.svg is. Is it for a macOS special case?

That's what I am wondering about as well.

[real-yfprojects]

This isn't working for me, bottom is this tree, top is master tree. Using XFCE4 Also has no icon in flatpak.

On XFCE 14.4 it behaves exactly the other way round. Top would be this branch and bottom master. It also works on GNOME and KDE Plasma but on KDE Neon the resolution is way to low.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[sten0]

"stale[bot]" @.***> writes:

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Update for Vorta 0.8.10, as shipped in Debian 12/bookworm: No notifications display whatsoever under KDE Plasma, which is a regression compared to the version that I initially reported this issue against.

Vorta now fails silently when the repo disk is unavailable

2023-07-19 16:15:12,946 - vorta.scheduler - DEBUG - Paused 3 until 2023-07-19 16:16:12 2023-07-19 16:16:11,948 - vorta.scheduler - DEBUG - Nothing scheduled for profile 3 because of timeout until 2023-07-19 16:16:12. 2023-07-19 16:17:10,938 - vorta.scheduler - INFO - Setting timer for profile 3 2023-07-19 16:17:10,939 - vorta.scheduler - DEBUG - Catching up by running job for test0 (3) 2023-07-19 16:17:10,941 - vorta.scheduler - INFO - Starting background backup for test0 2023-07-19 16:17:10,941 - vorta.notifications - DEBUG - notification not suppressed 2023-07-19 16:17:10,943 - vorta.keyring.abc - DEBUG - Only available on macOS 2023-07-19 16:17:10,943 - vorta.keyring.abc - DEBUG - Using VortaKWallet5Keyring 2023-07-19 16:17:10,943 - vorta.borg.borg_job - DEBUG - Using VortaKWallet5Keyring keyring to store passwords. 2023-07-19 16:17:10,945 - vorta.borg.borg_job - DEBUG - Password not found in primary keyring. Falling back to VortaDBKeyring. 2023-07-19 16:17:10,945 - vorta.scheduler - ERROR - Conditions for backup not met. Aborting. 2023-07-19 16:17:10,945 - vorta.scheduler - ERROR - Repo folder not mounted or moved. 2023-07-19 16:17:10,946 - vorta.notifications - DEBUG - notification not suppressed 2023-07-19 16:17:10,948 - vorta.scheduler - DEBUG - Paused 3 until 2023-07-19 16:18:10

I'll test 0.8.12 on Debian 12/bookworm as soon as I find some more free time. Please ping me if I seem to take too long.

[sten0]

Results for 0.8.12 on Debian 12/bookworm:

Backup continues to fail silently; however the failure is logged correctly. Desktop notifications are supposed to be used to notify the user of things like "Hey, you forgot to plug in or mount your backup disk! Backing up is not possible without a writable target".

2023-07-21 19:29:26,270 - vorta.scheduler - ERROR - Conditions for backup not met. Aborting.
2023-07-21 19:29:26,270 - vorta.scheduler - ERROR - Repo folder not mounted or moved.

[real-yfprojects]

@sten0 You don't need to put effort into this PR. There is #1522.