Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System Tray (v3) #743

Merged
merged 55 commits into from
Mar 30, 2024
Merged

System Tray (v3) #743

merged 55 commits into from
Mar 30, 2024

Conversation

ralismark
Copy link
Contributor

@ralismark ralismark commented Apr 9, 2023

Description

A system tray widget that supports the StatusNotifierItem protocol.

Supersedes #676. Currently very WIP. See below for more info.

Usage

The widget is called systray and can take the following properties:

  • pack_direction: one of "ltr"/"right", "rtl"/"left", "ttb"/"down", "btt"/"up" to specify the direction in which widgets are laid out
  • icon-size: an integer specifying the size of icons (in pixels)

Showcase

Demonstration of (systray :pack-direction "ttb") with a menu open:

Additional Notes

Closes #111.

This supersedes my previous attempt #676, which itself is a continuation of #448. The context behind this rewrite is this comment on #676 -- the main ones being:

  • Using libdbusmenu instead of our own menu handling, which should fix a lot of issues.
  • Integrating handling of the system tray protocol into this repo to make it easier to iterate on.

Checklist

Please make sure you can check all the boxes that apply to this PR.

  • All widgets I've added are correctly documented.
  • I added my changes to CHANGELOG.md, if appropriate.
  • The documentation in the docs/content/main directory has been adjusted to reflect my changes.
    • Document how to style the menus
  • I used cargo fmt to automatically format all code before committing

🚧 Remaining Work / Known Issues 🚧

Currently, this feature is functional enough to show icons, but needs much more testing and likely has numerous bugs and unsupported things. If you find issues, it would be really appreciated if you report them!

  • Better handling of multiple system trays, reloading, removing the widget, etc. for dbus state and tasks
  • Customisable item size
  • Dynamic icon
    • Support for OverlayIcon & AttentionIcon
  • Tooltip
  • Handling other button clicks & scrolling

@ralismark ralismark mentioned this pull request Apr 9, 2023
6 tasks
@eclairevoyant
Copy link
Contributor

eclairevoyant commented Apr 9, 2023

Not sure how to help debug this further, but eww crashes when I add systray to the config (I exported RUST_BACKTRACE=full before opening the bar):

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(Names(InvalidBusName("must start with a `:`", "each element must not start with a digit")))', crates/eww/src/widgets/systray.rs:84:55

Full stacktrace here: https://gist.githubusercontent.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d/raw/5fce16030bcee06390d0ac809a090917b4fa1c2b/eww%2520logs%2520stacktrace

For reference I'm building this as so: https://gist.githubusercontent.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d/raw/5fce16030bcee06390d0ac809a090917b4fa1c2b/PKGBUILD

@ralismark
Copy link
Contributor Author

@eclairevoyant I've pushed some changes, can you have another try?

@eclairevoyant
Copy link
Contributor

eclairevoyant commented Apr 9, 2023

eww starts now, but icons don't consistently show up (for example Steam was showing up at first, but after killing and restarting it no longer shows up, no matter what order I open steam vs eww).

FWIW the icons do show correctly in swaybar (and waybar, which seems to reliably update on the fly as well).

Also, running eww reload --debug leads to a crash:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NameTaken', crates/eww/src/widgets/systray.rs:65:47

full backtrace:
https://gist.githubusercontent.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d/raw/f8cb6d5c4a015de21fec82c5bc87140169e87ef0/reload%2520systrace

@ralismark
Copy link
Contributor Author

@eclairevoyant thanks for finding those! the latest commits should fix those

@eclairevoyant
Copy link
Contributor

eclairevoyant commented Apr 10, 2023

yep, seems to have fixed it. Fcitx5 and Steam show up correctly now.
I do notice the Fcitx5 icon doesn't change when switching languages, but maybe that's lower priority and can be fixed later on. The "base" icon itself displays correctly so it's good for now imo.

I did find another crash with Electron apps that use tray icons.
For example, webcord:

2023-04-10T07:53:59.059Z INFO  notifier_host::watcher  > new item: :1.62/StatusNotifierItemow_name", "WebCord")])
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(Failed("error occurred in Get")))', crates/eww/src/widgets/systray.rs:41:47

backtrace:

https://gist.githubusercontent.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d/raw/68332a65dcc5b70e38f55585e212210b05a596a0/electron%2520stacktrace

