bug: missing icons on applications started as user services

andresilva commented 2 years ago

Is there an existing issue for this?

[X] I have searched the existing issues

Issue description

As an example starting pasystray as a user service or manually starting pasystray results in a different set of icons being used.

Started as user service:

service

Started manually from a user shell:

plain

I don't have any custom GTK theme configuration, just using the defaults. This behavior has changed recently but I can't point to any home-manager or nixpkgs commit that introduced the change.

Maintainer CC

No response

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.17.1, NixOS, 22.05 (Quokka), 22.05.git.f008b756b2b`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - channels(root): `"nixos"`
 - channels(andre): `""`
 - nixpkgs: `/etc/nixos/nixpkgs`

sumnerevans commented 2 years ago

I notice that in general, system-started things don't have tray icons either. I wonder if there's some sort of icon lookup path we need to add.

rycee commented 2 years ago

In general I think having XDG_DATA_DIRS imported into the systemd environment should suffice?

Could you try running

$ systemctl --user show-environment | grep XDG_DATA_DIRS

and see if it exists, and if so whether it is different from the output of

$ echo $XDG_DATA_DIRS

andresilva commented 2 years ago

In my case it is defined and has the exact same value as the environment variable in a user shell.

steveej commented 2 years ago

In my case it is defined and has the exact same value as the environment variable in a user shell.

this is the case for me as well.

on my system it seems to be specific to some services only and i noticed this on the systray icons.

while redshift, blueman-applet and flameshot work, cbatticon and pasystray do not. the broken ones just leave a gap in the systray.

for me this issue was introduced with the update to nixos-22.05. i noticed that the icon packages i had installed were renamed or removed, which may or may not be related. FWIW, here's the compressed diff for these changes in my config:

   home.packages = with pkgs; [
-    gnome3.gnome_themes_standard
-    gnome3.adwaita-icon-theme
+    gnome.gnome-themes-extra
+    gnome.adwaita-icon-theme

mpasternacki commented 2 years ago

I see a similar effect, which might be the same underlying issue or a completely different one:

xsession.windowManager.command = "${pkgs.cwm}/bin/cwm";
services.polybar.enable = true; (plus a good polybar config, omitted for brevity)

services.volctl.enable = true; – locally defined user-systemd service for an existing program, configured like other systray services:

systemd.user.services.volctl = {
  Unit = {
    Description = "Volume control";
    Requires = [ "tray.target" ];
    After = [ "graphical-session-pre.target" "tray.target" ];
    PartOf = [ "graphical-session.target" ];
  };

  Service = {
    ExecSearchPath = "${pkgs.pavucontrol}/bin";
    ExecStart = "${pkgs.volctl}/bin/volctl";
  };

  Install = { WantedBy = [ "graphical-session.target" ]; };
};

When xsession starts, volctl runs, but there's no icon in polybar. There's a space where icon should be, but it doesn't react to click.

I have no other systray services to compare.

Restarting volctl doesn't change anything. Restarting polybar fixes the situation – in restarted polybar, the volctl icon is visible and clickable.

polybar's internal/window module also doesn't work when started with xsession and is fixed by restarting polybar. The xsession–started polybar logs are:

Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|warn:  Naming your configuration file 'config' is deprecated, the expected name is 'config.ini'.
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Parsing config file: /home/japhy/.config/polybar/config
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loading module 'ewmh' of type 'internal/xworkspaces'
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loading module 'title' of type 'internal/xwindow'
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|error: Disabling module "title" (reason: The WM does not list _NET_ACTIVE_WINDOW as a supported hint)
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loading module 'clock' of type 'internal/date'
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loading module 'temperature' of type 'internal/temperature'
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loading module 'battery' of type 'internal/battery'
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loaded 4 modules
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|notice:  Loaded font "Go" (name=Go, offset=0, file=/nix/store/95rvhvpcww8b27xb5yryncqfg6g3j28g-home-manager-path/share/fonts/truetype/Go-Regular.ttf)
Jul 03 21:09:50 edalyn polybar-start[9960]: polybar|error: Failed to query _XEMBED_INFO, removing client... (XCB_WINDOW (3))

It looks like polybar needs some properties started by window manager that aren't present. The middle section of HM-generated ~/.xsession goes like this:

systemctl --user start hm-graphical-session.target

# [cut initExtra]

/nix/store/kkbdkacyk6j5ahi9y0vmh3sbldfizb96-cwm-6.7/bin/cwm

systemctl --user stop graphical-session.target
systemctl --user stop graphical-session-pre.target

# Wait until the units actually stop.

Window manager is not part of systemd setup, and waiting for WM properties in a user service that belongs to hm-graphical-session.target might deadlock. I have no idea at this moment for how to fix that situation. Could WM be moved to a systemd unit somehow?

stale[bot] commented 1 year ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

steveej commented 1 year ago

I marked this issue as stale due to inactivity

my described issue have remained but i've not gained further insight.

andresilva commented 1 year ago

For me the issue seems to have been mostly solved after installing the gnome-icon-theme package.

steveej commented 1 year ago

For me the issue seems to have been mostly solved after installing the gnome-icon-theme package.

thanks. FWIW, i've tried adding pkgs.gnome-icon-theme to home.packages and it didn't help here.

silvanshade commented 5 months ago

I'm seeing this same issue, but in the context of waybar's taskbar module.

If waybar is started via the terminal or directly via the compositor (hyprland), icons in the taskbar show up as expected.

If waybar is started as a systemd service via programs.waybar.systemd.enable = true, most of the icons that show up in the taskbar are blank placeholders.

The only exception on my system seems to be Google Chrome, which shows the correct icon. Incidentally, Google Chrome is the only application that has a .desktop entry under ~/.local/share/applications.

Attaching to waybar with strace seems to indicate that most of the time it's trying to look up entries for unknown.desktop or .desktop (indicating an empty name string) rather than the correct app name.

In my case, systemctl --user show-environment | grep XDG_DATA_DIRS does show some differences to env | grep XDG_DATA_DIRS executed as the user in a graphical terminal, but the extra entries are mostly for gnome-shell and don't include the applications for which the icons are missing anyway.

It seems that for some reason, waybar (or similar apps) launched as user services under systemd via home-manager aren't receiving the correct metadata to actually look up the icon data when requested.

I don't know enough to understand what could cause that but maybe someone else has some ideas.

nix-community / home-manager