Wallpaper Engine on NixOS (wallpaper-engine-kde-plugin)

Oh. My nix file looks not perfect yet.
I have noticed some points after commenting

  • It installs only lib, so you need to install plugin manually.(Originally, the plugin should also be installed)
  • Some wallpaper that worked on ArchLinux does not work on my Nix environment.

Despite the problems, I am somewhat satisfied with current situation. If you find a solution, I world be glad to know.

As mentioned above, it is possible to install the wallpaper plugin if you turn DUSE_PLASMAPKG OFF, but then the following error appear:

Python helper run failed:
python3: can’t open file ‘/home/spp/no_pyext_file_found’: [Errno 2] No such file or directory

What I also found out is that in the “About-Tab” of the wallpaper engine settings, their are no pythone3-websocket dependencies found.
Since you installed it manually, is the check mark displayed?

As mentioned above, it is possible to install the wallpaper plugin if you turn DUSE_PLASMAPKG OFF, but then the following error appear

I could not reproduce it. I turn DUSE_PLASMAPKG OFF but build works fine and plugin not installed.

What I also found out is that in the “About-Tab” of the wallpaper engine settings, their are no pythone3-websocket dependencies found.
Since you installed it manually, is the check mark displayed?

Yes.


I have added it here.

Make sure there are no conflicts with python3 installed elsewhere, like this

I copied your config for wallpaper engine one by one and if I set

"-DUSE_PLASMAPKG=OFF"

wallpaper engine gets installed and I do not need to install it manually. But I always get the missing dependencies error mentioned above.

I was able to reproduce your situation after uninstalling plugin that installed manually, and I noticed that the folder com.github.casout.wallpaperEngineKde in ~/.local/share/plasma/wallpapers/ has been deleted.
I checked and nix had installed it on /run/current-system/sw/share/plasma/wallpapers and KDE cannot seem to recognize.

Finally I solved this problem by adding a small script. I would like to know if there is a better way to add the folder in user .local directory.

Thank you so much! It’s working now without any problems.
And I think your solution with the startup script is fine.

1 Like

Hey, that’s awesome! You should make a PR to include it in Nixpkgs!

To do that, I need to fix this problem and do everything in mkDerivation, but have not found a good way😇

anyone knows how to use it on plasma6?

Does this work on plasma 6 under wayland?

I have been able to make this work on Plasma 6! It took a quite a few trials but I got it working thanks to the comments by @turtton and @xerhaxs !

A few notes:

  • To enable it, import it into your preffered nix config file and enable it as so:
imports = [
    ./wallpaper-engine-kde-plugin.nix  # Or another path to the file
];
....
nixos.pkgs = {
    wallpaper-engine-kde-plugin.enable = true;
  };
  • It is definitely not the latest git version of the code but I am thinking of using nvfetcher to automate it.
  • Doing the symbolic link does not seem to work for me as it is doing a symlink of another symlink and plasma does not seem to like it. After installing, you have to go to $HOME/.local/share/plasma/wallpapers/, follow the symlink, copy the targeted symlink and copy it back into $HOME/.local/share/plasma/wallpapers/.
  • I added qtwebchannel as a runtime dependency for support for web scenes, but interaction with the web frame does not seem to work (I think it is not yet implemented in the actual plugin so it should not be a problem with the packaging).
  • This script was derived from @xerhaxs own package where the user is configured with config.nixos.system.user.defaultuser.name. I could not find a generic way to do it if your configuration is not using that specific name, so I relied on the logname utility to find the user. Now, this means this package needs to be activated while the target user is logged in (or it might assume the root, but it still works if you run the nixos-rebuild as root). For most people I do not think this is too much too ask, but it might be a flaw for people who would want a perfect one config installation.
  • I am open to improvements so it is possible for future users to install it directly from the nix store.

Very cool. I’m happy, that we could help to figure it out.
The option config.nixos.system.user.defaultuser.name is just a custom module created by myself. It should be possible to do this in a more generic way with builtins.head (builtins.attrNames config.users.users);

And now I will clean up and write a better README for my repo, if it is so famous. xD

I also found a little bug. It should be
wallpaperenginetarget=/share/plasma/wallpapers/com.github.casout.wallpaperEngineKde
and not
wallpaperenginetarget=share/plasma/wallpapers/com.github.casout.wallpaperEngineKde
The leading / makes a difference in the creation of a symlink.
It is also necessary to create the folders /plasma/wallpapers if it does not exist.
Maybe you could add this to the activation Script.

I modified the activation script:

      wallpaper-engine-kde-plugin.text = ''
        wallpaperenginetarget=/share/plasma/wallpapers/com.github.catsout.wallpaperEngineKde
        mkdir -p /home/${config.nixos.system.user.defaultuser.name}/.local/share/plasma/wallpapers
        chown -R ${config.nixos.system.user.defaultuser.name}:users /home/${config.nixos.system.user.defaultuser.name}/.local/share/plasma
        ln -sf ${wallpaper-engine-kde-plugin}/$wallpaperenginetarget /home/${config.nixos.system.user.defaultuser.name}/.local/$wallpaperenginetarget
      '';
1 Like

Sweet! I’ll test it out (with the generic user attribution too) and come back if it still works. I do wonder, if we are doing an activation script, is there a “deactivationScripts”? I’ll go check it out in the nixos doc. I’m still quite new to Nixos :smile: .

No problem. And I think there is no official “deactivation Script”. Maybe you could script it with a wait function in the bash code of the activation script.

What do you need a “deactivation” script for? What are you trying to achieve?

Simply to remove the symlink we created. I would not want to create a package that keeps unecessary files around when a user wants to deactivate it.

Create a boolean option, if it’s true, create the symlink, else remove the symlink.