I don't think it's webcord specific as I was able to repro the crash with other apps like signal and discord (all use electron).

Another crash I found with blueman-manager (not an electron app of course):

 2023-04-10T08:17:51.817Z INFO  notifier_host::watcher  > new item: :1.144/org/blueman/sni
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(InvalidArgs("No such property “IconThemePath”")))', crates/eww/src/widgets/systray.rs:41:47

backtrace:
https://gist.githubusercontent.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d/raw/22a5ffb61535c96513e9bac32dee8d30d68d0ca5/blueman%2520stacktrace

@bwachter
Copy link

Any attempt of any app to create a status icon results in a log message like this, with nothing showing:

 2023-04-10T08:08:32.317Z INFO  notifier_host::watcher  > new item: :1.2668/org/blueman/sni
 2023-04-10T08:08:32.319Z WARN  notifier_host::host     > Could not create StatusNotifierItem from address ":1.2668": Names(InvalidBusName("must start with a `:`", "each element must not start with a digit"))

@ralismark
Copy link
Contributor Author

@bwachter i made some commits earlier today that should fix that, can make sure you're on the latest commit? if you still have that issue on the latest version can you run busctl --user list | grep StatusNotifier?

@i-can-not-program
Copy link

It doesn't work for me on NixOS and gives this error:

error: builder for '/nix/store/cl9q159h3s8r5xkgli19qbx7c2r1dyvb-eww-94309f96cbf78077fc50fb813c9e4c38e8faf072.drv' failed with exit code 101;
       last 10 log lines:
       >   Package dbusmenu-glib-0.4 was not found in the pkg-config search path.
       >   Perhaps you should add the directory containing `dbusmenu-glib-0.4.pc'
       >   to the PKG_CONFIG_PATH environment variable
       >   No package 'dbusmenu-glib-0.4' found
       >   Package dbusmenu-glib-0.4 was not found in the pkg-config search path.
       >   Perhaps you should add the directory containing `dbusmenu-glib-0.4.pc'
       >   to the PKG_CONFIG_PATH environment variable
       >   No package 'dbusmenu-glib-0.4' found
       >
       > warning: build failed, waiting for other jobs to finish...
       For full logs, run 'nix log /nix/store/cl9q159h3s8r5xkgli19qbx7c2r1dyvb-eww-94309f96cbf78077fc50fb813c9e4c38e8faf072.drv'.

full log: eww.log

@ettancos
Copy link
Contributor

ettancos commented Apr 10, 2023

thanks for the work, managed to style a tiny bit, but opening zoom (installed with flatpak, can't test without) caused a crash:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(UnknownProperty("Property org.kde.StatusNotifierItem.IconThemePath was not found in object /StatusNotifierItem")))', crates/eww/src/widgets/systray.rs:41:47thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(UnknownProperty("Property org.kde.StatusNotifierItem.IconThemePath was not found in object /StatusNotifierItem")))', crates/eww/src/widgets/systray.rs:41:47

backtrace does not seem to be more helpful here, do you need anything else?

migth have to do with my icon themes not available in the flatpak container, but it does seem to work with slack (also flatpak) without issues and anyhow it should not crash I guess

@eclairevoyant
Copy link
Contributor

eclairevoyant commented Apr 10, 2023

@ettancos same error that i reported above, i think actually maybe not, it does look slightly different despite failing on the same line for essentially the same cause. might be another case that needs handling
@i-can-not-program this branch builds fine, see my PKGBUILD for deps and build steps but if you're having trouble building I don't think this is the place to get support

@ettancos
Copy link
Contributor

ettancos commented Apr 10, 2023

this might be a eww-tray-hyprland interaction kind of thing so not very sure where this goes

i had to enable focusable in the eww window to be able to hit escape to close the menu (very used to this kind of workflow). problem is if I set the window stacking prop to foreground eww will take over the mouse focus even if the mouse is over the application window so clicks are not going to the app (I assume eww gets them), keyboard focus seem to work, but if I set it to background the dbusmenu window will be drawn behind the application

@bwachter
Copy link

@ralismark my build was at 132b18c - I've now pulled additional commits, and with 94309f9 it crashes on startup:

