Updated README with this decision. Also other documents as well.

README.md

@@ -1,30 +1,11 @@
 [![Build Status](https://travis-ci.org/andlabs/ui.png?branch=master)](https://travis-ci.org/andlabs/ui)
 # Native UI library for Go
-### CRITICAL UPDATE 17 March 2014: Due to deadlocks between resizing and setting label text once a second (see below), all Controls no longer lock their internal mutex locks after their Window has been created. This seems to not have issues, and the Go race detector isn't saying anything, so IDK... Please help spot issues or suggest actual solutions if you can.
-The issue:
-- a time.Ticker ticks, which causes label.SetText() or whatever to be called; it locks its mutex
-- at the same time, a resize event comes in; the resize event runs before the SetText action ever does
-- the resize eventually comes to the label, whose resizing functions also try to lock the already-locked mutex
-- because the drawing function is now stuck waiting for the mutex to be unlocked, the label.SetText() system-dependent operation never runs, so the mutex is never unlocked
-- this fools Go's deadlock detector; it never reports anything
-- changing from standard mutexes to R/W mutexes does not work
-- making resizes concurrent causes resizes to become too slow to be acceptable: the control resizing doesn't take effect until at least a second after the user lets go, and keeping a grip too long overloads the scheduler with goroutines
-- making Label use a goroutine and channels for internal communication did not get rid of the locks
-
-If you know a better way I can do things, **please** help... I'm at my wits end here<br>The main test (`test/test`) now has its label show the current time; GTK+ users can run `test/test -area` for the Area test that sparked this whole calamity.
-
-
-
-
-
-
-
-
-
 ### THIS PACKAGE IS UNDER ACTIVE DEVELOPMENT. It can be used; the API is stable enough at this point, but keep in mind there may still be crashes and API changes, as suggestions are always open. If you can help, please do! Run `./test` to build a test binary `test/test` which runs a (mostly) feature-complete UI test. Run `./d32 ./test` to build a 32-bit version (you will need a cgo-enabled 32-bit go environment, and I have only tested this on Mac OS X).
 
 ### UPDATE 12 March 2014: Windows 2000 is no longer supported [as it is no longer supported by Go](https://codereview.appspot.com/74790043).
 
+### UPDATE 18 March 2014: Resizes are now assumed to stop other UI event processing, and thus do not run with locks anymore. I changed real control resizing so that it doesn't need to lock (it just fills an array with data fed in), but real control `preferredSize()` and `Stack`/`Grid.setRect()` could potentially still be racy... if I am right it won't be an issue, but if anyone else knows, please let me know.
+
 This is a simple library for building cross-platform GUI programs in Go. It targets Windows, Mac OS X, Linux, and other Unixes, and provides a thread-safe, channel-based API. The API itself is minimal; it aims to provide only what is necessary for GUI program design. That being said, suggestions are welcome. Layout is done using various layout managers, and some effort is taken to conform to the target platform's UI guidelines. Otherwise, the library uses native toolkits.
 
 ui aims to run on all supported versions of supported platforms. To be more precise, the system requirements are:

implementation.md

@@ -1,3 +1,5 @@
+## UPDATE 18 March 2014: this document is out of date and could use some rewriting
+
 # ui library implementation information
 
 All platform-specific functionality is isolated in a mega-type `sysData` that stores OS toolkit handles and provides methods that do the work for the frontend API. The file `sysdata.go` defines a type `cSysData` that contains everything all platforms have in common and dummy definitions of the `sysData` functions that panic. The platform-specific `sysData` embeds `cSysData`.

todo.md

@@ -75,6 +75,7 @@ super ultra important things:
 	- GTK+: requested clip rect seems to be larger than the size of the Area (also larger than the visible portion? TODO)
 - when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (progress bars/entry lines will just cut off; editable comboboxes will stretch slightly longer than noneditable ones; the horizontal scrollbar in Area will disappear smoothly; etc.)
 - the window background of a GTK+ window seems to be... off - I think it has to do with the GtkLayout
+- see update 18 March 2014 in README
 
 important things:
 - make specific wording in documentation consistent (make/create, etc.)