I had a mental breakdown watching everything fall apart miserably and so I decided to just start over, this time designing around the underlying APIs, not around what I actually want the API to look like.
WINDOWS
GUI work can be done on multiple threads; just run a message loop on each thread (and set COM threading to STA)
each thread owns whatever window handles were created on that thread
will need a master thread to coordinate everything
dialogs are code-modal; no result until dialog closed and blocks owner hwnd
open-close order important; threads circumvent this
owner hwnd required to keep on top; can't keep on top unconditionally
changing parents is possible; initially unowned might not be? TODO
I have a stackoverflow question asking about this but no one has given me a real answer yet, just more questions
- font and color choosers are neither, but since they're NSPanels which are NSWindows I could coerce them to be :S would take a fair bit of work though
all calls are done with performSelectorOnMainThread:
each widget calls a function that creates a window
this allows the API to be fully multithreaded, and allows us to have callabcks just be normal
the ui.Go() function would sit waiting for Stop to be sent, at which point it would signal all open windows to quit unconditionally, then break the event loop without calling terminate
for window-specific dialogs, a goroutine/channel hack may be necessary if this SO question doesn't get an answer
the answer might also be victim to ordering...
GENERAL NOTES
what about spinning an inner message pump during each event and run event handlers in their own goroutine?
no, still subject to the same race condition that could lead to a double button press