2023-04-10T19:51:53.124Z INFO  notifier_host::watcher  > new host: :1.2704
2023-04-10T19:51:53.132Z WARN  eww::script_var_handler > stderr of `notifications_listen`: 
2023-04-10T19:51:53.132Z WARN  eww::script_var_handler > stderr of `notifications_listen`: ** (tiramisu:32752): ERROR **: 22:51:53.131: tiramisu.vala:46: Unable to acquired DBus name.

@VuiMuich
Copy link

VuiMuich commented Apr 12, 2023

Since the two main programs I would want to use a dock for are steam and discord I have not tested any further programs.
But I can tell you that opening a systray window while discord is running or launching discord while a systray window is open crashes eww.

Not sure, why it does not print the full backtrace, as I suppose, I set it with set -gx RUST_BACKTRACE full (in fish shell) 🤷
Here is the output of the logs after it crashes.

 2023-04-12T15:45:03.930Z INFO  eww::app                > Opening window tray
 2023-04-12T15:45:03.965Z INFO  notifier_host::watcher  > new host: :1.198
 2023-04-12T15:45:04.090Z INFO  notifier_host::watcher  > new item: :1.170/StatusNotifierItem
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(Failed("error occurred in Get")))', crates/eww/src/widgets/systray.rs:41:47
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/result.rs:1785:5
   3: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   4: glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default
   5: glib::main_context_futures::TaskSource::dispatch
   6: g_main_context_dispatch
   7: <unknown>
   8: g_main_loop_run
   9: gtk_main
  10: eww::server::initialize_server
  11: eww::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Here is the full backtrace:

  2023-04-12T15:53:31.320Z INFO  eww::app                > Opening window tray
 2023-04-12T15:53:31.334Z INFO  notifier_host::watcher  > new item: :1.170/StatusNotifierItem
 2023-04-12T15:53:31.335Z INFO  notifier_host::watcher  > new host: :1.203
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(Failed("error occurred in Get")))', crates/eww/src/widgets/systray.rs:41:47
stack backtrace:
   0:     0x55d6b72491d0 - std::backtrace_rs::backtrace::libunwind::trace::ha93b1d4802475003
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   1:     0x55d6b72491d0 - std::backtrace_rs::backtrace::trace_unsynchronized::h40d7f2da011bd85b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55d6b72491d0 - std::sys_common::backtrace::_print_fmt::hd4c318607ed6977d
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x55d6b72491d0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h3d1dee5bf49c390e
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x55d6b7270a3e - core::fmt::write::h5629927f37465513
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/fmt/mod.rs:1202:17
   5:     0x55d6b7241b95 - std::io::Write::write_fmt::h41e38f576096734b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/io/mod.rs:1672:15
   6:     0x55d6b724aa43 - std::sys_common::backtrace::_print::hb4df1a69959f2fbc
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x55d6b724aa43 - std::sys_common::backtrace::print::h7093396eb4e737fc
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x55d6b724aa43 - std::panicking::default_hook::{{closure}}::h044155a56acd855d
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:295:22
   9:     0x55d6b724a72f - std::panicking::default_hook::hf2b314c3c2ce4158
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:314:9
  10:     0x55d6b724b0ea - std::panicking::rust_panic_with_hook::he1240b7f7e10f2ad
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:698:17
  11:     0x55d6b724afe7 - std::panicking::begin_panic_handler::{{closure}}::h60ca41cdf195e052
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:588:13
  12:     0x55d6b72496ec - std::sys_common::backtrace::__rust_end_short_backtrace::h0260dedd111c7b11
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x55d6b724ad02 - rust_begin_unwind
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:584:5
  14:     0x55d6b68e3a43 - core::panicking::panic_fmt::h44c2814e5bc1b46f
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/panicking.rs:142:14
  15:     0x55d6b68e3b93 - core::result::unwrap_failed::h09f85debf7d2260a
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/result.rs:1785:5
  16:     0x55d6b6af11f7 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h3bca14a624de6380
  17:     0x55d6b7221dcc - glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default::hecb764308d4d80a8
  18:     0x55d6b72252ea - glib::main_context_futures::TaskSource::dispatch::h2185ad61cc3ea797
  19:     0x7f10eada553b - g_main_context_dispatch
  20:     0x7f10eae02219 - <unknown>
  21:     0x7f10eada4c7f - g_main_loop_run
  22:     0x7f10ea74ae4f - gtk_main
  23:     0x55d6b6a1b56d - eww::server::initialize_server::h202905115a5d9a84
  24:     0x55d6b6a89399 - eww::main::h2670549213359a1a
  25:     0x55d6b6b79a13 - std::sys_common::backtrace::__rust_begin_short_backtrace::ha6081961802baf25
  26:     0x55d6b69dfb29 - std::rt::lang_start::{{closure}}::heb787f769b439e70
  27:     0x55d6b723bb1f - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h1f73150d454b41b9
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/ops/function.rs:280:13
  28:     0x55d6b723bb1f - std::panicking::try::do_call::hc2a0f6a54bbfbc83
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:492:40
  29:     0x55d6b723bb1f - std::panicking::try::h22dd2c39c33f5d79
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:456:19
  30:     0x55d6b723bb1f - std::panic::catch_unwind::h304ac8613501ec27
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panic.rs:137:14
  31:     0x55d6b723bb1f - std::rt::lang_start_internal::{{closure}}::h908b7e245713b406
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/rt.rs:128:48
  32:     0x55d6b723bb1f - std::panicking::try::do_call::h1343d879ac83b3c6
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:492:40
  33:     0x55d6b723bb1f - std::panicking::try::he03f984691a7ab4b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:456:19
  34:     0x55d6b723bb1f - std::panic::catch_unwind::h01722b96585f9bcd
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panic.rs:137:14
  35:     0x55d6b723bb1f - std::rt::lang_start_internal::h25ef46d553ec36b4
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/rt.rs:128:20
  36:     0x55d6b6a8a8f2 - main
  37:     0x7f10ea097790 - <unknown>
  38:     0x7f10ea09784a - __libc_start_main
  39:     0x55d6b68e3d95 - _start
  40:                0x0 - <unknown>

