ksni

ksni copied to clipboard

Using zbus instead of the dbus crate would make it possible to use this crate without a build and runtime dependency on libdbus.

https://crates.io/crates/zbus

Also would allow for async

I just did a zbus+async port so I could stop linking libdbus: https://github.com/talonvoice/ksni/commits/zbus This is a substantial rewrite and the api / send+sync traits changed slightly, so I'm unsure about merging it as is. It's mostly done, though error handling could use more consideration and there are some TODOs / debug prints left in.

I also just noticed my branch was a few commits behind upstream, though I'd already done some work on my branch to trust the dbus remote less.

Also would love to see an async-capable version!

My port is async-capable.

My port is async-capable.

Mind providing a working example with async API in your fork? As the API changes seems to be pretty significant.

As the API changes seems to be pretty significant

I almost completely rewrote the ksni internals, but the public api is almost identical.

This is all that changed in my app code, for a synchronous spawn. Nothing else changed about my code that invoked ksni.

-        let tray = ksni::TrayService::new(service);
-        let handle = tray.handle();
-        tray.spawn();
+        let handle = ksni::spawn(service)
+            .map_err(|e| std::io::Error::new(std::io::ErrorKind::Other, e))?;

To launch it on an existing tokio runtime, you'd need to replicate fn spawn() but skip spawning a thread and use an async task.

I didn't plumb up an equivalent to the sync fn spawn() for async spawning, but the run_async function is public and using it directly would look about like this:

let (client_tx, client_rx) = tokio::sync::mpsc::unbounded_channel::<ClientRequest<T>>();
tokio::spawn(async {
    let _ = run_async(tray, client_rx).await;
});
Ok(Handle { sender: client_tx })

Hi! May I ask what the state of this is? @lunixbochs would you say that your fork is useable for real (OSS) projects? Is it possible to help here?

I use my fork in Talon with real world users.

hm... may I ask why you don't create a PR request with your zbus changes @lunixbochs ?

Read up-thread:

This is a substantial rewrite and the api / send+sync traits changed slightly, so I'm unsure about merging it as is

Hm... would it make sense to create a new "project" with your fork?

Your example doesn't work sadly on my machine :( I'm using stalonetray as a testing system tray and after running cargo run --example example on your fork, nothing changed. May I ask if you have an idea what may be the reason? I've also tried it with i3status-rust

stalonetray might not support SNI. You can try running snixembed

Yay, starting stalonetray and snixembed did it. Thank you! :)

I'd prefer to not hard fork the dependency. I'd like to hear @iovxw's thoughts on merging my changes.

I'd prefer to not hard fork the dependency. I'd like to hear @iovxw's thoughts on merging my changes.

Would be nice if there will be a clear answer to this because my friend and I need this for our project and we need gtk4 for this :) (and zbus would help to reduce some external dependencies)

Actually... I finished the port a few months ago, but didn't have time to test it (I suffered from CVS), and worse, I lost the hard disk somewhere at home...

I'd prefer to not hard fork the dependency. I'd like to hear @iovxw's thoughts on merging my changes.

The mpsc layer doesn't seem necessary, let me try to find the hard drive

I lost the hard disk somewhere at home...

@iovxw may I ask if you've found it? :D

@lunixbochs may I ask if it's possible to have a blocking variant of starting the tray? Because I'm trying to invoke a notification with notify-rust inside the activate function of the ksni::Tray implementation and I'm getting the following error message:

thread 'main' panicked at /home/tornax/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zbus-3.14.1/src/utils.rs:47:14:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.

@lunixbochs may I ask if you could bump the zbus dependency of ksni? Because I'm getting

    Updating crates.io index
error: failed to select a version for `zvariant_utils`.
    ... required by package `zbus_macros v3.14.1`
    ... which satisfies dependency `zbus_macros = "=3.14.1"` of package `zbus v3.14.1`
    ... which satisfies dependency `zbus = "^3.14.1"` of package `ksni v0.2.1 (https://github.com/talonvoice/ksni/?branch=zbus#05abf939)`
    ... which satisfies git dependency `ksni` (locked to 0.2.1) of package `flakeshot v0.1.0 (/home/tornax/projects/flakeshot)`
versions that meet the requirements `=1.0.1` are: 1.0.1

all possible versions conflict with previously selected packages.

  previously selected package `zvariant_utils v1.1.0`
    ... which satisfies dependency `zvariant_utils = "=1.1.0"` of package `zbus_macros v4.0.0`
    ... which satisfies dependency `zbus_macros = "=4.0.0"` of package `zbus v4.0.0`
    ... which satisfies dependency `zbus = "^4"` of package `flakeshot v0.1.0 (/home/tornax/projects/flakeshot)`

failed to select a version for `zvariant_utils` which could resolve this conflict

Or do you prefer a PR?

That's no lock in the fork because there's no lock in the upstream repo. Personally I'm just relying on the lock file in my app.

There's a pattern in this thread of people asking me for support on my branch. If I want to provide that kind of support, I will hard fork ksni. Right now, what you see in my repo is what you get. I do actively use my ksni fork in my production app and you can probably expect me to make changes needed by my app and fix bugs reported by my users, but you are not my users and you should not approach me for support in your use of my fork at this time.

I would prefer to keep this thread about merging the fork.

Fair, I'm sorry for the noise!

Sorry for the late reply, tooooo many things to do

Bad news, didn't find the hard drive during the Chinese New Year holiday cleanup

Good news, lunixbochs's fork has been merged, a new version will be released soon (after I have time to do a few small tweaks and tests), thank you @lunixbochs

Hey! Are there any plans to go forward with zbus in the main branch in the foreseeable future?

Friendly ping, I'm also looking forward to using zbus version, but don't want to depend on a custom branch that is not guaranteed to exist long-term.