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
	might not be possible if we have one thread per window? TODO googling fails
creating windows and controls before main loop begins possible
sending a message across threads will hang up the first thread during the send if you so choose

	POSSIBLE BACKEND DESIGN
	each top-level window exists on its own thread
	each request would be a SendMessage(hwndParent, msgDoThing, hwnd, &arg)
	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

GTK+
GUI work must be done on the main thread; what thread this is isn't particularly clear but I'm assuming it's the one that calls gtk_init()
IIRC windows/controls can only be made on the main thread as well
dialogs can either be code modal or not
	dialogs are modal to all windows in the same window group; only the transient window is actually DISABLED, however
	not sure if open/close order can be affected since gtk_dialog_run() does that transient window thing
can't keep dialog window always on top (X11-based limitation); only above the transient window (if any)
changing parents is possible but IIRC is done in a control-dependent manner? also requires incrementing the refcount
creating windows and controls before main loop begins possible
sending a message across threads will NOT hang up the first thread during the send, and the GTK+ designers don't think this is good design
	- there is gdk_threads_enter()/gdk_threads_leave() but they're X11-only and deprecated as of GTK+ 3.6
	- gdk_threads_add_idle() does not block
	- g_main_context_invoke() also doesn't block if not on the main thread
	- g_signal_emit() is not thread safe

COCOA
only one thread, must be thread main() is called on
cannot create new windows/controls on any other thread
	there are complex rules involving windows but let's not bother
everything is coordinated with the NSApp delegate
two types of dialogs:
	- code-modal; stops ALL interaction with program
	- non-code-modal; affects current window only but need to sit and wait for a callback to come in before you know it's done
		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
not sure if changing parents is possible TODO
creating windows/controls before [NSApp run] possible
	TODO documented?
sending a message across threads will hang up the first thread during the send if you so choose

	POSSIBLE BACKEND DESIGN
	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
another caveat I neve rnoticed before
	[20:20] <andlabs> ,..ack
	[20:20] <andlabs> I just realized osmething else about my API design
	[20:21] <andlabs> I can't stop preemption during an event handle
	[20:21] <andlabs> r
	[20:23] <andlabs> no matter how I slice it I might have to have tow different sets of funcitons
	[20:23] <andlabs> one for outside evernts and one for inside events
	[20:23] <andlabs> yuck