@ItsDrike
Copy link

ItsDrike commented Apr 12, 2023

I'm also experiencing an error, which is likely related to @eclairevoyant's report (and also to @VuiMuich's report, which afaik seem to be the same) about electron apps, though this is a different error.

This error only occurs when the bar is already running, and I start discord, while eclairevoyant's original report is what happens when discord is already running, and eww is only started afterwards.

Note: In the v2, discord tray icon worked properly.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusAddressError("org.kde.StatusNotifierItem-543854-1")', crates/eww/src/widgets/systray.rs:84:55
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Short backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusAddressError("org.kde.StatusNotifierItem-556569-1")', crates/eww/src/widgets/systray.rs:84:55
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/result.rs:1785:5
   3: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   4: glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default
   5: glib::main_context_futures::TaskSource::dispatch
   6: g_main_context_dispatch
   7: <unknown>
   8: g_main_loop_run
   9: gtk_main
  10: eww::server::initialize_server
  11: eww::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Full backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusAddressError("org.kde.StatusNotifierItem-550580-1")', crates/eww/src/widgets/systray.rs:84:55
stack backtrace:
   0:     0x561a3b33ba40 - std::backtrace_rs::backtrace::libunwind::trace::ha93b1d4802475003
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   1:     0x561a3b33ba40 - std::backtrace_rs::backtrace::trace_unsynchronized::h40d7f2da011bd85b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x561a3b33ba40 - std::sys_common::backtrace::_print_fmt::hd4c318607ed6977d
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x561a3b33ba40 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h3d1dee5bf49c390e
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x561a3b36314e - core::fmt::write::h5629927f37465513
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/fmt/mod.rs:1202:17
   5:     0x561a3b334415 - std::io::Write::write_fmt::h41e38f576096734b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/io/mod.rs:1672:15
   6:     0x561a3b33d2b3 - std::sys_common::backtrace::_print::hb4df1a69959f2fbc
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x561a3b33d2b3 - std::sys_common::backtrace::print::h7093396eb4e737fc
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x561a3b33d2b3 - std::panicking::default_hook::{{closure}}::h044155a56acd855d
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:295:22
   9:     0x561a3b33cf9f - std::panicking::default_hook::hf2b314c3c2ce4158
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:314:9
  10:     0x561a3b33d95a - std::panicking::rust_panic_with_hook::he1240b7f7e10f2ad
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:698:17
  11:     0x561a3b33d857 - std::panicking::begin_panic_handler::{{closure}}::h60ca41cdf195e052
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:588:13
  12:     0x561a3b33bf5c - std::sys_common::backtrace::__rust_end_short_backtrace::h0260dedd111c7b11
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x561a3b33d572 - rust_begin_unwind
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:584:5
  14:     0x561a3aa0b513 - core::panicking::panic_fmt::h44c2814e5bc1b46f
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/panicking.rs:142:14
  15:     0x561a3aa0b663 - core::result::unwrap_failed::h09f85debf7d2260a
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/result.rs:1785:5
  16:     0x561a3ac0b962 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h65e04a1423d57019
  17:     0x561a3b3146bc - glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default::hecb764308d4d80a8
  18:     0x561a3b317b6a - glib::main_context_futures::TaskSource::dispatch::h2185ad61cc3ea797
  19:     0x7fa88a3a753b - g_main_context_dispatch
  20:     0x7fa88a404219 - <unknown>
  21:     0x7fa88a3a6c7f - g_main_loop_run
  22:     0x7fa88a9d8e4f - gtk_main
  23:     0x561a3ab9ec5e - eww::server::initialize_server::h4e65562e48b2ee6d
  24:     0x561a3ab72d0e - eww::main::h89ace478fcbe75a5
  25:     0x561a3ac8f143 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2afa6a757a2f6f59
  26:     0x561a3aae5dc9 - std::rt::lang_start::{{closure}}::hf2b91b5d01083cb8
  27:     0x561a3b32e39f - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h1f73150d454b41b9
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/core/src/ops/function.rs:280:13
  28:     0x561a3b32e39f - std::panicking::try::do_call::hc2a0f6a54bbfbc83
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:492:40
  29:     0x561a3b32e39f - std::panicking::try::h22dd2c39c33f5d79
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:456:19
  30:     0x561a3b32e39f - std::panic::catch_unwind::h304ac8613501ec27
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panic.rs:137:14
  31:     0x561a3b32e39f - std::rt::lang_start_internal::{{closure}}::h908b7e245713b406
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/rt.rs:128:48
  32:     0x561a3b32e39f - std::panicking::try::do_call::h1343d879ac83b3c6
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:492:40
  33:     0x561a3b32e39f - std::panicking::try::he03f984691a7ab4b
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panicking.rs:456:19
  34:     0x561a3b32e39f - std::panic::catch_unwind::h01722b96585f9bcd
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/panic.rs:137:14
  35:     0x561a3b32e39f - std::rt::lang_start_internal::h25ef46d553ec36b4
                               at /rustc/c07a8b4e09f356c7468b69c50cac7fc5b5000b8a/library/std/src/rt.rs:128:20
  36:     0x561a3ab73cc2 - main
  37:     0x7fa88a069790 - <unknown>
  38:     0x7fa88a06984a - __libc_start_main
  39:     0x561a3aa0b865 - _start
  40:                0x0 - <unknown>

In case it would matter, I'm on wayland, not X11.

@VuiMuich
Copy link

Oh, right, I just skimmed through previous reports as I supposed those where all related to the build issues, sorry.

As @ItsDrike reported, in the v2 branch discord worked well, so this might be discord vs dbus related?
I am using x11, so I guess it is independent of display servers.

@eclairevoyant
Copy link
Contributor

@ItsDrike same crash happens either way for me, independent of order of starting apps

@VuiMuich seems more like just error handling differences, but idk rust tbh

@Lord-Valen
Copy link

@i-can-not-program Well the error is quite obvious, it can't find dbusmenu-glib-0.4.pc, install whatever package provides it for you. Here's the Void Linux example:

$ xlocate dbusmenu-glib-0.4.pc
libdbusmenu-glib-devel-16.04.0_5        /usr/lib/pkgconfig/dbusmenu-glib-0.4.pc

That simply isn't how Nix works. A nix build is not like building on other distros. If complete dependencies aren't defined, the package will not build. Derivations are supposed to describe everything that is needed to build them -- dependencies and build steps. If the build is failing, it is because the flake's package derivation is inadequate. If the build fails on one supported system, it fails on all supported systems regardless of the packages users install. Obviously, changes that would cause the package to fail builds are relevant to the PR.

@eclairevoyant
Copy link
Contributor

@Lord-Valen Incorrectly specifying dependencies in your nix derivation has nothing to do with this PR, which is why I said this isn't the place to get support for how to use nix

@eclairevoyant
Copy link
Contributor

eclairevoyant commented Apr 29, 2023

Apologies, I didn't realise this repo had a flake file in it. Nevertheless, this is still a change that needs to be made on the nixpkgs end, because that's where all the dependencies are specified.

As a workaround if you want to test this on nix you can use the same dependencies that were added to the dev shell output, by adding this after line 38:

# TODO remove after next release
buildInputs = old.buildInputs ++ (with final; [ glib librsvg libdbusmenu-gtk3 ]);

and applying the fix from #748.

I don't know if that's necessary to put in the PR since it'll end up being removed, I'll leave that up to the maintainer to decide

@Onyx47
Copy link
Contributor

Onyx47 commented Apr 30, 2023

I just want to add on to @VuiMuich here: It's not Electron specific, I'm getting the same issue with qbittorrent and keepassxc, seems to be an issue with non-GTK applications to me.

I can add full traces, but here are the errors on crash:

qbittorrent:
2023-04-30T16:09:08.003Z INFO  notifier_host::watcher  > new item: :1.6685/StatusNotifierItem
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(UnknownObject("No such object path '/StatusNotifierItem'")))', crates/eww/src/widgets/systray.rs:41:47

