LXQT now starts in a vm for me, however there seems to be something up with the
theme and or icons.

Idem.

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707/6

cc @ttuegel any idea what's going wrong here?

Currently this is broken, and that's not a good shape for the release or users.

What theme package is used, and how is it installed?

These packages appear to be installed as pre-requisites

pkgs.gvfs # virtual file systems support for PCManFM-QT
pkgs.libsForQt5.kwindowsystem # provides some QT5 plugins needed by lxqt-panel
pkgs.libsForQt5.libkscreen # provides plugins for screen management software
pkgs.libfm
pkgs.libfm-extra
pkgs.lxmenu-data
pkgs.menu-cache
pkgs.openbox # default window manager
pkgs.qt5.qtsvg # provides QT5 plugins for svg icons

and I'm assuming the theming package would be lxqt-themes.

All of which are installed with environment.systemPackages via the lists in lxqt/default.nix.

I investigated this a little. It's unfortunately difficult to diagnose because applications seem to load their themes correctly, it's just the desktop that's the problem, and the desktop doesn't send logs to the system journal.

I think the default settings are just scrambled somehow. If I set the panel background color and the launcher icon, then everything seems to work OK; it looks like the defaults just aren't initialized correctly.

I think the default settings are just scrambled somehow. If I set the panel background color and the launcher icon, then everything seems to work OK; it looks like the defaults just aren't initialized correctly.

Ahh, I think I thought of the same thing. What operation does the application do to modify those things? If it's something environmental it can go in the session script, or maybe something is up with the startlxqt script in lxqt-session.

What operation does the application do to modify those things? If it's something environmental it can go in the session script, or maybe something is up with the startlxqt script in lxqt-session.

My best guess (unvalidated, at the moment) is that there is a "default" configuration file that ships with LXQT. The changes to the Qt wrappers might have broken the resolution of that file's name. Without the default file, the panel's color is "uninitialized"; IIRC the uninitialized QColor is all zeros, i.e. black.

So it does appear that the script for the environmental initialzation has an issue

if [ -z "$XDG_CONFIG_DIRS" ]; then
    export XDG_CONFIG_DIRS="/etc:/nix/store/hypj40wbcl8i9rl2b1915m4ny2yq28kg-lxqt-build-tools-0.6.0/etc/xdg:/var/empty/share"
else
    if ! contains "$XDG_CONFIG_DIRS" '/nix/store/hypj40wbcl8i9rl2b1915m4ny2yq28kg-lxqt-build-tools-0.6.0/etc/xdg'; then
        XDG_CONFIG_DIRS="$XDG_CONFIG_DIRS:/nix/store/hypj40wbcl8i9rl2b1915m4ny2yq28kg-lxqt-build-tools-0.6.0/etc/xdg"
    fi
fi

The nix store paths to lxqt-build-tools should be from within lxqt-session. Probably need to fix the cmake files.
As for where the it gets its settings, I'm pretty sure it's within lxqt-session and resolves it through the standard directories that could have gotten scrambled.

So in the process of debugging this it appears I've fixed a separate issue e34de04 that doesn't produce the effects I wanted.

With the paths corrected in the script this still occurs.

I've tried actually disabling wrapQtAppsHook from exporting XDG* variables by commenting it out and I didn't eliminate the issue, so perhaps this isn't caused from the wrapping?

are there environment variables I can set to get debug messages?

Can we merge this and fix up the theming in a new PR, it's rather annoying if one's terminal doesn't start...

@globin That's fine, I'm mostly holding off because this is a pretty ugly regression for users of the desktop.

Well it doesn't seem to work at all currently so this definitely should be an improvement already?

No disagreement there @globin. I just need someone to review my new changes then.

My best guess (unvalidated, at the moment) is that there is a "default" configuration file that ships with LXQT. The changes to the Qt wrappers might have broken the resolution of that file's name. Without the default file, the panel's color is "uninitialized"; IIRC the uninitialized QColor is all zeros, i.e. black.

@ttuegel - you are right

If I set the panel background color and the launcher icon, then everything seems to work OK; it looks like the defaults just aren't initialized correctly.

It seems more is broken with the panel when I compare the appearance with screenshots of how themes should look. For instance, no border colour is applied to the panel, which can make it look off.

Also, many app icons e.g., Firefox are missing from the generated start menu (even though they appear correctly in the taskbar), so it looks bad to the point of being unusuable for daily use.

Fixed by adding hicolor-icon-theme derivation as a fallback.

Are there any partial fixes for the panel problem? Thanks for any help.

I could not find a fix for this issue yet. As a workaround one can set the foreground and/or background colors in the lxqt panel properties.

As a workaround one can set the foreground and/or background colors in the lxqt panel properties.

As there are other theme attributes LXQT applies to the panel, aside from colour, this is only a partial workaround. It isn't a massive deal, but here is a screenshot of an LXQT theme I use on a laptop not switched over to NixOS yet. Notice the 3D border of the panel edge. Here is the same theme on NixOS. The panel is cutoff where the 3D border should appear, and the correct style for the buttons and workspaces do not get applied either. Spot the difference.

This particular theme still doesn't look too broken or inconsistent because the underlying widget-engine theme I'm using still gets applied, but other panel themes may look worse depending on the widgets used, as the styles aren't getting applied correctly. Hopefully I will figure out a fix soon.

When I was looking at this a while ago, it seemed that the theme paths were getting rewritten to the lxqt package, rather than the themes package.

@lordcirth I believe that was fixed in e34de04

@lordcirth I believe that was fixed in e34de04

It was not.

See #65482 (comment) onward.

Any themes installed by the package show in the preferences window to change themes, but do not get applied when selected. Themes installed in ~/.local/share/lxqt/themes also show, and also do not get applied when selected.