Single-instance app

[phkoester]

I want my app to have a systray icon. Thus, it makes sense for the app to be single-instance only. Using the interprocess crate, I managed to receive command-line args from another instance of the app, which sends the command line to the already-running instance and then exits itself.

Now, the first instance of the app should activate its window and grab the focus. How would I do that? I need to get a handle of the main window and call set_focus on it. I'm basically in main, with no component context whatsoever. Can this be done?

[DogeDark]

I don't believe it is possible to get a window handle before dioxus::launch is called. I'd suggest using a use_effect, and maybe spawn in your App component and call the window function to get a handle to the window: https://docs.rs/dioxus-desktop/latest/dioxus_desktop/fn.window.html

Alternatively, if this is a one-time thing, you could pass data as context from your main function to the root App component with LaunchBuilder::new().with_context(data) https://docs.rs/dioxus/latest/dioxus/struct.LaunchBuilder.html

[phkoester]

Thanks a lot for your answer. I still can't figure out how to do this. In my App fn, I can call dioxus::desktop::window(), which yields an Rc<DesktopService>. There is also use_window() with the exact same return type, but the impl looks completely different at a first glance. I'm only starting to learn Dioxus, so I'm not on solid ground here.

Because Rc is not Send, I can't pass this handle to another thread. Maybe I need a weak handle or must explicitly drop it when the window is closing, but anyway, I see no way to pass it to my little command-line service.

[phkoester]

Do you mean the component would receive the command-line arguments? Why would I need a channel for that, doesn't Dioxus have some mechanism there? I'm just reading about hooks, signals, effects, and global signals, but all of these only seem to work in component functions. I cannot use a GlobalSignal from an arbitrary thread. In Tauri, an app can "emit" something, how do I do this in Dioxus?

Let's imagine my app would have a menu bar and a menu item to open a file. Now, how would I send the file path to any component and update the UI? Likewise, if I receive a command-line, how can I pass it on to the UI? In the UI, I can call window().set_focus(), but how would I trrigger that?

[DogeDark]

Dioxus doesn't have an event emit kind of system built in for app state. There is dioxus-radio but this relies on the Dioxus runtime which can't be used outside of components.

The reason I'm suggesting a channel is that you need something to bridge between your command-line thread and the Dioxus thread/runtime to be able to interact with the Window.

Whatever data you send through that channel - I'd suggest a custom enum with a variant like FocusWindow - the app would have to react to it and perform actions accordingly, such as focusing the current window.

Here's what I'm trying to describe:

use dioxus::prelude::*;

#[derive(Debug, Clone)]
enum AppEvent {
    FocusWindow,
}

fn main() {
    // this doesn't need to be tokio
    let (tx, rx) = tokio::sync::mpsc::channel(5);
    tokio::spawn(async move {
        // your interprocess code here
        // determine when you need to focus the window and send the event:
        tx.send(AppEvent::FocusWindow).await;
    });
    
    LaunchBuilder::new().with_context(rx).launch(App);
}


#[component]
fn App() -> Element {
    // spawn a future, grab the channel receiver from context, and start handling events.
    use_effect(move || {
        spawn_forever(move || async move {
            let mut app_event_rx: Receiver<AppEvent> = consume_context();
            while let Some(event) = app_event_rx.recv() {
                match event {
                    AppEvent::FocusWindow => {
                        let window = window().window;
                        window.set_focus();
                    }
                }
            }
        });
    });
    
    rsx! { "hi" }
}

I actually think this is something that would be quite handy to have in Dioxus itself. A way to push events into the Dioxus runtime. Like a use_external_event(move |event| println!("{:?}", event)); hook.

Now, how would I send the file path to any component and update the UI?

For menu items specifically, we have use_muda_event_handler

[phkoester]

Alright, I'm trying to follow your example. dioxus_desktop already depends on tokio, so I'm fine with that:

let (app_sender, app_receiver) = tokio::sync::mpsc::channel::<AppEvent>(5);

I can clone the sender and pass it to my desktop init code. Perfect. However, .with_context(app_receiver) doesn't compile:

the trait bound `tokio::sync::mpsc::Receiver<AppEvent>: Clone` is not satisfied

The function signature is

pub fn with_context(mut self, state: impl Any + Clone + Send + Sync + 'static) -> Self

Do I have to wrap the receiver somewhow?

[phkoester]

Okay, I wrapped the receiver in an Arc<Mutex<...>>. This compiles, and in Rust, this means it works! ;)

I have this in the App function:

#[cfg(feature = "desktop")]
use_effect(move || {
  spawn_forever(async move {
    let app_receiver: Arc<Mutex<Receiver<AppEvent>>> = consume_context();
    let mut app_receiver = app_receiver.lock().await;
    println!("IN use_effect(), got lock"); // I see this message!
    while let Some(event) = app_receiver.recv().await {
      match event {
        AppEvent::Run(args) => {
          println!("AppEvent::Run({:?})", args);
          let window = dioxus::desktop::window();
          window.set_focus();
        }
      }
    }
  });
});

The lock is being acquired alright. But on the sender site, Tokio isn't initialized:

thread '<unnamed>' panicked at src/desktop.rs:100:9:
there is no reactor running, must be called from the context of a Tokio 1.x runtime

I tinkered about with async main and #[tokio::main], but to no avail. I'm not familiar with Tokio.

The sending code in desktop.rs looks like this:

let sender = sender.clone();
tokio::spawn(async move {
  debug!("Sending AppEvent");
  _ = sender.send(AppEvent::Run(args)).await;
  debug!("Sent AppEvent");
});

[DogeDark]

I realize that dioxus-desktop creates a tokio runtime on its own. Good news is that it's behind a feature flag tokio_runtime so disabling it in Cargo.toml would let you do this:

// main.rs
#[tokio::main]
async fn main() {

# cargo.toml
dioxus-desktop = { 
    version = "0.6", 
    default-features = false, 
    # these are the default features except tokio_runtime
    features = ["exception", "transparent", "devtools"]
}

[phkoester]

Thanks a lot, I got the chain running until set_focus. There was no need to change the Cargo.toml. The problem was I tried to tokio::spawn from a new thread that has no Tokio runtime. Passing over a handle fixed this. In a component function, with feature desktop, Tokio is ready to use out of the box.

The code has gotten pretty lengthy and complicated, so I will try to make things simple and beautiful. "Single instance" should be a feature I can easily enable or disable for a particular app.

When and how often is the App function called? I need to set up sender, receiver, and service only once, of course. Would std::sync::Once be a reasonable helper here? Why did you suggest use_effect here? Will the closure ever be called once only because it has no dependencies?

Umh, there is so much for me to learn here, I'm not even a web developer, been doing Rust only for a few months now, and I don't feel very comfortable with async yet, but I think I got the picture. I wanted to use the hottest stuff out there and learn something new. I am willing to take the challenge ... Please be merciful to me if I ask too many questions.

[DogeDark]

There was no need to change the Cargo.toml

Odd, I expected it would conflict since two Tokio runtimes can't be started at the same time. If it works, it works haha.

The App function is called whenever Dioxus determines it needs to rerun, such as updating state in a Signal.

use_effect is a hook that will rerun the closure anytime any dependencies are updated. Since we don't use any dependencies, it will only run once, starting your channel listener. This allows the App component to run as much as it wants without causing issues.

I don't think you need std::sync::Once though it depends on your app's architecture. It sounds like any new instances (while the app is running) will communicate over interprocess and then shut themselves down. If that is the case, then you probably don't need std::sync::Once since the main instance will only create the channel and interprocess communication thread once.

Async definitely takes some time to understand, especially since things don't run in a specific order. Dioxus being single-threaded means we have to use async a lot since blocking the thread will freeze the UI, and often cause deadlocks.

What we're doing here, awaiting events from the channel, basically tells Tokio/Dioxus that if there is data ready, continue with the current execution (in your case the match statement), otherwise work on something else (rendering UI, networking, events, etc) and check back later to see if there is any data available from your channel to be processed. I figured I would try to explain some of it in case it'd help at all. And don't worry about asking too many questions (it's how you learn!) I'll try to help the best I can.

[phkoester]

Changing the Cargo.toml the way you suggested didn't work for me. Tokio complained about being init'ed twice. It looks like disabling the tokio_runtime feature didn't work as intended. (I don't even have dioxus-desktop as a dependency, this all works through re-exports.) I'm not sure about the side effects anyway---maybe I miss some Dioxus functionality if I tell it to not use Tokio?

So, in a first approach, I moved all of the interprocess set-up stuff into the App function, using the existing Tokio runtime that is ready by the time the component function is called. This worked, but then, the second app instance took some time to pass on the command line to the other process and then exit. Looking up another process, sending some data, and then exiting can be a lot faster. In fact, I don't need the App function to be called for the second instance at all.

So what I'm doing now is a bit strange, but it works. I create the Tokio channel directly in main, without any Tokio runtime being set up at all. The receiver is passed on to the App function as a context, using the Tokio runtime from dioxus-desktop. The app-event sender, however, creates a new runtime via let runtime = tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap() in a separate thread. In this thread, I send the event like this:

runtime.block_on(async {
  _ = sender.send(DesktopEvent::Run(args)).await;
});

Although sender and receiver "live" in different Tokio runtimes, this works. I did not really expect this, but that's what it does. How Tokio deals with this is beyond my comprehension.