Daemon doesn't stay running

[jjramsey]

I am running on Labwc 0.7.2.

If I run waypaper-engine daemon at the command line, I get a message saying starting daemon..., and then the command line prompt comes back, as if the daemon finished running. If I run the command ps ax | grep way there's no indication that anything named waypaper-engine has continued running in the background.

The command waypaper-engine run does bring up the GUI, which appears to work. However, if I add waypaper-engine daemon & to my $HOME/.config/labwc/autostart, it doesn't restore the background that waypaper-engine run had set. And if I run the command ps ax | grep way yet again, there's no indication that anything named waypaper-engine has continued running in the background.

I've installed waypaper-engine via the AUR package waypaper-engine-git, and its version is 2.0.3.r7.7b2855f-1. Here are the messages that I get when running makepkg -sic: waypaper-engine-git-makepkg-msgs.txt

[0bCdian]

I should put in the README that the process for the daemon is actually called wpe-daemon 😅 About the wallpaper not being restored.. it should automatically be set by swww so it's kinda strange that it doesn't work. Try rebooting, see if swww-daemon and wpe-daemon are running and we'll take it from there. I'm sorry about any inconvenience, and I'll try to solve the issue as soon as possible.

[jjramsey]

Good news and bad news:

• The good news is that if I start swww-daemon either before or after running "waypaper-engine daemon", then the image does show up in the background on restart.

• The bad news is that while the image shows up, it doesn't not show up with the configuration set by the Waypaper Engine GUI, but rather it always fills the screen, even if I set it up to just fit within the screen area. (Unfortunately, the images I happen to have from Digital Blasphemy are from my days with a smaller screen, and only go up to 1152 × 864. so this is a bit of a problem.) Looks like some state isn't being properly restored.

[0bCdian]

Which options you have set for swww in the gui? So i can try to replicate this.

[0bCdian]

Also, it's kind of weird that the daemon isn't starting swww automatically, I have it set so that it check's for the process pid and if it's not present it will start swww, so just calling the daemon should start both the wpe-daemon and swww-daemon. I have it set up like that in sway and hyprland and both work, I don't know if it is an obscure bug or something, but I'll keep digging.

[jjramsey]

"Resize type" is set to "Fit", and "Fill Color" is set to R:29, G22, B22, according to the color selector in the GUI. Not sure if those numbers are in decimal or hex.

[0bCdian]

Just so we are on the same page, here's swww's resize options:

--resize Whether to resize the image and the method by which to resize it

      [default: crop]

      Possible values:
      - no:   Do not resize the image
      - crop: Resize the image to fill the whole screen, cropping out parts
        that don't fit
      - fit:  Resize the image to fit inside the screen, preserving the
        original aspect ratio

I've tried setting directly with swww from my terminal images bigger/smaller than my monitor and both crop/fit do the same, rescale the image to fit entirely within the monitor (So if the image is bigger, it simply rescales down and fits entirely, and if it is smaller it scales it up to my monitor res so it looks blurry), so I think this is an issue with swww, I'll try to report it, for now if your images are smaller than your monitor, a resize of no will just leave the image as it is and fill it with the color you set.

Btw, do you still have problems with the daemon process not starting swww? I want you to try and reboot, open up the terminal and call waypaper-engine ri or waypaper-engine info, this are daemon commands, see if it works properly, if not, change the exec line in your wm to waypaper-engine daemon --logs and try again to generate some logs located in $HOME/.waypaper-engine. Btw the ampersand is not needed when running the daemon from the cli, the waypaper-engine program in the terminal is just a pretty bash script, the daemon command specifically just calls for the waypaper-engine electron binary with the --daemon flag, and that just spins up a nodejs process and shuts down so there is no need to put the &.

[jjramsey]

I think this is an issue with swww

I think you may have misunderstood, and perhaps I was unclear. Initially, if I set the SWWW configuration in the Waypaper Engine GUI, the configuration is obeyed. It's just that when I restart, the configuration that was set goes away, and the image always fills the screen (provided that the swww daemon is running).

Btw, do you still have problems with the daemon process not starting swww?

Yes, though it seems a bit more complicated than before. After a reboot, the image showed up, filling the screen, but after logging out and logging back in, the swww daemon didn't restart, and the background was black. Running waypaper-engine ri restored the desired setup.

[0bCdian]

Ok, can you peek at the db to see the values? The db is located in $HOME/.waypaper_engine/images_database.sqlite3.

If you have sqlite3 installed in your system you can open the db with it and it'll start a repl sqlite3 $HOME/.waypaper_engine/images_database.sqlite3, once inside do a select statement SELECT * FROM swwwConfig, to check whether the changes are being written to the db. I haven't encountered this issue or how to replicate it so it's weird that the changes in the swww page are not being stored.

About the logging in/out I'll try to replicate that in sway and hyprland, but going from memory I haven't had that problem before. Just to try, use the -git version of swww to see if it changes anything. I'll get back to you if I find anything.

[0bCdian]

Good news, I was able to replicate swww not running on subsequent logins on sway (In hyprland it always worked) so I'll get to it asap and push a fix.

[jjramsey]

If you have sqlite3 installed in your system you can open the db with it and it'll start a repl sqlite3 $HOME/.waypaper_engine/images_database.sqlite3, once inside do a select statement SELECT * FROM swwwConfig, to check whether the changes are being written to the db.

I just tried this on a fresh login right after the reboot (where the image shows up, but not with the correct swww config), and running SELECT * FROM swwwConfig just gets me what looks like a continuation prompt, i.e., ...>.

[0bCdian]

whoops, I forgot the colon SELECT * FROM swwwConfig; my bad!

[jjramsey]

Thanks. Here's the result:

{"resizeType":"fit","fillColor":"#1d1616","filterType":"Lanczos3","transitionType":"simple","transitionStep":90,"transitionDuration":3,"transitionFPS":60,"transitionAngle":45,"transitionPositionType":"alias","transitionPosition":"center","invertY":false,"transitionBezier":".25,.1,.25,1","transitionWaveX":20,"transitionWaveY":20,"transitionPositionIntX":960,"transitionPositionIntY":540,"transitionPositionFloatX":0.5,"transitionPositionFloatY":0.5}

"resizeType" and "fillColor" appear to be correct.

[0bCdian]

I see, upon further testing I see what's the culprit.

First, about swww not being executed right away with the daemon, it is executing, only that there's a bug in swww that makes it crash on systemd suspend or logouts in certain compositors, I replicated this in sway, and there are some issues open in swww about this. My daemon tries to run swww, it crashes but I don't have any safeguards for this other that when it's time to set a picture, if swww is not running it will run it. I'll fix this to address that issue.

Second, about the wallpaper restored not respecting the settings, I also managed to replicate this, and it seems that swww just defaults to fit when restoring from cache (I'm actually not doing anything to restore the last wallpaper, it's autmagically handled by swww-daemon initialization), I'll just write some logic to replicate this behavior and actually set the images with the correct configurations.

Thank you for your patience, I'll fix this asap and push the changes to -git and also release a new minor version, since it's been a while.

[0bCdian]

I pushed some changes that should address both your issues, pull the latest git changes and try. Let me know if anything else is broken or if there are any bugs.

[jjramsey]

Looks like those bugs have been fixed, at least with the minimal testing I've done so far.

[0bCdian]

Glad to help, if you have any more issues feel free to open one!