System Tray (v3)

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

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

:construction: Remaining Work / Known Issues :construction:
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

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
stack backtrace:
   0:     0x5648ae36b66a - std::backtrace_rs::backtrace::libunwind::trace::h36eacf401795ea3b
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x5648ae36b66a - std::backtrace_rs::backtrace::trace_unsynchronized::hb87bf1e96b38c7cb
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x5648ae36b66a - std::sys_common::backtrace::_print_fmt::h2b17190245ca0f2f
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x5648ae36b66a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h57a3b0c077c1808b
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x5648ae39565f - core::fmt::write::h6246f7e9e1f91310
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/fmt/mod.rs:1254:17
   5:     0x5648ae366ce5 - std::io::Write::write_fmt::hdaab967c27a3c2d2
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/io/mod.rs:1698:15
   6:     0x5648ae36b435 - std::sys_common::backtrace::_print::h0ad3185cdd4d6d17
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:47:5
   7:     0x5648ae36b435 - std::sys_common::backtrace::print::he2ffc525e0cbf07c
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:34:9
   8:     0x5648ae36cade - std::panicking::default_hook::{{closure}}::hc1124ef8f66ed33f
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:269:22
   9:     0x5648ae36c885 - std::panicking::default_hook::hb01528e27b8ba1d7
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:288:9
  10:     0x5648ae36d03e - std::panicking::rust_panic_with_hook::he404bd653c842314
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:690:13
  11:     0x5648ae36cf39 - std::panicking::begin_panic_handler::{{closure}}::h55a3075ac1d86afd
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:581:13
  12:     0x5648ae36bad6 - std::sys_common::backtrace::__rust_end_short_backtrace::h176586461c131da7
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:150:18
  13:     0x5648ae36cc92 - rust_begin_unwind
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:577:5
  14:     0x5648ada24493 - core::panicking::panic_fmt::h303ff62b64cb4509
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/panicking.rs:67:14
  15:     0x5648ada24943 - core::result::unwrap_failed::h734496769bf336b3
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/result.rs:1687:5
  16:     0x5648adc26722 - core::result::Result<T,E>::unwrap::hf47c26641b1a0c27
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/result.rs:1089:23
  17:     0x5648adc26722 - eww::widgets::systray::maintain_menubar::{{closure}}::hc3fad990cf1b86dc
                               at /usr/src/debug/eww-wayland-systray-git/eww/crates/eww/src/widgets/systray.rs:84:9
  18:     0x5648ae34697b - glib::main_context_futures::TaskSource::poll::{{closure}}::h1fa849af612f24d0
                               at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.15.12/src/main_context_futures.rs:233:17
  19:     0x5648ae34697b - glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default::h29a5ff8c97bfcd17
                               at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.15.12/src/main_context.rs:156:12
  20:     0x5648ae34417a - glib::main_context_futures::TaskSource::poll::h4c3bdb766a7f6a99
                               at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.15.12/src/main_context_futures.rs:226:9
  21:     0x5648ae34417a - glib::main_context_futures::TaskSource::dispatch::hab196a8018070e19
                               at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.15.12/src/main_context_futures.rs:67:34
  22:     0x7fb010d6153b - g_main_context_dispatch
  23:     0x7fb010dbe219 - <unknown>
  24:     0x7fb010d60c7f - g_main_loop_run
  25:     0x7fb0113d8e4f - gtk_main
  26:     0x5648adc5cf72 - eww::server::initialize_server::h478760db2a188356
                               at /usr/src/debug/eww-wayland-systray-git/eww/crates/eww/src/server.rs:125:5
  27:     0x5648adb9db70 - eww::run::h1074e6622e1560ac
                               at /usr/src/debug/eww-wayland-systray-git/eww/crates/eww/src/main.rs:156:39
  28:     0x5648adb9db70 - eww::main::hd6393d9157e46ed9
                               at /usr/src/debug/eww-wayland-systray-git/eww/crates/eww/src/main.rs:69:18
  29:     0x5648adcb7ac3 - core::ops::function::FnOnce::call_once::he3ebd3b0a7514c2f
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/ops/function.rs:250:5
  30:     0x5648adcb7ac3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5ffe8425ecd9e846
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/sys_common/backtrace.rs:134:18
  31:     0x5648adba1089 - std::rt::lang_start::{{closure}}::hf17d41adb1f400f4
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/rt.rs:166:18
  32:     0x5648ae360b6e - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::ha5f61d868738642d
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/core/src/ops/function.rs:287:13
  33:     0x5648ae360b6e - std::panicking::try::do_call::h3766da4608915cb1
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:485:40
  34:     0x5648ae360b6e - std::panicking::try::h4cc51c799f4f8cc6
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:449:19
  35:     0x5648ae360b6e - std::panic::catch_unwind::hb284be48c6757a9c
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panic.rs:140:14
  36:     0x5648ae360b6e - std::rt::lang_start_internal::{{closure}}::h9eabba50f5d76d69
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/rt.rs:148:48
  37:     0x5648ae360b6e - std::panicking::try::do_call::h4596fba5de32e7ab
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:485:40
  38:     0x5648ae360b6e - std::panicking::try::hf1496fec4e0450ab
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panicking.rs:449:19
  39:     0x5648ae360b6e - std::panic::catch_unwind::h04f21c8ee7b07770
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/panic.rs:140:14
  40:     0x5648ae360b6e - std::rt::lang_start_internal::hddb97da39b1fc896
                               at /rustc/af06dce64bf87ea9206bdf6cff61c144b9ce8458/library/std/src/rt.rs:148:20
  41:     0x5648adba00ec - main
  42:     0x7fb010a03790 - <unknown>
  43:     0x7fb010a0384a - __libc_start_main
  44:     0x5648ada24b25 - _start
  45:                0x0 - <unknown>

For reference I'm building this as so: https://gist.github.com/eclairevoyant/d077cd0ecd0ff56d9f9f946da11e2f7d

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

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).
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

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

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.
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).

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"))

@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 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
libdbusmenu-glib-devel-32bit-16.04.0_5  /usr/lib32/pkgconfig/dbusmenu-glib-0.4.pc

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?

@ettancos same error that i reported above
@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

this might be a eww-tray-hyprland interaction kind of thing so not very sure where this goes
i had to set the eww window to focusable to be able to hit escape to close the menu (very used to this kind of workflow). problem is if I set the stacking to foreground eww will take over the mouse focus even if mouse is over the workspaces so clics are not going to the app (I assume eww gets them), keyboard focus seem to work, but if I set it to background the popup will be drawn behind the workspace

@ralismark my build was at 132b18c30525adca8aba212f7a592f679cbb10a1 - I've now pulled additional commits, and with 94309f96cbf78077fc50fb813c9e4c38e8faf072 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.

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) :shrug:
 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.

I'm also experiencing an error, which is likely related to @eclairevoyant's report about electron apps, though it 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.
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>

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.

@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

@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.

@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

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 ]);

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

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.

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.

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:

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.

nm-applet has supported appindicator for years, works fine on my end?

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.

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

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

That explains it then, I have 1.30.0 (Debian testing), either way something to document I guess.

Thanks for the heads up, @Onyx47 & @eclairevoyant. I am running version 1.32, but I believe this is an environmental issue. I don't have GNOME installed, just basic I3 on Vanilla Arch. However, I can work around it by using the network manager dmenu implementation. Running with the indicator flag doesn't have any effect either. What's strange is that the I3-Bar displays it perfectly.

Since you're using i3 it will default to using xembed which is naturally only supported in x11. i3bar implements the xembed spec and does not implement the appindicator spec (which I find a little surprising, but see i3/i3#2088), hence nm-applet defaults to the former. I'm using waybar under sway instead, which has appindicator support, so it defaults the other way.
I've found an example xembed implementation in Rust, but xembed support should be a separate PR if eww wants to support this.

