A safer way to get interact with other threads would be very nice

[mullr]

My program has a worker thread that the UI needs to interact with. I'm presently using queued_callback to do this, which in itself is fine. But in order to actually affect any UI changes in its callback, you need to do some acrobatics that feel very unsettling to a Rust developer.

This is the pattern I arrived at, and the only thing I could get to work:

fn do_stuff_in_a_qobj(&mut self) {
   let self_ptr = QPointer::from(self as &Self);
   self.worker_thread_sender
        .send(WorkerThreadRequest::DoWork(Box::new(queued_callback(
            move |result: ResultOfWork| {
                self_ptr.as_pinned().borrow_mut().map(|self_| {
                    let mut self_mut = self_.borrow_mut();
                    self_mut.deal_with_result_of_work(result);
                });
            },
        ))))
        .unwrap();
}

This is very hairy, and I'm not even certain it's correct. (If self_ptr wasn't pinned before, does that mean it could be moved before the callback triggers?) If this is indeed the intended pattern, it would be great to facilitate it, perhaps via a version that does the capturing for you, something like this:

trait CallbackHelper {
    fn capturing_queued_callback<T: Send>(
        &mut self,
        func: fn(&mut Self, T),
    ) -> Box<dyn Fn(T) + Send + Sync>;
}

impl<Q: QObject> CallbackHelper for Q {
    fn capturing_queued_callback<T: Send>(
        &mut self,
        func: fn(&mut Self, T),
    ) -> Box<dyn Fn(T) + Send + Sync> {
        // Rust does not believe I should be able to implement this
    }
}

[mullr]

I understand now that 'self' is in fact pinned, as long as it has previously been handed over to qmetaobject-rs. I think a more idiomatic way to deal with this in client code would be to require do_stuff_in_a_qobj to take a Pin<Box<Self>> or similar as its self type (I /think/ you can do that now).