andlabs-ui/newplan

35 lines
2.3 KiB
Plaintext
Raw Normal View History

2014-07-02 16:57:56 -05:00
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
creating windows and controls before main loop begins possible
2014-07-02 17:00:08 -05:00
sending a message across threads will hang up the first thread during the send if you so choose
2014-07-02 16:57:56 -05:00
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
2014-07-02 17:00:08 -05:00
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
2014-07-02 16:57:56 -05:00
COCOA
only one thread, must be thread main() is called on
cannot create new windows/controls on any other thread
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
not sure if changing parents is possible TODO
not sure if creating windows/controls before [NSApp run] is supported
2014-07-02 17:00:08 -05:00
sending a message across threads will hang up the first thread during the send if you so choose