Happy to c you guys are getting me what I want.

It seems like it ignores which mouse button is pressed and just open the context menu on any mouse button some programs eg radeon-profile open the programm on left click
Note: I am on wayland and I use the https://github.com/ralismark/eww/pull/2 patch

Alexays/Waybar#768 describes a similar issue; I do notice though, waybar handles other programs like keepassxc correctly (left-click shows/hides, right-click gives menu) whereas this tray-3 uses the right-click menu always

Entries with an arbitrary icon path are showing a placeholder image instead of the icon. ex: jellyfin-mpv-shim is trying to load its icon from /tmp/tmp3oyvjdlz, causing this warning. I am using Onyx's patch. (ralismark#2)
2023-05-26T02:08:10.839Z WARN  notifier_host::item    > Could not find icon "/tmp/tmp3oyvjdlz" in default theme: Icon '/tmp/tmp3oyvjdlz' not present in theme Papirus-Dark
2023-05-26T02:08:10.839Z WARN  notifier_host::item    > Could not find icon "/tmp/tmp3oyvjdlz" in default theme: Icon '/tmp/tmp3oyvjdlz' not present in theme Papirus-Dark

So I have tried to use it inside of my dotfiles and 2 scenarios crash it:

Using WebCord as a discord Client will crash it
Using blueman-applet for bluetooth manager crashes it

They both crash with the error
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

So I have tried to use it inside of my dotfiles and 2 scenarios crash it:
* Using WebCord as a discord Client will crash it

* Using blueman-applet for bluetooth manager crashes it

They both crash with the error
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

ralismark#2 should fix this

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

I argue that it's better to put that in the PR than not, since even if it's forgotten about, it won't hurt when the dependency gets added in nixpkgs too. This will make it easier for Nix users to work on the PR.

I've got a bit of time to work on this PR again :) and have now incorporated @Onyx47's changes into this branch. Thanks for that change :blush:, and thanks everyone that's been testing!
Since this has been a PR for a couple of months, I do wanna get it merged soon. Looking through the StatusNotiferItem spec, actually a surprising amount of functionality beyond just icon + menu e.g. OverlayIcon/AttentionIcon, tooltips, scrolling & other mouse button actions, etc. I'm still a bit limited on time/energy, so I think it might be worth leaving those out of this PR to avoid delaying it further -- before getting this merge-ready (which is probably a decent amount of work), I'm planning on focusing on just:

allowing the size of icons to be customised -- i haven't really hardcoded the size anywhere so it shouldn't be too hard
ironing out issues with the default icon -- thanks everyone that's been testing! one issue i do know of is that we only look for a 24x24 pixmap, not other sizes -- I've found keepassxc has this issue, so it's pretty easy to reproduce
implementing cleanup & avoiding memory/async task leaks when reloading

So I have been doing some testing with the updated branch and from tests I can see:

nm-applet works
udiskie tray works
blueman applet works
WebCord Applet works but has no Icon

One edge case that I did notice is it seems like the background of the menus seems to be transparent in my setup. So I am unsure what's causing this and I can't eww inspector because it will close so this requires further digging on my part. But even setting the background-color to having an A value of 1 doesn't work. So either something is overiding this in which case it's an issue on my side or it's not properly applying styles.

I would just like to add that there's also an issue with at the very least qbittorrent exposing two tray icon entries. I wasn't able to figure out how to pick the "correct" entry nor what the reason for two entries is. It might be some low hanging fruit there to figure out how to handle that case.

I've done a big refactor of icon handling (again), should fix keepassxc. lmk if there are still issues.
Icon size is now customisable, and I've hopefully done task cleanup correctly, so gonna mark this as ready :tada:
@Onyx47 when I run qbittorrent it only shows one icon. Can you make sure that eww is the only systray running, retstart eww (preferably with qbittorrent as the only app with a tray icon), then send logs?

Hi, I have a small issue with this - most of my icons are missing (gammastep and nm-applet) and show these errors in the logs:
 2023-06-21T22:13:55.892Z WARN  notifier_host::icon     > failed to get icon by name for :1.37: loading icon "gammastep-status-on" from theme None
 2023-06-21T22:13:55.894Z WARN  notifier_host::icon     > failed to get icon by name for :1.228: loading icon "nm-signal-100" from theme None

I've noticed it says "theme None", which sounds like it doesn't detect my theme properly?
I also have another Rust project - https://github.com/Kirottu/anyrun/, which does detect my icon theme just fine.
Could this be a NixOS issue?

@n3oney theme None here means it's looking in the default theme -- i've edited this message to hopefully make more sense. I've also added some debug logging, so can you try the latest version and send logs after running with --debug

Okay, it seems to be some nix issue. I've built it from source with cargo and ran it - the icons load fine.
I've then built it with Nix - no icons work...

Note - the icons exist in XDG_DATA_DIRS.
My default theme is Papirus-Dark.

The new logs from within the dev shell with the icon working:
 2023-06-22T13:00:14.278Z DEBUG notifier_host::icon     > dbus: :1.94 icon_name -> Ok("nm-device-wired")
 2023-06-22T13:00:14.278Z DEBUG notifier_host::icon     > dbus: :1.94 icon_theme_path -> Ok("")

Logs from outside of the shell:
 2023-06-22T13:01:13.237Z DEBUG notifier_host::icon     > dbus: :1.94 icon_name -> Ok("nm-device-wired")
 2023-06-22T13:01:13.237Z DEBUG notifier_host::icon     > dbus: :1.94 icon_theme_path -> Ok("")
 2023-06-22T13:01:13.269Z WARN  notifier_host::icon     > failed to get icon by name for :1.94: loading icon "nm-device-wired" from theme (default)

@elkowar: thoughts on this PR? Friendly ping since you haven't commented on this PR and the CI for this PR is still waiting for approval.

@elkowar just another friendly ping because it's been 2 weeks, and I know I and probably a lot of other people are keeping a close eye on this PR so we can switch from status bars like Waybar to Eww

Sorry for my silence, I'll try to take a look at this in the next few days or weeks, worst case. Could someone tldr me the current status of the functionality? Are there still things to iron out, or could this be considered ready to go, if it passes review and stuff?

After using it for a few days:

Default styling is non-existent and menus are unusable with everything squashed together and a transparent background
Icons don't update, eg nm-applet connection strength/VPN status
Checkboxes are missing by default
Tooltips are missing

But once styled it's quite effective, no crashes or anything in eww logs

In my personal opinion, it's functional enough for everyday use. It does everything I expect from a systray and without many issues. I've never experienced any software crashes related to the systray widget.
The one issue I found is that clicking with any mouse button (even thumb buttons) opens the context menu, but the menuitems only work if the menu itself was opened using the left mouse button. It doesn't impede functionality, but  worth mentioning nevertheless.

Default styling is non-existent and menus are unusable with everything squashed together and a transparent background

Would your stylesheet happen to have * { all: unset; } in it? The context menu is built from GTK widgets and inherits the system's GTK theme.

It's functional, not complete.

Would your stylesheet happen to have * { all: unset; } in it? The context menu is built from GTK widgets and inherits the system's GTK theme.

You're right, edited

