Consider removing the option to autostart WD?

[Guilherme]

Hi, it’s me again.

I’m preparing a pull request to remove the autostart feature of WD for the Flatpak build, because it doesn’t work there.

This is the option I’m referring to:

‌

However, I wanted to ask about your thoughts on removing that option altogether (for Linux users). My rationale is that this feature should be handled by the desktop environment, and not by the application itself.

The two major desktop environments (GNOME and KDE) both provide an interface for autostarting programs.

Additionally, I feel like trying to implement this feature properly across all builds (“regular”, snap or flatpak), adds an unnecessary maintenance burden, because in some cases, the .desktop file WD creates on ~/.config/autostart doesn’t match the one installed with the WD package itself.

For example, this is what the .desktop file from the official WD package in the AUR looks like:

/usr/share/applications/desktop/wallpaperdownloader.desktop:

[Desktop Entry]
Name=WallpaperDownloader
GenericName=Wallpaper Downloader
Comment=Download, manage and change your wallpapers automatically from the Internet
Keywords=wallpaper;gallery;internet;download;downloader;changer;picture;desktop
Exec=/usr/bin/wallpaperdownloader.sh
Icon=/opt/wallpaperdownloader/gui/wallpaperdownloader.svg
Terminal=false
Type=Application
Categories=Utility;

Meanwhile, this is the autostart .desktop file installed by WD:

~/.config/autostart/wallpaperdownloader.desktop:

[Desktop Entry]
Categories=Utility;
Comment[es]=Gestiona y descarga automáticamente fondos de pantalla desde Internet
Comment=Download and manage wallpapers automatically from the Internet
Exec=/usr/bin/wallpaperdownloader.sh
GenericName[en_US]=Wallpaper Downloader
GenericName=Wallpaper Downloader
Icon=/home/user/.wallpaperdownloader/wallpaperdownloader.svg
Keywords=wallpaper;gallery;internet;download;changer;picture;desktop;image
MimeType=
Name[en_US]=WallpaperDownloader
Name=WallpaperDownloader
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
Version=3.2
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Besides not matching the original .desktop file, it adds some new properties with empty values that I’m not even sure what their purpose is.

Also, in both .desktop files, the Icon property is hardcoded, which means that users with a custom icon theme installed, won’t be able to have a personalized icon for WD. Fortunately, that’s easily fixable though.

So, I propose the removal of this feature (again, for Linux users) and, if possible, maintain only a single .desktop file across all builds (the desktop-file-edit command can help us with that very easily).

Side note: I’m also preparing a new pull request that fixes some issues with the Arch Linux packaging.

Cheers!

[Guilherme]

So it turns out that disabling the autostart feature was very trivial:

diff --git a/src/main/java/es/estoes/wallpaperDownloader/window/WallpaperDownloader.java b/src/main/java/es/estoes/wallpaperDownloader/window/WallpaperDownloader.java
index cb8aee1..230b316 100644
--- a/src/main/java/es/estoes/wallpaperDownloader/window/WallpaperDownloader.java
+++ b/src/main/java/es/estoes/wallpaperDownloader/window/WallpaperDownloader.java
@@ -3408,10 +3408,11 @@ public class WallpaperDownloader {
            WDUtilities.getOperatingSystem().equals(WDUtilities.OS_WINDOWS_7) || 
            WDUtilities.getOperatingSystem().equals(WDUtilities.OS_WINDOWS_10) || 
            WDUtilities.isSnapPackage() || 
+           WDUtilities.isFlatpakPackage() || 
            WDUtilities.getOperatingSystem().equals(WDUtilities.OS_MACOSX)) {
            // In these OS, users won't be able to start the application when the system is booted checking
            // the GUI option
-           // This option is not supported within snap package either
+           // This option is not supported within snap and flatpak packages either
            initOnBootCheckBox.setEnabled(false);
        } else {
            String autostartFilePath = WDUtilities.getAutostartFilePath();

Nevertheless, I’m still in favor of removing this feature, especially considering it doesn’t work on Windows/Mac/Snap either…

‌

[Eloy García Almadén]

Your PR has been finally merged

I’ll think about it because maybe you are right and we can remove this option in order to do the code more unified across desktop environments and packaging systems. Oh my God, it is very difficult to maintain a crossed platform and crossed DE application

‌

As always, thank you very much for your help and you’ll have to tell me more about desktop-file-edit command because I don’t know what it is.

[Guilherme]

Awesome, thanks!

you’ll have to tell me more about desktop-file-edit command because I don’t know what it is.

Ah, that’s an easy one.

Like I said, my ideia is that you have a single, generic .desktop file hosted on the repository (instead of 5, like there is currently).

But of course, this generic .desktop file won’t “just work” for Snap, Flatpak or native packages, so that’s when you’d use the desktop-file-edit utility (manual here), which allows us to edit/add specific sections of a .desktop file.

For example, the generic .desktop file won’t have the Exec= field because it won’t work across all different builds.

So, when building the Snap package, for example, we’d copy the generic .desktop file and add the Exec= field like this:

cp /path/to/generic/desktop/file/wallpaperdownloader.desktop /path/to/snap/wallpaperdownloader.desktop
desktop-file-edit --set-key=Exec --set-value='/path/to/snap/wallpaperdownloader' '/path/to/snap/wallpaperdownloader.desktop'

Another example, we’d do this to set the correct Icon= path for the Snap build:

desktop-file-edit --set-icon=wallpaperdownloader '/path/to/snap/wallpaperdownloader.desktop'

‌

[Eloy García Almadén]

It sounds great. We can make some tests and explore the idea when version 4.2 is released

[Eloy García Almadén]

Version 4.2 released with this issue implemented