Cc: @lordkekz, @rkuklik

@Alxandr Thanks for reporting! I got two questions:

• Does it correctly apply your wallpaper and theme on login?
  To test this, make sure the home-manager configuration is already activated, and then start a new Plasma session. Since Fix plasma activation #708 there's an AutostartScript that should run the plasma-apply-wallpaperimage and plasma-apply-lookandfeel commands when the Plasma session starts.
• Do you have a wallpaper configured?
  I think the stylix wallpaper option is no longer mandatory (or at least that's planned) but the KDE activation can't handle that yet. If you don't have a stylix wallpaper set, can you try setting one and check if the problem goes away?

In any case, the KDE module needs to be updated at least to make the wallpaper optional. Shouldn't be difficult though.

I have a wallpaper configured, it's not applied (cause I"m not actually running plasma - so that makes total sense). The theme is applied though in multiple applications. Or at least the dark-light-modedness is.

For now, I've solved my issue by doing this: https://github.com/Alxandr/nix-system/blob/9445bf3c0f2803794b9d072b85749106daec1f66/config/users/alxandr/home.nix#L211

Just to be sure, plasma-apply-lookandfeel works outside Plasma session? If so, then we (or at least I) incorrectly assumed otherwise and I would suggest just switching the order of the commands (first Look and Feel, then wallpaper) in activation and calling it a day. What do you think, @trueNAHO? If you agree, should I put it into #772?

Switching order is probably fine, but is there any good reason to not also just throw a || echo "failed" on both of the commands?

[Edit]
With regards to whether or not plasma-apply-lookandfeel works outside a plasma session, I'm a bit troubled for an answer, cause I think I might be down in the weeds of what constitutes a "plasma session". I launch hyprland using UWSM, and it launches some parts of what you typically have in a plasma session. It also calls plasma-apply-lookandfeel and that works just fine. Attempting to set the wallpaper crashes however. Haven't looked into why yet.

Switching order is probably fine, but is there any good reason to not also just throw a || echo "failed" on both of the commands?

[Edit] With regards to whether or not plasma-apply-lookandfeel works outside a plasma session, I'm a bit troubled for an answer, cause I think I might be down in the weeds of what constitutes a "plasma session". I launch hyprland using UWSM, and it launches some parts of what you typically have in a plasma session. It also calls plasma-apply-lookandfeel and that works just fine. Attempting to set the wallpaper crashes however. Haven't looked into why yet.

The wallpaper needs to be optional for #442 and I agree that it's better to not fail activation plasma-apply-lookandfeel either just because it might not be the last activation step.

If you're on UWSM+Hyprland and just run kwallet and maybe kde connect, that counts as outside a Plasma session IMO.

If you're on UWSM+Hyprland and just run kwallet and maybe kde connect, that counts as outside a Plasma session IMO.

I agree - but I don't know (cause I've not looked into) what plasma systemd services are also launched that simply got installed because I have plasma installed.

Switching order is probably fine, but is there any good reason to not also just throw a || echo "failed" on both of the commands?

My reasoning was that if wallpaper setting fails, it exits with a failure, which can then be reacted to accordingly (you can see autostart status in Plasma system settings, for instance). But it also may be reasonable store the exit codes and return them afterward.

[Edit] With regards to whether or not plasma-apply-lookandfeel works outside a plasma session, I'm a bit troubled for an answer, cause I think I might be down in the weeds of what constitutes a "plasma session". I launch hyprland using UWSM, and it launches some parts of what you typically have in a plasma session. It also calls plasma-apply-lookandfeel and that works just fine. Attempting to set the wallpaper crashes however. Haven't looked into why yet.

I looked at the source code, and it makes sense that wallpaper setting fails, it calls plasmashell via DBus, which isn't running. plasma-apply-lookandfeel seems to be part of System Settings and invoking some internal C++ directly, so it will most likely depend only on it being installed.

Just to be sure, plasma-apply-lookandfeel works outside Plasma session? If so, then we (or at least I) incorrectly assumed otherwise and I would suggest just switching the order of the commands (first Look and Feel, then wallpaper) in activation and calling it a day. What do you think, @trueNAHO? If you agree, should I put it into #772?

If it resolves the issue, then this LGTM. Open a new PR since #772 is merged.

Hi @Alxandr, I couldn't ping you from the PR, would you please try out the changes in #823 if they work for you? Thanks in advance.

I will try to remember to test it over the weekend.

I`m probably doing something wrong, but I don't see switching from danth/stylix to rkuklik/stylix having any effect. It's likely to just be me doing it wrong though as I'm pretty new to flakes (and nix in general).

So Look and Feel isn't set? The wallpaper should fail (and report doing so), but that should not affect the rest.

It does not - nor does my workaround actually. Yet calling plasma-apply-lookandfeel --apply stylix does work... I`m htinking there's some kind of timing issue here, which is likely to be my environment, not stylix.

Well, that's wierd. I honestly have no idea what could be done to fix this, given that we already faced these issues (which autostart was the best solution @lordkekz found). My only guess is that maybe autostart scripts aren't ran under Hyprland, but on the other hand I pressume that you rebuild and switch in an already running desktop. @trueNAHO any ideas?