Hey, i apologize in advance for not being properly informed. ( Also i'm unfortunatly not really into the debugging or coding side of GTK and Rust, so i might not be of good help. )
This should actually not be an issue right now, but an info if related to the pr.
If someone happend to have the Battle.net Client from Blizzard installed via Bottles ( I didn't test Lutris ) and you open it, in my case the system-tray icon is shown in it's own window ( Currently using dwm ).
Also it is functional and you can close the window without any issues.

I think this might be a thing for another pr, or it's some setting on my side, but somebody may be better in deciding.
Also i can confirm @elken s point, that updates aren't happening. Saw that with discord ( messages ) and blueman.
Otherwise it's working perfectly for me so far. :)

If someone happend to have the Battle.net Client from Blizzard installed via Bottles ( I didn't test Lutris ) and you open it, in my case the system-tray icon is shown in it's own window ( Currently using dwm ).
Also it is functional and you can close the window without any issues.

So for those my understanding is they're a different kind of indicator that isn't handled yet, this GNOME extension handles icons from WINE fine but since moving away I have also noticed the same using waybar's tray.

So for those my understanding is they're a different kind of indicator that isn't handled yet, this GNOME extension handles icons from WINE fine but since moving away I have also noticed the same using waybar's tray.

Ah okay, correct me if i'm wrong here pls.
If i see correctly gnome-shell-extension-appindicator builds upon libappindicator, this pr builds upon libdbusmenu.
So, this may indeed be something for another pr, but could later on be connected to the widget provided here through?!

So for those my understanding is they're a different kind of indicator that isn't handled yet, this GNOME extension handles icons from WINE fine but since moving away I have also noticed the same using waybar's tray.

Ah okay, correct me if i'm wrong here pls. If i see correctly gnome-shell-extension-appindicator builds upon libappindicator, this pr builds upon libdbusmenu. So, this may indeed be something for another pr, but could later on be connected to the widget provided here through?!

libappindicator is a library that applications can use to create a tray icon. it implements the app side of the StatusNotifierItem protocol. we implement the tray side of the protocol (StatusNotifierHost, in their terminology), but not using any third-party library.
libdbusmenu works "on top" of the StatusNotifierItem protocol to provide support for menus (both on the application side and the tray side). it's not responsible for the icon itself, only the menu.
there's also an older protocol called XEmbed, but it's not used much anymore. as such, i'm not gonna support it in this PR

Thanks for the clarification. ☺
I think this is also a valuable good to know for people that might read the thread somewhat later.

The icon looks blurry on hidpi screen, ig scaling is not implemented yet?

Hi, first of all I want to say thank you so much for bringing this functionality that's the only thing keeping me still on waybar, now I wanted to ask if there's a way to left click icons to show/hide them:
https://github.com/elkowar/eww/assets/101421807/a018a57b-4616-4a7a-8a1a-7aa5a1ba1870

This PR works well for me, the background is just transparent on right click.

The icon looks blurry on hidpi screen, ig scaling is not implemented yet?

Same issue here, and maybe support custom icon sort in future? I got fcitx nm-applet and blueberry execute at start up in order, but it had different ordered tray after every reboot.

I really like this feature and am using it now.
I also encountered some problems, what I want to know is how is the current progress, I can't wait to use it

i'll try fix the remaining things mentioned in the review in the coming days :) sorry i've been kinda missing

I noticed that there was some work done on the flake, however it still fails citing the missing dbusmenu-glib-0.4 package as mentioned prior in the PR.

@skiletro see https://github.com/elkowar/eww/pull/743#issuecomment-1528710727

@eclairevoyant @skiletro for now I've added it to the overrideAttrs in flake.nix. Once nixpkgs includes it (probably when eww next does a release), we can remove it.

@ralismark this PR could be merged or it is needed to wait for the stuff in the prev message is included in nixpkgs?

As I understand this, the flake takes account for building eww as a "non-release" version. When eww has a new release, those overrideAttrs can be removed.

@elkowar the current stable latest release came out on Sept. 2022. Is there a date for the next release?

Well there are many open pull requests maybe when more get merged

Well there are many open pull requests maybe when more get merged

Currently, from the release date of the latest release until the current day, 26 PRs have been merged and 47 commits applied.

This is something I've been wondering myself. Maybe milestones would be useful?

eagerly waiting for this feature!

Hi everyone, I'm currently attempting to build this PR in nixos but have came across an error compiling:
error[E0635]: unknown feature `hash_extract_if`
 --> crates/eww/src/main.rs:6:12
  |
6 | #![feature(hash_extract_if)]
  |            ^^^^^^^^^^^^^^^

error[E0635]: unknown feature `extract_if`
 --> crates/eww/src/main.rs:2:12
  |
2 | #![feature(extract_if)]
  |            ^^^^^^^^^^

error[E0599]: no method named `extract_if` found for struct `std::collections::HashMap` in the current scope
   --> crates/eww/src/widgets/widget_definitions.rs:132:62
    |
132 |     let contained_deprecated: Vec<_> = bargs.unhandled_attrs.extract_if(|a, _| deprecated.contains(&a.0 as &str)).collect();
    |                                                              ^^^^^^^^^^ method not found in `HashMap<AttrName, AttrEntry>`

This is my override:
environment.systemPackages = with pkgs; [
    (eww-wayland.overrideAttrs (drv: rec {
      version = "tray-3";
      src = fetchFromGitHub {
        owner = "ralismark";
        repo = "eww";
        rev = "a82ed62c25ba50f28dc8c3d57efe440d51d6136b";
        sha256 = "sha256-vxMGAa/RTsMADPK4dM/28SV2ktCT0DenYvGsHZ4IJ8c=";
      };
      cargoDeps = drv.cargoDeps.overrideAttrs (lib.const {
        inherit src;
        outputHash = "sha256-YN3c0lv886wrl+6zyoWCB6BlRPdpKGHZt+I3KZZFsqg=";
      });
      buildInputs = drv.buildInputs ++ (with pkgs; [ glib librsvg libdbusmenu-gtk3 ]);
    }))
  ];

As a nixos and rust newbie, I thought I'd leave this here in case it's related to the flake on this repo and needs to be looked into. Otherwise if it's a problem with my own config let me know and I'll remove this comment as to not get in the way.

On the doc it says:

This is a nightly-only experimental API. (extract_if #43244)

It might very well be that the package doesn't build with nightly, so you need to override that as well.

If that's the case, then shouldn't this repo's flake also build with nightly?
How would I go about overriding that locally? I can't seem to find info about it anywhere

ERROR eww::widgets::systray > could not initialise dbus connection for tray: I/O error: No such file or directory (os error 2)
I do have dbus service running too

If that's the case, then shouldn't this repo's flake also build with nightly? How would I go about overriding that locally? I can't seem to find info about it anywhere

As far as I can see this PR changed the Cargo.lock file so you can't just use the original Cargo.lock with new Hash and expect it to work. To import the new Cargo.lock file look at how it is done in the flake. There is a nix function in nixpkgs for that.

If that's the case, then shouldn't this repo's flake also build with nightly? How would I go about overriding that locally? I can't seem to find info about it anywhere

If you're using the overlay it will use your nixpkgs version's rust nightly, which is likely not up-to-date. Use the package directly with eww-wayland-input.pacakges."${system}".default.

Hiya, I just added dynamically updating icons here: https://github.com/ralismark/eww/pull/4
Seems to work great :)

Just wanted to drop a note to say that it's working out of the box for me right now with no fuss so far.

No news about this PR?

No news about this PR?

https://github.com/elkowar/eww/pull/743#issuecomment-1686270884

How would one go about making the icons appear vertically? I've tried the pack-direction btt/up without any luck

For me, (systray :pack-direction "ttb") seems to work @SomeSalmon

Oh goodness, thank you so much I had an absolute brain fart. It seems I used an underscore instead of a hyphen for some reason.

I think that's because it is like that in the initial message here, I also had the same issue, but luckily the good error message in the log helped out :)

@elkowar could you review again? in case you didn't see that i requested a re-review ;)

FWIW, I've been running the dynamic icons PR for a few days without issues

Something that would be really helpful with this is examples of how to style it. I've seen in the inspector that items with submenus have some arrow element added, but have been failing to make anything display there.

pitching in to ask the question if it is possible to not have a fixed minimum width when the tray is being used,
at least in a bare config i can set my width to be whatever i want and when using the systray widget it seems to not be able to go lower than 25pixel in the height of a window, which seems counterproductive when you can modify the icon size

(defwidget bottom [screen]
  (box :orientation "v"
       :valign "end"
       :space-evenly true
       :spacing "5"

    (systray :class "tray" :icon-size 18 :pack-direction "ttb")

    (time)))

.tray {
  all: unset
}

Seems to do the trick for me @Souliboi

This PR works well for me, the background is just transparent on click.

How to fix this issue?

This PR works well for me, the background is just transparent on click.

How to fix this issue?

It looks like that when you have all: unset in your css/scss file. In that case you have to style it yourself. You can use menu and menuitem selectors to do that.
You also can use eww inspector to check which selectors to use to style specific elements.

Any pending issues? Life without a tray is hard.

Great job with this try.
I've noticed the following behavior:
With this systray the notification popup on top of icons doesn't work. Please look at the screenshot below where the WhatsApp client "WhatSie" for example doesn't show the notification count. The upper is waybar

Additionally I noticed that clicking on an icon doesn't execute the default action for the applet. For example on waybar systray if I click on WhatSie icon it opens the client window (and if I click again it closes the window), in this tray it opens the menu and I have tho select the option to show the window.

@mamaraddio that's likely using dynamic icons, which is supported by a separate PR: https://github.com/ralismark/eww/pull/4

@mamaraddio that's likely using dynamic icons, which is supported by a separate PR: ralismark#4

Great!
Will wait for this to be merged

Hey! Is there an update on whenever this will be merged? I've used both this PR and https://github.com/ralismark/eww/pull/4 for months now with no issues or crashes.

it's probably going to be stale for a while as @elkowar seems to be interested in other stuff at the moment

Bit of off-topic to this PR, but is there a way to know if there are 0 tray items? If so I'd like to remove the separator from my bar if in case there's no tray icons. I'm wasn't sure where to ask about this.
I'm also not very familiar with dbus things, so I was thinking of in-built way for it. If not is there a command to know it, the length of tray items (which I wan't able to find so easily)?

Hey! Is there an update on whenever this will be merged? I've used both this PR and ralismark#4 for months now with no issues or crashes.

How are you using it? I've built eww from the tray-3 branch but it doesn't recognize the systray widget

How are you using it? I've built eww from the tray-3 branch but it doesn't recognize the systray widget

@GOKOP I had the same problem and it turned out the "normal" version of eww was still running in the background. Try killing and re-starting eww.

(merged the two open PRs and rebased onto upstream master)

Tried to build it on NixOS got the following error:
   Compiling notifier_host v0.1.0 (/build/source/crates/notifier_host)
error[E0061]: this method takes 2 arguments but 1 argument was supplied
   --> crates/eww/src/widgets/systray.rs:191:47
    |
191 |                     icon.set_from_pixbuf(item.icon(*icon_size.borrow_and_update()).await.as_ref());
    |                                               ^^^^-------------------------------- an argument of type `i32` is missing
    |
note: method defined here
   --> /build/source/crates/notifier_host/src/item.rs:89:18
    |
89  |     pub async fn icon(&self, size: i32, scale: i32) -> Option<gtk::gdk_pixbuf::Pixbuf> {
    |                  ^^^^
help: provide the argument
    |
191 |                     icon.set_from_pixbuf(item.icon(*icon_size.borrow_and_update(), /* i32 */).await.as_ref());
    |                                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Tried to build it on NixOS got the following error:

should be fixed now

Tried to build it on NixOS got the following error:

should be fixed now

confirmed it is fixed

This seems to work fine, though i do get a lot of gtk errors in my logs on reload:
(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_set_accel_path: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_set_accel_path: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_set_accel_path: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

(eww:39868): Gtk-CRITICAL **: 19:17:25.454: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed

how can i change the icon size?

how can i change the icon size?

@MatheusTT use the icon-size property, which takes an integer

Hello, currently, are we able to style the icons, such as spacing between different tray icons? How do I hide icons that are displayed as a  "no symbol" (red line across circle)?

Just noticed that the --arg eww cli parameter isn't handled in this branch. When using the official elkowar's eww I used to open my bar with some args:
eww open bar --arg monitor=0

But on this branch the argument isn't recognized:
error: unexpected argument '--arg' found

Seems weird to me as this branch isn't behind any commit on the master branch.

Hello, currently, are we able to style the icons, such as spacing between different tray icons?

if building with my pr https://github.com/ralismark/eww/pull/6 you can set the spacing property.

Hello everyone, how are you, I would like to know about the progress of this feature, it is something that I really hope for, I have recently been building my distro that has an eww as a "dock" by default, and this feature is greatly missed, I would like to know how I can help in the development of this infamous feature

@n1ckisthereu it's pretty much complete (and you can just use my branch if you want to use this feature right now), we're mainly just waiting for this PR to be reviewed and merged
on the technical side, if you want to contribute code the most useful thing would probably be tests, since there aren't really any right now

Good Ralis, but it seems that the master has a problem, well my distro is based on arch with hyprland, and when I try to use the version that is on the master, or tray-3 which is based on the same, I have the image problem below, it looks like it is duplicating the "bar" and one has a bugged radius, the 0.4.0 tag works but I couldn't implement its branch in it...
Well, I really want to see this working, I'll try to work on the tests.

(Related to previous comment)
Good evening everyone, sorry to be dealing with this issue in this thread, I believe this is not a problem with the PR but with the master branch, I didn't have much time to work on these topics today, I tried a lot to correct them but without success, I'm here looking for a solution. a light to make this work, I didn't see anyone portraying this problem, I use hyprland with arch, I tried a clean install from master, but without success, I really need to use the tray-3 branch. (If this comment is inappropriate, I will remove it immediately)

AUR?

I tried all ways, AUR, build etc, the 0.4.0 tag works normally

Yes, i try, but not working :(

I'd a problem when I trying to install from tray-3 branch or even master branch, the same problem from @n1ckisthereu, I use hyperland and ArchLinux.

I encountered an issue while attempting to install from the tray-3 branch, facing the identical problem as. I am using Hyperland and running ArchLinux.

Encontrei um problema ao tentar instalar a partir da ramificação da bandeja 3. Estou usando o Hyperland e executando o ArchLinux.

I encountered an issue while attempting to install from the tray-3 branch. I am using Hyperland and running ArchLinux.

Hello guys, good morning, new noticies? i need open a bug for this?

Menus are transparent and non functional on arch+wayland(hyprland/labwc)

@googl267 transparency may be due to your style. The menu only works if you use the same mouse button in the menu as the one used to open the menu. These are known and (for now) accepted issues. Could you confirm whether this is a different issue?

@Fxxxlei And regarding the problem I mentioned above, do you have any knowledge about it?

@googl267 transparency may be due to your style. The menu only works if you use the same mouse button in the menu as the one used to open the menu. These are known and (for now) accepted issues. Could you confirm whether this is a different issue?

ah so sorry! The button issue is indeed from right clicking the icon and left clicking the menu. Transparency can be fixed by using *{ } so I'll have to find its name to theme it separately. Wish the menu could use the same class param as the tray but again sorry for my ignorance

Hey @ralismark! I'd really love to finally get systray support merged :3 I've looked through the code, and this already looks very clean! There are a few TODOs, and some commented-out code where I'm not sure how relevant it is, but otherwise, even if this isn't yet completely perfect, I'd say functionality-wise this might be close to ready for merge -- additional extensions can still happen later on.
What do you think?
I'd also appreciate if there was a tiny bit more of a general structural explanation, maybe in the notifier_host crate. All of this is quite dense code that probably makes perfect sense if one has studied the underlying Glib APIs and specs, but without that preexisting knowledge, I find it quite hard to navigate (basically, because I just don't intuitively know where the components fit into one another. Maybe even a small diagram could help here?
Would love to get your input, maybe we can finally get this merged soon!

@elkowar Thanks for having a look!

I'd also appreciate if there was a tiny bit more of a general structural explanation

You're right that notifier_host needs better documentation, I'll add that when I can. There's also some generated code files that I haven't documented properly.

There are a few TODOs

Yeah, these definitely need looking into.

some commented-out code

Is there any beyond con and name for DBusSession? I think those can be removed at least.

To be honest, with how long it's been I've kinda lost motivation to maintain this PR. 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.

@elkowar Thanks for having a look!

I'd also appreciate if there was a tiny bit more of a general structural explanation

You're right that notifier_host needs better documentation, I'll add that when I can. There's also some generated code files that I haven't documented properly.

There are a few TODOs

Yeah, these definitely need looking into.

some commented-out code

Is there any beyond con and name for DBusSession? I think those can be removed at least.
To be honest, with how long it's been I've kinda lost motivation to maintain this PR. 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.

Please do not adandon this PR, it adds a a crucial feature to eww. It would be such a waste that it ends up not merged:(

@elkowar Thanks for having a look!

I'd also appreciate if there was a tiny bit more of a general structural explanation

You're right that notifier_host needs better documentation, I'll add that when I can. There's also some generated code files that I haven't documented properly.

There are a few TODOs

Yeah, these definitely need looking into.

some commented-out code

Is there any beyond con and name for DBusSession? I think those can be removed at least.
To be honest, with how long it's been I've kinda lost motivation to maintain this PR. 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.

I agree with the comment above. Tray is the only reason why I don't use my version of the system bar and rewrite all the modal windows I need on eww. I'd appreciate it if you'd finish it.

Don't worry, I'm not abandoning this.

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 @EzequielRamis, 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. :)

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!

@elkowar can you also review https://github.com/ralismark/eww/pull/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

@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

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

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.

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

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

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!


Update overview.adoc

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/do-doc-build


⚠ Fetchers has degraded performance

In 40cb354, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 1129 ms

Resolved: Fetchers performance has improved in eca6417.


PostgreQueryBuilder.distinct_on is not a function

It seams that distinct_on no longer works as explained in #356
$ python
Python 3.8.2 (default, May 13 2020, 15:52:37)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pypika import PostgreSQLQuery
>>> q = PostgreSQLQuery.from_('customers').select('id', 'fname', 'lname', 'phone').distinct_on("fname").orderby("fname", "id")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'Field' object is not callable

Further investigation shows:
$ python
Python 3.8.2 (default, May 13 2020, 15:52:37)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pypika import PostgreSQLQuery
>>> type(PostgreSQLQuery.from_('x').distinct_on)
<class 'pypika.terms.Field'>

Oh my... I finally figured it out. For some reason I was still running PyPika 0.27.2. I recently reinstalled it but didn't realize it was using a pinned version. :facepalm:
Using the correct version of PyPika it works now. :+1:

for anyone encountering the same issue, in my case, i got the same error, but this was because i was using ppk.Query.from_('x').distinct_on and not the postgresql dialect: ppk.PostgreSQLQuery.from_('x').distinct_on.
DISTINCT ON is only available in postgresql.


[Question] Closure-based API for zero-copy

The current read function of of the traits takes in a buffer, requiring an additional buffer to be allocated
Would it make sense to add something along the lines of
fn read_with<F>(&self, socket: &mut Self::TcpSocket, f: F) -> nb::Result<usize, Self::Error>
where
    F: FnOnce(&[u8]) -> usize,

Making it easier to use with socket buffers of the kind used in smoltcp, without the additional clone? https://github.com/smoltcp-rs/smoltcp/blob/bdfa44270e9c59b3095b555cdf14601f7dc27794/src/socket/tcp.rs#L752

Maybe even
/// Call `f` with a slice of octets in the receive buffer, and dequeue the
/// amount of elements returned by `f`.
///
/// If the buffer read wraps around, the second argument of `f` will be
/// `Some()` with the remainder of the buffer, such that the combined slice
/// of the two arguments, makes up the full buffer.
fn read_with<F>(&self, socket: &mut Self::TcpSocket, f: F) -> nb::Result<usize, Self::Error>
where
    F: FnOnce(&[u8], Option<&[u8]>) -> usize,

It would also be desirable to have a write equivalent of this.
These types of functions allow us to create zero-copy abstractions for higher level protocols, such that we can write data directly into the outbound FIFO or (potentially) read entire packets directly from the incoming FIFO.

Could we get something drafted up for zero-copy usage?
It's great that this is released now, but i still lack the zero-copy API to be able to replace my local fork with the crates.io version. On top of that i think any serious networking abstraction should provide a way of using it in a zero-copy way.

The main complication I see is that not all network stacks will support zero-copy abstractions. Take for example a TCP stack using the W5500. The only way to "write" to the socket is to perform a SPI transaction to the W5500. The SPI transaction requires the original buffer, so the current API works well for this.
However, other network stacks, like smoltcp, can provide a direct buffer to write into (with modifications, smoltcp can't do this currently to my knowledge. See https://github.com/smoltcp-rs/smoltcp/issues/359).
If we were to force all users to supply the read_with() API (closure-based), then the W5500 network stack implementation would have to maintain some internal [u8] buffer that it could provide to the read_with() API and then write out to the W5500. In reality, this just offloads the explicit buffering to the stack impl (which isn't a bad thing). However, even stacks like smoltcp do not yet support direct-write to the underlying TCP socket data without buffering yet, so the value added isn't present for these two stacks. (It feels a bit like the chicken and the egg problem here)

I don't necessarily think we need to force anyone to implement it.
Two ideas come to my mind

Add a default implementation for one using the other (might not actually be possible, due to allocation issues?)
Make the zero-copy an optional extension trait? (This does break the one impl fits all abstraction though?)

I don't necessarily think we need to force anyone to implement it.

I think if we propose it into the trait, that's essentailly what we have to do.

Add a default implementation for one using the other (might not actually be possible, due to allocation issues?)

I think we can make a default implementation and require the user to specify some generic_array::ArraySize? I'm not entirely sure if this is possible - I can poke around with this - it's an interesting idea.

Make the zero-copy an optional extension trait? (This does break the one impl fits all abstraction though?)

I think we should make all effort to avoid fractioning/splitting the traits, otherwise the abstraction breaks down and it becomes less useful.

I think we can make a default implementation and require the user to specify some generic_array::ArraySize? I'm not entirely sure if this is possible - I can poke around with this - it's an interesting idea.

That would be awesome! Hit me on matrix if i can help with anything?

I've added a sample for a TCP stack in https://github.com/ryan-summers/embedded-nal/blob/feature/closure-read-writes/src/lib.rs#L29-L106
The main downside of a default implementation is that we need to break a read() into distinct actions:

Acquire data from the socket (but do not dequeue it)
Allow the user closure to process N bytes
Dequeue N bytes from the socket, where N <= bytes_available

This means that stacks must support reading without dequeuing, which isn't always possible. For example, this is not supported by std::net::TcpSocket because it implements the Read trait.

I can live with this from my end, though I agree on the downsides of the approach. Can't think of anything better, that still would allow for the functionality though.
One thing that comes to mind with this is how to handle using a circular socket buffer with this?
Example:
I am using this API for zero-copy decoding of MQTT packets, meaning i will only ever commit if there is a full MQTT packet in the buffer. let size = network.read_with(socket, |buf| clone_packet(buf, packet_buf).unwrap_or(0))where the result is the number of bytes copied to packet_buf (or 0 if there is still not a full MQTT packet available).
I can then in-place decode the packet_buf to a structured MQTT packet containing references into the memory buffer.
The downside being, that if the packet is actually in my circular buffer, but half of it is wrapped around, i would never be able to read it.

The downside being, that if the packet is actually in my circular buffer, but half of it is wrapped around, i would never be able to read it.

That's why I mentioned https://github.com/smoltcp-rs/smoltcp/issues/359 - this closure-based approach will never work if a network stack uses a ring buffer as the underlying storage mechanic because there's always the possibility that the packet isn't contiguous. If this is the case, it will always need to be copied into memory such that it would then be contiguous.

That makes sense! Perhaps i should look into replacing my socket buffer implementation with a bip based version.. Perhaps based on bbqueue

I would be quite happy with https://github.com/ryan-summers/embedded-nal/blob/feature/closure-read-writes/src/lib.rs#L29-L106
Could you maybe open a draft PR, so we can get some eyes and comments on the approach?

Update

That makes sense! Perhaps i should look into replacing my socket buffer implementation with a bip based version.. Perhaps based on bbqueue

It seems like bbqueue would not actually solve my issue here? It would give me a contiguous piece of memory for writing, but does not set such guarantees when reading?

Relevant info: BBqueue has merged this PR: https://github.com/jamesmunns/bbqueue/pull/77
Adding essentially the same feature that i was originally asking here..

Maybe a special trait that implementers don't have to provide like we currently have for Client/Server traits would be best here.

The problem is that if we make a separate trait, we have now divided the ecosystem. If a library required a zero-copy trait, then it would not be usable with stacks that don't have zero-copy support (e.g. smoltcp). Essentially, rust semantics don't allow for a logical OR of implementations, so we're restricted in only exposing a single trait for stacks.

Maybe forcing implementers to add zero-copy methods isn't so bad after all. Thinking about it, I think it may be possible for stacks like smoltcp to have a fake zero-copy interface that does copy in the background. This would obviously be less efficient, but would still work.

That's a potential avenue as well - it would be very reasonable to add zero-copy APIs, but then force the implementation of the traits to internally buffer if the underlying stack doesn't support zero-copy write/read. That would allow the individual network stack implementation to tailor the buffer size to their specific use case as well.

I think that is the way i would like to see this go.. Maybe we can even provide some sensible default implementation that does copy?

The downside being, that if the packet is actually in my circular buffer, but half of it is wrapped around, i would never be able to read it.

That's why I mentioned smoltcp-rs/smoltcp#359 - this closure-based approach will never work if a network stack uses a ring buffer as the underlying storage mechanic because there's always the possibility that the packet isn't contiguous. If this is the case, it will always need to be copied into memory such that it would then be contiguous.

Recently I saw the core::ops::Index trait, could this allow an arbitrary backing buffer which implements the index operation?
If I understand correctly, maybe this would allow for either a slice or circular buffer at the implementation's choice?

AFAIR that depends on whether indexing by slices is allowed. If so, indexing by 0..end still needs to produce contiguous memory. Indexing for by individual bytes makes scattered backends easy, but is very limiting (and probably inefficient, eg feeding single bytes to serde) in use.
A middle ground may be rope-like data structures, but I have no experience with them in Rust.


Boilerplate: Update to 76942d7dbb2425eb028459cfc5f88e92b6d4d504

This is a straight update of boilerplate, with a make generate

#163 needs to merge first

/retest

/lgtm


Link for personal bookings

Hi,
The link to access personal bookings was removed " https://outlook.office.com/bookwithme/me".
Also, I am having permission error after I enable personal bookings org wide commands. I have waited for almost 1 day and still I am having this issue.

Any advise would help.
Thank you!
https://docs.microsoft.com/en-us/microsoft-365/bookings/bookings-in-outlook?view=o365-worldwide#feedback

@placido-iv Thank you for your feedback. This seems to be an issue either with the tenant or the associated mailbox. I'd recommend you contact Microsoft support so the support engineer can fix the issue.
You can reach out to the support team via the need help section on the M365 Admin center.
Hope this helps!
Thanks
Sri

@msbemba Thank you very much for the contribution and sharing this explanation. @placido-iv Hope this comment is helpful for you. Considering the nature of the issue, as advised, please open a service ticket in your tenant and follow with them for the resolution. We proceed to close it as here we are limited to documentation fixes and improvements only.
We will be very happy if you can share the outcome or resolution with us if you see documentation update is required. We will certainly update this documentation with that valuable information. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Please Add Resource Move Considerations

Hi,
Under the section "Considerations before applying your locks", please add impact of Read only lock on Resource Move.
For example

A read-only lock on a resource group that contains a virtual machine prevents users from moving the the VM out of the resource group.
A read-only lock on a resource group prevents users from moving any new resource into that resource group.

Regards
Shridhar

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4e7af209-7240-dd2a-7130-e7fb3143986a
Version Independent ID: a653b0d1-877d-09f7-17fa-11bf06c37cc9
Content: Protect your Azure resources with a lock - Azure Resource Manager
Content Source: articles/azure-resource-manager/management/lock-resources.md
Service: azure-resource-manager
Sub-service: management
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@ssrinivasn-edu Thanks for your comment! We will review and provide an update as appropriate.

@ssrinivasn-edu We have verified and updated the document as required. The update will go live in less than 24 hours. Thanks again!

@ssrinivasn-edu Your name would appear in the list of contributors if you create a pull request and if its gets merged by reviewers. For more information, please check this page.


MapHub is not present on ApplicationBuilder but on EndpointRouteBuilder

MapHub<> extension method is not present on IApplicationBuilder anymore, instead its on IEndpointRouteBuilder
Even in source code you do not have any other extensions than to IEndpointRouteBuilder

@dotnet-policy-service agree

@dotnet-policy-bot agree

See https://github.com/dotnet/AspNetCore.Docs/pull/26136

@BrennanConroy ok, as long as you use the new format.
thanks, this can be closed.


Update API Docs for Table Extension & Model Calculations

Updating API docs to account for Table Extensions and the Model Calculations.

merging doc updates


CLOUDSTACK-8231: Fixed UI empty drop-down list for LB rules

It seems that getLbAlgorithms() function must be called if context is "undefined".  If context is defined then function returns empty list. That is why drop-down menu is also empty when I add new LB rule.

LGTM. Thanks @vadimkim


[SPARK-20862][MLLIB][PYTHON] Avoid passing float to ndarray.reshape in LogisticRegressionModel

What changes were proposed in this pull request?
Fixed TypeError with python3 and numpy 1.12.1. Numpy's reshape no longer takes floats as arguments as of 1.12. Also, python3 uses float division for /, we should be using // to ensure that _dataWithBiasSize doesn't get set to a float.
How was this patch tested?
Existing tests run using python3 and numpy 1.12.

Test build #77275 has started for PR 18081 at commit b536160.

Test build #77275 has finished for PR 18081 at commit b536160.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77275/
Test PASSed.

Merged build finished. Test PASSed.

LGTM
Do we have similar cases in MLlib?

To test it in jenkins might need a specified numpy version, but the code change looks ok.

Dumb question but this still works in Python 2.6+ right?

I think so.

Nit: usually we won't specially tag it is a BugFix in the title.

@srowen floor divide has been in python since 2.2, https://www.python.org/download/releases/2.2/.

@viirya I was running python tests for pyspark-ml and pyspark-mllib and this was the only place where the python3/numpy interaction caused a test failure. There might be other places where floor int division might be preferable to float division, but if they exist they're not causing any of the tests to fail.

@MrBago Yeah, after a quick scan, seems other reshape usage in MLlib are ok.

LGTM, merged into master/branch-2.2/branch-2.1. Thanks for all.


Validate digestion space

Rachel observes that when we digest our protein database, we see that 90+% of proteins contain a unique peptide (a peptide that can be a digestion product of only that protein). This number is consistent across proteases. Experimentally, this number is only 50%.
Are we digesting our database correctly? Or are shared peptides simply more abundant and thus more likely to be observed?

Wasn't the 90% number calculated using up to 2 missed cleavages? We mostly observe no missed cleavages, which may have more overlap. Did she include proteolytic cleavages? More information about the digest is needed. I agree that shared peptides are more likely to be observed, as they are more abundant by a factor of the number of shared proteins, but the discrepancy seems high.

I think she tried it with no missed cleavages and got that ~90% number

What percent of peptides are unique? This might be a closer answer to our experimental observation, because we don't get full coverage of every protein that we identify. This will need to be calculated on a length basis, as shorter peptides will rarely be unique and longer peptides are much more likely to be unique.

what unit tests do we have specifically for digestion? I saw different digestions used in classic and modern search tests, but only with simple peptides. I didn't see anything really to get to all the possibilities of digestion.  Also didn't see test for each of the different proteases.

For Trypsin using Uniprot database that contains 71,785 proteins with minimum peptide length of 5 and no max set

2 missed cleavages: 89.42% of proteins contain at least 1 unique peptide
no missed cleavages: 77.78% of proteins contain at least 1 unique peptide

Additionally, for the same set of conditions:
2 missed cleavages: 27.33% of all peptides are unique (not excluding duplicates in total count)
0 missed cleavages: 25.04% of all peptides are unique (not excluding duplicates in total count)

Can you clarify the minimum and maximum length allowed? ie the peptide "K" is ~6% of all peptides, but is never observed in proteomics.

The minimum peptide length is 5 and I have not set a maximum length allowed.


Can't run mrsegmentator with batchsize!=1 and assigned fold

I have a directory path data_path with some nifti file in it, and use
mrsegmentator  --input "$data_path" --outdir "$output_path"
After reading 8 images, and predicting them.
it raise an error as follow:
Done with image of shape torch.Size([1, 789, 233, 333]):

Predicting image of shape torch.Size([1, 773, 233, 333]):
perform_everything_on_gpu: True
Traceback (most recent call last):
  File "xxx/mrseg_venv_2/bin/mrsegmentator", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "xxx/mrseg_venv_2/lib/python3.12/site-packages/mrsegmentator/main.py", line 37, in main
    infer(
  File "xxx/mrseg_venv_2/lib/python3.12/site-packages/mrsegmentator/inference.py", line 89, in infer
    segmentations = predictor.predict_from_list_of_npy_arrays(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "xxx/mrseg_venv_2/lib/python3.12/site-packages/nnunetv2/inference/predict_from_raw_data.py", line 329, in predict_from_list_of_npy_arrays
    return self.predict_from_data_iterator(iterator, save_probabilities, num_processes_segmentation_export)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "xxx/mrseg_venv_2/lib/python3.12/site-packages/nnunetv2/inference/predict_from_raw_data.py", line 361, in predict_from_data_iterator
    proceed = not check_workers_alive_and_busy(export_pool, worker_list, r, allowed_num_queued=2)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "xxx/mrseg_venv_2/lib/python3.12/site-packages/nnunetv2/utilities/file_path_utilities.py", line 103, in check_workers_alive_and_busy
    raise RuntimeError('Some background workers are no longer alive')
RuntimeError: Some background workers are no longer alive

And, if I assign fold model with --fold 1, it will stack after  predicting.
showing: Done with image of shape torch.Size([1, 805, 233, 333]):

This might be caused by an out of memor error. Can you try to run:
mrsegmentator  --input "$data_path" --outdir "$output_path" --split_level 2

Works for me.
However, when I use --split_level 2, it seems to set the batch size to 1. I've checked my memory usage and GPU memory usage, and neither is maxed out. Is there a way to see specific error outputs? Also, do you know of any faster inference methods, as it currently takes too long to process a single image when I run mrsegmentator --input "$data_path" --outdir "$output_path" --split_level 2

Thanks for your detailed response.


fix: Fix temperature range to include 82 degrees as max

I changed the temperature_range from range(62, 82) to range(62, 83) so the range includes 82 degrees, which is the max temp setting supported by the USA api prior to changing to HIGH. As it is currently, when the car reads HIGH, the api reads 81, which is incorrect. In reality even 82 is technically incorrect, as 82 comes before HIGH, but I think it's reasonable to cap the display to that in order to avoid mixing numbers and strings (if one were to try and actually display "HIGH").

Thanks for this!

Thank you for all the hard work with this outstanding integration!


Add performance bar to display slow Matrix requests

Is your feature request related to a problem? Please describe.
Since we're relying on the backing Matrix homeserver to retrieve information to display, this can lead to timeouts with no visibility on what part is being slow to respond.
Related to:

https://github.com/matrix-org/matrix-public-archive/issues/9

Describe the solution you'd like
Add a performance bar (inspired by GitLab) that shows off the timings of the homeserver requests to see where all the time was sunk.

It would be nice to have the data itself be a standard like OpenTelemetry to keep track of spans across the app, https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/
Additional context
Instead of running into 504 Gateway timeouts of the infrastructure, we should probably also opt to respond 5 seconds before the timeout with just the performance bar results so they are always visible when the app is overall too slow to respond at all.

As a step towards this goal, since https://github.com/matrix-org/matrix-public-archive/pull/27, we have OpenTelemetry tracing in the app and you can find the spans for the Matrix requests that back every request to the archive by looking at window.tracingSpansForRequest in the devtools for any page loaded.
Also when the app times out, it will give a data dump of what was slow (window.tracingSpansForRequest is still available):

This should also be useful for users on a mobile proxy browser (UC/Opera Mini) as those also time out after 5 seconds. I think most web crawlers also time out after 5 seconds (they apply the same timeout when running JavaScript as well).


Storefront API scope unauthenticated_read_product_inventory not available via checkout UI extension

Please list the package(s) involved in the issue, and include the version you are using
"@shopify/ui-extensions": "2023.10.x",
"@shopify/ui-extensions-react": "2023.10.x"

Describe the bug

It is impossible to retrieve the productVariant.quantityAvailable field via the Storefront API within a checkout ui extension. The graphQL api always returns a null value for quantityAvailable and the error message:
Access denied for quantityAvailable field. Required access: unauthenticated_read_product_inventory access scope.
Steps to reproduce the behavior:

Try to make a query that includes a request for productVariant.quantityAvailable.
In the graphQL response, the quantityAvailable field is always null, and there is an error saying that I need access to the unauthenticated_read_product_inventory scope.

Expected behavior

The quantityAvailable field should return an integer - how many of that product is available.
Screenshots

My query code in checkout-ui:

My app scope request:

My app permissions in partner dashboard:

App permissions in app installed in test store:

Additional context
This is affecting other users as well, I have found a few posts about it on the shopify forums such as:
https://community.shopify.com/c/extensions/is-there-any-way-to-add-new-access-scope-to-checkout-ui/td-p/2141674

+1 would like it very much as well.

+1 would love to see support for this

Hello guys,
Is it the same with
Access denied for customer field. Required access: unauthenticated_read_customers access scope. ?
unauthenticated_read_customers access scope is already added to my app but if Shopify does't support some access scopes...  and we don't know which ones, it's really difficult to debug and develop...


Dependencies are removed

Unused dependencies located in build. Gradle (Module: app) file have been deleted.
Fixes #{3128} {Go through all our existing dependencies to see if we should keep or remove them}
I have looked through existing dependencies located in build. Gradle (Module: app) file to see if they should be deleted or kept. I have commented on each one by one and have checked whether it still works.
Tested Debug on Nexus 5X with API level 27.
Tested Debug on Pixel 2 with API level 19.

Codecov Report

Merging #3141 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #3141   +/-   ##
======================================
  Coverage    4.66%   4.66%
======================================
  Files         264     264
  Lines       12400   12400
  Branches     1057    1057
======================================
  Hits          579     579
  Misses      11777   11777
  Partials       44      44

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eeeea47...4d23a6a. Read the comment docs.


Unrendered markdown in article

Link to article:
https://docs.microsoft.com/en-us/windows/desktop/WinAuto/uiauto-uiautomationoverview
Problem:
Unrendered markdown.
[!Note] The functions described in [Deprecated Control Pattern Functions](uiauto-entry-cpfunctions.md) and [Deprecated Node Functions](uiauto-entry-uianodefunctions.md) are deprecated. Instead, client applications should use the UI Automation COM interfaces described in [UI Automation Element Interfaces for Clients](uiauto-entry-uiautoclientinterfaces.md).

@ginami Can you find author to modify it?

Hi @SujeathPareddy  -- thank you for your feedback! I think this problem is a result of the migration process; I'll confirm that is on our list of known migration issues.

Hi @SujeathPareddy -- this issue is now fixed. Thanks again for bringing it to our attention.

Welcome!


updated rng guide

updated rng guide

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (2c7d7cd) to head (370a60f).
Report is 16 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #3912       +/-   ##
==========================================
- Coverage   60.43%   0.00%   -60.44%
==========================================
  Files         105      97        -8
  Lines       13263   12862      -401
==========================================
- Hits         8015       0     -8015
- Misses       5248   12862     +7614

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Arango becomes unresponsive and needs restarts after a while

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 2.8
[ ] 3.0
[x] 3.1 - Using 3.1
[ ] 3.2
[ ] 3.3
[ ] self-compiled devel branch

Mode:

[ ] Cluster
[x] Single-Server  - Single Server

Storage-Engine:

[ ] mmfiles
[x] rocksdb

On this operating system:

[ ] DCOS on

[ ] AWS
[ ] Azure
[ ] own infrastructure

[ ] Linux

[ ] Debian .deb
[x] Ubuntu .deb
[ ] SUSE   .rpm
[ ] RedHat .rpm
[ ] Fedora .rpm
[ ] Gentoo
[ ] docker - official docker library
[ ] other:

[ ] Windows, version:
[ ] MacOS, version:

this is an AQL-related issue:
[x] I'm using graph features
I'm issuing AQL via:

[ ] web interface with this browser:  running on this OS:
[ ] arangosh
[x] this Driver:

I've run db._explain("<my aql query>") and it didn't shed more light on this.
The AQL query in question is:
The issue can be reproduced using this dataset:
Please provide a way to create the dataset to run the above query on; either by a gist with an arangodump, or `db.collection.save({my: "values"}) statements. If it can be reproduced with one of the ArangoDB example datasets, it's a plus.
Foxx
this is a web interface-related issue:
I'm using the web interface with this browser:     running on this OS: Ubuntu

[x] authentication is enabled? Yes
[ ] using the cluster?
[ ] _system database?

These are the steps to reproduce:

open the browser on http://bud.gc.magicpin.in:8529
log in as buddy/Buddy_2017
use database [ ] _friendfinder
click to ...
...

The following problem occurs: [Screenshot?] - After running fine for several hours, arango just becomes jombie and stops responding on 8529 port. We are forced to restart the process which also takes very long to come back. Disk operation pattern on the server shows that there are spikes in read operation post which this problem occurs.
This is causing us down time on some of our critical features.
Instead I would be expecting: It should run smoothly all the time.

this is an installation-related issue:
Describe which steps you carried out, what you expected to happen and what actually happened.

Hi @awasta
Could you please send us an update on this ticket?

Hi @awasta,
im am closing this issue for now as we have not received any feedback for a few months.
Please feel free to reopen this issue and comment in case your problem persists.


[performance] wasm triggers

Feature request
repo: https://github.com/soramitsu/iroha2-perf/tree/featere/triggers
implement wasm trigger
triggers should run if there is a value in the event metadata
Trigger operating conditions:

When registering a new user to an existing domain
1.1. add AssetDefinitionId
1.2. make a mint of an asset in the amount of "1"
1.3. The trigger should fire if there is a string in the metadata "NewUserRegister"

Motivation
necessary for load testing purposes
Who can help?
@timofeevmd

trying to implement smart contract testing similar to the Palau project, with focus on perf scn
Precondition (at one time of test)

registerBondAssetTrigger
registerBuyBondsTrigger
registerRedeemBondsTrigger
registerBondAsset

Scenario (loop)

grantPermissionForTriggers
pause(5sec)
buySomeBondsBondAssetTrigger
pause(5sec)
triggeringBondAssetSmartContract

Postcondition (at one time of test)

redeemBondsBondAssetTrigger


Add Gravatar provider

👋 ,
this PR adds Gravatar Image generator:
https://fr.gravatar.com/site/implement/images

What is the use-case for this one? Since there is already an image provider in the repo? So i do not really see any added benefit of adding another one

you are right, an image provider already exists, but Gravatar generator can provide randomly generated pixeled avatars:

The actual Image provider calls http://lorempixel.com API which crops a big image for the requested size, for example:

I think it'll be nice to have identicon or retro avatar generator too

@CodeCooler well i dont think this needs to be in the faker core to be honest. Since we provide fake data and there is already a way to generate a fake image there is no need.
However feel free to create your custom provider and let us link to your repo instead.

@CodeCooler well i dont think this needs to be in the faker core to be honest.

I get that, and I don't really have a dog in the fight, but for what it's worth, I do think this meets a broad need that is not currently being addressed by the core faker providers:
Most of the time, I just want to generate profile avatars when seeding users for enterprise applications, and I find that more often than not, the current data source returns images that distract clients into conversations about the appearance of models, etc (case in point attached):

Sure, we could use a generic placeholder image, but this results in every profile being indistinguishable at first glance.
Generic/abstract avatars such as those provided here could be extremely handy in this use case.

@CodeCooler understand. Feel free to make a custom provider and link it to our repo that you can still use it with Faker itself and it is not part of the Faker core.

done https://github.com/ottaviano/faker-gravatar
@pimjansen, should I make a PR to add a link to my repo? thanks

Yes please 👌🏻


Remove ops from decompositions where converters exist

Description
The last removed aten.var_mean doesn't have a converter, but it's a duplicate in the list, so I remove it as well.
Partially #2665
Type of change

Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project (You can use the linters)
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas and hacks
[ ] I have made corresponding changes to the documentation
[ ] I have added tests to verify my fix or my feature
[ ] New and existing unit tests pass locally with my changes
[ ] I have added the relevant labels to my PR in so that relevant reviewers are notified

Thanks for pointing this out and the above changes!
Couple of points-

grid_sampler_2d would require some additional changes
As pointed out by you (thanks!), upsample cases do not seem to be direct enough. But removal of the above decomposition should be good for now.

Looks good to me, pending on CI