keepassxc:
2023-04-30T16:26:21.426Z INFO  notifier_host::watcher > new item: :1.6807/StatusNotifierItem
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DbusError(FDO(UnknownProperty("Property org.kde.StatusNotifierItem.IconThemePath was not found in object /StatusNotifierItem")))', crates/eww/src/widgets/systray.rs:41:47

Note that uncommenting the icon creation code on the given line "fixes" the crash and the context menus work correctly when clicking on the space which the empty icon occupies. So it's just the actual icon that's causing issues.

I'll try to look into this more myself but not really knowing much Rust or GTK I'm not very hopeful that I'll make much progress.

@ralismark
Copy link
Contributor Author

Sorry for all the crashes! Compared to v2, this has a completely different implementation of the dbus bits. I mainly wanted limitations with the implementation to be really obvious while I'm still ironing out all the bugs. When I'm happy with the state of things, i'll add in better error handling that does something sensible.

However, I've been seriously busy with life & work the past few weeks and haven't really had time to go through and actually investigate these issues.... :(

@Onyx47
Copy link
Contributor

Onyx47 commented May 5, 2023

Fixed the crashes at least! See ralismark#2 if you're impatient and want to patch it yourself.

Discord (and probably other Electron stuff) still needs pixmap support so it will show a default "Not found" icon for now, but at least it won't crash the bar and the menu is functional.

Excuse my Rust if something I did is a no-no 😛

@mauricekraus
Copy link

I tried @Onyx47 fixes and they seem to be very stable, however what occurred to me that applets like nm-applet are not shown nor throw any error.

@Onyx47
Copy link
Contributor

Onyx47 commented May 6, 2023

While the code needs some serious review (because, again, still fumbling in Rust), applications that don't have a system icon but they expose it in the DBus interface now also have an icon. For example, Discord now works:

image

Hopefully once @ralismark gets some time to do stuff again this will at least help on the research side of things. There are still edge cases about (found one application that still has a broken icon), but so far no crashes at least.

@mauricekraus - took a peek, nm-applet does not seem to use StatusNotifier protocol at all, at least I didn't manage to find anything on DBus that conforms to it. It might be still using some of the older system tray protocols, so no dice on that without a lot of additional work.

@eclairevoyant
Copy link
Contributor

eclairevoyant commented May 6, 2023

nm-applet has supported appindicator for years, works fine on my end? maybe you have an older version installed?

image

@Onyx47
Copy link
Contributor

Onyx47 commented May 6, 2023

Ah, @mauricekraus might be making the same mistake I did when I tried and it didn't work - and the man page is horrible: it mentions options but doesn't list any.

With nm-applet --indicator it works perfectly.

@eclairevoyant
Copy link
Contributor

I actually didn't need to pass that flag, since as of 1.32.0 it defaults to appindicator when xembed isn't available

@0xC0ncord
Copy link

0xC0ncord commented Mar 8, 2024

I'll aim to get documentation in within a week or two (sorry if I forget, please remind me if I do), but I'm not sure how much of the code TODOs I'll get around to.

Hey @ralismark, just checking to see how you're doing with the remainder of the items. Please let us know if there's anything you need help with -- I'm sure some of us who are really looking forward to this feature would be willing to do whatever we can to help get this across the finish line. :)

Copy link
Contributor Author

@ralismark ralismark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty much happy with how everything is now -- I've fixed up all the TODOs I wanted to fix myself. All the remaining TODOs should now have a review comment on them explaining what they mean and how important they are -- I think all of them are pretty minor.

Let's get this (finally) merged!


/// Get the current icon.
pub async fn icon(&self, size: i32, scale: i32) -> Option<gtk::gdk_pixbuf::Pixbuf> {
// TODO explain what size and scale mean here
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@moetayuko you were the original contributor of the HiDPI feature, can you explain what size and scale mean?

let (addr, path) = {
// Based on <https://github.com/oknozor/stray/blob/main/stray/src/notifier_watcher/notifier_address.rs>
//
// TODO is the service name format actually documented anywhere?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oknozor I took this parsing logic from your repo, do you know how you came up with it?

fn remove_item(&mut self, id: &str);
}

// TODO We aren't really thinking about what happens when we shut down a host. Currently, we don't
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO is only for proper behaviour when you keep the DBus connection around but stop having a systray. I don't think fixing this is a blocker for merging -- it only really means that tray icons may think there's a tray when there isn't one, which isn't really a problem.

Err(e) => log::warn!("failed to get menu: {}", e),
}

// TODO this is a lot of code duplication unfortunately, i'm not really sure how to
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO is just about making the code here a bit nicer. I can't think of how so if you do know please let me know.

}