I am slowly switching to Hyprland myself, but am nowhere near for me to jump over and try to debug this, so perhaps it might be a good idea to postpone this issue, unless anybody has a solution.

Meanwhile @Alxandr maybe try to add the command into exec-once or similar, if that doesn't fix your particular issue.

I'm pretty sure Plasma's autostart scripts don't run under Hyprland (at least not unless you script it yourself).

I'll try using the plasma-apply-lookandfeel from a TTY without having any display session started. If it works there, it should also work on any DE. If it doesn't maybe it does depend on some environment variable or service, which would IMO not be stylix's responsibility to get working, since these setups vary a lot between different DEs and WMs.

plasma-apply-lookandfeel --apply stylix does not work on a TTY as far as I can tell:

qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, xcb.

Exit code -6

Maybe it can work with a different platform plugin (some are listed in the error log), but I have no clue how to even test that.

Maybe it'll just work in any graphical session, even if it isn't Plasma specifically. But I can't test that right now since my Hyprland's been broken for a while (I never fixed it since I'm on KDE anyways).

So probably the easy way would be to instruct non-KDE users to add some sort of autostart to call plasma-apply-lookandfeel, which should be trivial on Hyprland with exec-once.

From what I can gather, it would work in any graphical session, as you said. I am bit unsure where to add the documentation, in order for it to be discoverable.

EDIT:
One option would be to add a read-only package option with ${pkgs.kdePackages.plasma-workspace}/bin/plasma-apply-lookandfeel --apply stylix script, which however feels a bit like bloat to me.

My only guess is that maybe autostart scripts aren't ran under Hyprland

I think all my applications are spawned by systemd, not hyprland, so I don't think this should be the case.

rebuild and switch in an already running desktop

I did rebuild & switch, then restarted my login session. Else I wouldn't really be able to tell if anything worked.

I'm pretty sure Plasma's autostart scripts don't run under Hyprland (at least not unless you script it yourself).

I have systemd-autostart running autostart scripts

So probably the easy way would be to instruct non-KDE users to add some sort of autostart to call plasma-apply-lookandfeel, which should be trivial on Hyprland with exec-once.

This is effectively what I've done, though not using exec-once, but autostart. I'm considering just creating a bash-script that does sleep 5 followed by apply-lookandfeel.

Yeah, that sounds like systemd-autostart runs it before Hyprland is ready... Maybe you can delay all of systemd-autostart though? Other apps surely could also misbehave if started too early.

True. The issue is that I got all of this "for free" by simply setting a nix option (something like hyprland.useUWSM, can't check it atm), so I don't quite know how it's all wired together.

Well, as far as I am aware, that isn't something I can fix on stylix's side. Given that this seems to be a niche issue, I think the best way to proceed is to leave the autostart as it is and ask KDE people for help (preferably for us to be able to apply look and feel on activation, without the need for separate autostart). I can do so when I have more time.

Agreed

I do not have any problems on Hyprland, since my wallpaper is set by hyprpaper:

Could you provide steps to reproduce this?

I`m not using hyprpaper - nor is the wallpaper a problem. OS level "dark mode" (and theming) is. My browser is currently stuck in light-mode (not sure why, but lookandfeel just stopped working for me, even though it worked just fine untill my last rebuild).

Could this problem be solved by sleeping or waiting until something specific is ready?

That used to work for me, but the latest messing around I've done with my config broke that. Now applying look and feel doesn't seem to do anything anymore. I've capitulated for now and manually put brave in dark mode

I think I got a fix for this.
As hinted in my previous comment, I tried to give Qt a platform to work with independently from the main Plasma/Hyprland session being fully started or not. There's some documentation for different Qt Platform Abstractions here but I couldn't get offscreen, vnc or minimal to work in my TTY.

Instead, I use xvfb-run to run the plasma-apply-* commands with a headless X11 server. By default each command takes 3 seconds, but this can be reduced (I didn't bother for now).

Since I'm on NixOS 24.11, I based my initial attempt on that, see 1427b55. Please use inputs.stylix.url = "github:lordkekz/stylix?ref=release-24.11"; if you want to try it because it also contains another commit to ignore when the wallpaper fails. I am strongly in favor of ignoring activation failures for both plasma-apply-* commands; they are expected to fail in some scenarios even when there is no misconfiguration in the system.

Note that we will still need the activator autostart script to apply the wallpaper (which actually does require plasma, not just a Qt platform).

@Alxandr could you please try #848 and see if it resolves your issue?

I kinda broke my filesystem, and need to get it rescued before I'm able to test anything unfortunately...

So probably the easy way would be to instruct non-KDE users to add some sort of autostart to call plasma-apply-lookandfeel, which should be trivial on Hyprland with exec-once.

The most popular DEs will do this automatically using the existing autostart desktop entry. This can also be added to other DEs/WMs by running a standalone implementation of XDG autostart, such as dex with the --autostart flag.

This can also be added to other DEs/WMs by running a standalone implementation of XDG autostart, such as dex with the --autostart flag.

Or run your WM in UWSM which handles this for you using systemd-autostart.