I like theIDispatchQueueManager idea, but seems like this could just extend theTrayWindow and have it be theIDispatchQueueManager, rather than having it on the App and having to deal with the fact that it might be null.

We have the TrayWindow as a "transient" in the dependency injection right now, but the App creates an instance that it holds forever, so we are lying to ourselves about it being transient.

The problem with this is if we define it as a singleton the DI instance tries to create it outside of the UI thread, which will crash the app. That's why all of the stuff that must be instantiated on the UI thread is marked transient, even if it typically only gets instantiated once.

This shit is so dumb.

Q: How do you get on the main UI thread?

A: You need a DispatcherQueue.

Q: How do you get a DispatcherQueue?

A: You have to get it from a UI Window

Q: How do you get a UI Window?

A: You have to create it from the main UI thread.

Should we be moving all this initialization of dependencies toOnLaunched instead so it's on the main UI thread?

truly a classic Microsoft® Moment™

We could try doing that. I don't know what the DI behavior will be for a singleton<IDispatcherQueueManager, TrayWindow> if it can still be accessed as bothIDispatcherQueueManager andTrayWindow, but I'll give it a shot

If I move all the instantiation toOnLaunched then all of the properties inApp need to become nullable which seems worse, so I think I'll just stick to a method like this. I will makeApp itself be theIDispatcherQueueManager though which seems a lot nicer.

Cool cool.