Cleaned up TODO.md.

TODO.md

@@ -1,54 +1,32 @@
 - all ports: update state when adding a control to a parent
+- should uiWindowsSizing be computed against the window handle, not the parent?
 
-# Old TODOs
-
-- figure out how to deal with dchild at all, including preferred sizes
-- make OS X uiEntry width based on default in Interface Builder, not from sizeToFit
-- update state whenever setting parent
-- make the various onDestroy() functions take the uiControl instead
-- make sure all calls to uiControlResize() are preceded with calls to uiControlGetSizing()
-
-- OS X group: use setFrameFromContentFrame: in preferredSize?
 - DPI awareness on windows
 
-- require explicit calls to uiContainerUpdate() everywhere, because sigh...
-	- forbid uiControlSetParent() when there already is a parent
 - consider calling setAppleMenu: for the application menu; it doesn't seem to make much of a difference but
 - http://stackoverflow.com/questions/4543087/applicationwillterminate-and-the-dock-but-wanting-to-cancel-this-action
 
 ultimately:
 - MAYBE readd lifetime handling/destruction blocking
-- assign control IDs on windows
-	- GWL(P)_ID
-	- related? [12:25] <ZeroOne> And the blue outline on those buttons [ALL clicked buttons on Windows 7] won't go away
-		- I get this too
+- related? [12:25] <ZeroOne> And the blue outline on those buttons [ALL clicked buttons on Windows 7] won't go away
+	- I get this too
 - SWP_NOCOPYBITS to avoid button redraw issues on Windows when not in tab, but only when making resize faster
-- opposite side alignment control in uiBox
+- secondary side alignment control in uiBox
 - generate libui.lib and related files
-- make OS-specific headers generated by an IDL
-- menu item state change while the menu is visible (not in response to user action)
-	- OS X: requires an [NSMenu update] call after changing state
-	- Windows: requires getting current menu state when amending it in sync()
-- figure out where we should return HRESULTs
 - Windows: don't abort if a cleanup function fails?
-- make it so Windows API calls that do logLastError(), etc. abort whatever they're doing and not try to continue, just like wintable
+
 - 32-bit Mac OS X support (requires lots of code changes)
 	- change the build system to be more receptive to arch changes
 
 notes to self
 - explicitly document label position at top-left corner
+- explicitly document that if number of radio buttons >= 1 there will always be a selection
 - mark that uiControlShow() on a uiWindow() will bring to front and give keyboard focus because of OS X
 	- make sure ShowWindow() is sufficient for zorder on Windows
 - document that you CAN use InsertAt functions to insert at the first invalid index, even if the array is empty
-	- add tests for this
 - note that uiTabInsertAt() does NOT change the current tab page (it may change its index if inserting before the current page)
 - note that the default action for uiWindowOnClosing() is to return 0 (keep the window open)
 - note that uiInitOptions should be initialized to zero
 - explicitly document that uiCheckboxSetChecked() and uiEntrySetText() do not fire uiCheckboxOnToggled() and uiEntryOnChanged(), respectively
-- note that uiControlResize() on a uiContainer also updates
 - note that if a menu is requested on systems with menubars on windows but no menus are defined, the result is a blank menubar, with whatever that means left up to the OS to decide
-- note that type mixing == undefined behavior
-- note that handling of multiple consecutive separators in menus, leading separators in menus, and trailing separators in menus are all implementation-defined
-- note that ContainerVisible() returns true if both user and container not hidden; container use only
-- note that if we are currently updating, QueueResize() will take effect during the CURRENT update cycle
-- note that uiControlResize() on Windows is now in *toplevel uiWindow* coordinates
+- note that handling of multiple consecutive separators in menus, leading separators in menus, and trailing separators in menus are all OS-defined