async fn dbus_session() -> zbus::Result<&'static DBusSession> {
// TODO make DBusSession reference counted so it's dropped when not in use?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO is just for not taking up resources when we don't need it -- there's not much benefit beyond that, to be honest.


/// Get the menu of this item.
pub async fn menu(&self) -> zbus::Result<gtk::Menu> {
// TODO document what this returns if there is no menu.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation TODO. Nice to have but not necessary I guess.

#[zbus(connection)] con: &zbus::Connection,
#[zbus(signal_context)] ctxt: zbus::SignalContext<'_>,
) -> zbus::fdo::Result<()> {
// TODO right now, we convert everything to the unique bus name (something like :1.234).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a correctness issue, but if no one has raised it in the ~year this PR has been around it might be fine.

@elkowar
Copy link
Owner

elkowar commented Mar 16, 2024

Looking great! I'll be using this for the next few days, and let's give the people you pinged a bit more time to reply -- but other than that, I guess this is pretty much ready for merge! HYPE!

@moetayuko
Copy link
Contributor

@elkowar can you also review ralismark#6? while it's okay to relocate it here as a new PR after this PR gets merged, it contains breaking changes so simultaneously check-in both is better for UX

@bvr-yr
Copy link

bvr-yr commented Mar 23, 2024

@elkowar can you also review ralismark#6? while it's okay to relocate it here as a new PR after this PR gets merged, it contains breaking changes so simultaneously check-in both is better for UX

please do this, it's half-usable without proper click handling

@Itstatertots
Copy link

Itstatertots commented Mar 28, 2024

im trying to install through the aur and when i add the systray widget my eww closes

it says unknown widget when i try and run it with debug

@samchouse
Copy link

This feature isn't on main branch yet so it's also not in the aur. You have to compile manually off this PR if you want to use the systray.

@Itstatertots
Copy link

Weird I thought it was bc of this https://aur.archlinux.org/packages/eww-tray-wayland-git
Either way could you explain how to do that I'm self taught and new to all of this

@samchouse
Copy link

You need to have that installed and follow this, https://elkowar.github.io/eww.

@elkowar
Copy link
Owner

elkowar commented Mar 30, 2024

Let's merge this! Thanks a TON for your work, @ralismark, and huge thanks to all the others that have worked on this over the past year(s). Y'all are amazing!

@elkowar elkowar merged commit 1b819fb into elkowar:master Mar 30, 2024
1 check passed
@0xC0ncord 0xC0ncord mentioned this pull request Apr 1, 2024
4 tasks
@NicTanghe
Copy link

since this is such a major added feature could you consider releasing a 5.1 build ?
so that the mainline packages all have this feature ?

@ralismark ralismark deleted the tray-3 branch May 6, 2024 05:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE] Tray Support