perhaps break this down with a type alias or something? that type signature is very verbose

Yeah, Clippy did tell me about this. Still working on exactly which types I want so I didn't want to make them aliased yet.

maybe use the futures_unordered crate? produces a stream of futures, which if I remember correctly, you can get the results of concurrently and in order

I did mention in there that I can not have them compute concurrently, and why. The Vec<Command> may need to modify state.

isn't this the purpose of this refactor, to remove state handling within handlers, but modify state externally outside the handler? if we modify global state in there, we're back to no testability or very hard testability

A set of Commands are instructions on how to modify the state. Yes, the idea of this is to move the handling of state separate from the handling of actions. For example, an event may update speak some text, update the cache, fire a key event, or open a remote connection.

The implementations of these actions should be separate from their intention. If I want to speak x and y, then open a remote connection, that should be done through a set of commands, which are applied onto the state.

This way, we de-duplicate code, and de-couple the implmentation. So now, an addon can say "Hey, if I get this event, then I saw to beep at this frequency, or play this sound if some other condition is matched", and Odilia can respond without trying to give direct access to resources across FFI boundaries.

but then, state still doesn't have to be updated in the handler, no? and then, event handlers can indeed run in paralell

State will (eventually) be applied within a single call to a boxed service. But, since getting partial state is required (mostly) for each function, the functions that need state will need to be run in series to avoid sending out copies of stale data. Imagine that F1 updates the currently focused item, and F2 depends on the state of the currently focused item. If run in parallel, these functions will both get a copy of the current focused item at time 0, F1 will then run, producing a command to update the currently focused item, then F2 runs saying to speak the currently focused item and its role. This will result in speaking the last focused item instead of the current one.

from stackoverflow

you can directly use a stream of streams of future, where each future is converted to a stream and then flattened to force it to be poled to completion before anything else is. For that, you can use iter_ok, like so...

iter_ok(tasks).map(|f|f.into_stream()).flatten()

or this, where you get a single future which poles all of them to completion

let tasks = vec![ok(()), ok(()), ok(())];

let combined_task = iter_ok::<_, ()>(tasks).for_each(|f| f);

though I still question the doing of such serially, but this is an approach with mucbh less code, if it can be done

I like this! But we need concrete types since we need to return this from a function.

I tried really hard to use something more similar to this, especially in relation to not rolling our own SequentialFutures. That does seem silly after all.

I got really close but got slapped by the borrow checker. I can come back to this one.