I have a two widgets in a simple GTK app:
extern crate gdk;
extern crate gtk;
use super::desktop_entry::DesktopEntry;
use gdk::enums::key;
use gtk::prelude::*;
pub fn launch_ui(_desktop_entries: Vec<DesktopEntry>) {
gtk::init().unwrap();
let builder = gtk::Builder::new_from_string(include_str!("interface.glade"));
let window: gtk::Window = builder.get_object("main_window").unwrap();
let search_entry: gtk::SearchEntry = builder.get_object("search_entry").unwrap();
let list_box: gtk::ListBox = builder.get_object("list_box").unwrap();
window.show_all();
search_entry.connect_search_changed(move |_se| {
let _a = list_box.get_selected_rows();
});
window.connect_key_press_event(move |_, key| {
match key.get_keyval() {
key::Down => {
list_box.unselect_all();
}
_ => {}
}
gtk::Inhibit(false)
});
gtk::main();
}
I need to change list_box from both events. I have two closures that move, but it is not possible to move list_box to both closures simultaneously as I get the error:
error[E0382]: capture of moved value: `list_box`
What can I do?
As explained in Shepmaster's answer, you can only move a value out of a variable once, and the compiler will prevent you from doing it a second time. I'll try to add a bit of specific context for this use case. Most of this is from my memory of having used GTK from C ages ago, and a few bits I just looked up in the gtk-rs documentation, so I'm sure I got some details wrong, but I think the general gist is accurate.
Let's first take a look at why you need to move the value into the closures in the first place. The methods you call on
list_boxinside both closures takeselfby reference, so you don't actually consume the list box in the closures. This means it would be perfectly valid to define the two closures without themovespecifiers – you only need read-only references tolist_box, you are allowed to have more than one read-only reference at once, andlist_boxlives at least as long as the closures.However, while you are allowed to define the two closures without moving
list_boxinto them, you can't pass the closures defined this way to gtk-rs: all functions connecting event handlers only accept "static" functions, e.g.The type
Fof the handler has the trait boundFn(&Self) + 'static, which means that the closure either can't hold any references at all, or all references it holds must have static lifetime. If we don't movelist_boxinto the closure, the closure will hold a non-static reference to it. So we need to get rid of the reference before being able to use the function as an event handler.Why does gtk-rs impose this limitation? The reason is that gtk-rs is a wrapper around a set of C libraries, and a pointer to the callback is eventually passed on to the underlying
gliblibrary. Since C does not have any concept of lifetimes, the only way to do this safely is to require that there aren't any references that may become invalid.We have now established that our closures can't hold any references. We still need to access
list_boxfrom the closures, so what are our options? If you only have a single closure, usingmovedoes the trick – by movinglist_boxinto the closure, the closure becomes its owner. However, we have seen that this doesn't work for more than one closure, because we can only movelist_boxonce. We need to find a way to have multiple owners for it, and the Rust standard library provides such a way: the reference-counting pointersRcandArc. The former is used for values that are only accessed from the current thread, while the latter is safe to move to other threads.If I remember correctly, glib executes all event handlers in the main thread, and the trait bounds for the closure reflect this: the closure isn't required to be
SendorSync, so we should be able to make do withRc. Morevoer, we only need read access tolist_boxin the closures, so we don't needRefCellorMutexfor interior mutability in this case. In summary, all you need is probably this:Now you have two "owned" pointers to the same list box, and these pointers can be moved into the two closures.
Disclaimer: I couldn't really test any of this, since your example code isn't self-contained.