<p>We are developing in an embedded type environment and find ourselves needing to create our own UI framework.</p>

<p>I have done this before, but I am interested in doing a little bit of research around common design patterns for frameworks.</p>

<p>Types of things that I am thinking of as patterns (somewhat far reaching):</p>

<ul>
<li>Widget Focus / defocus </li>
<li>Widget Animation </li>
<li>Data sharing between elements</li>
<li>Attaching commands to widgets</li>
<li>Saving state (MVC?)</li>
</ul>

<p>What recommended reading do you have for GUI Framework patterns?</p>

I have two for you, the callback or notification, maybe this is what you call "attaching commands to widgets", somehow you want to react to changes in state in your UI element. The controller needs to be informed that a change has occured.
Cocoa/UIKit has a pattern that is called "Delegation" and notifications to accomplish this, others use callback functions or objects (Java Swing) or  "signals and slots" (QT).
I very useful pattern that does not occur in the wild very often is the ability to
prevent
a state change, the easiest use case for this is input validation, you want to prevent the loss of focus from a widget when the text in the widget does not concur with what you would expect. Windows Forms used to have that on some elements, not all, Cocoa can do this. This can be accomplished by using return values or reference parameters (or pointers) in the callbacks where the callee can communicate back to the originating widget
These days applying styles to ui elements, i.e. changing the look without changing the functionality has also become very popular QT can do this and I am sure a lot of other libraries
The Gang of Four Decorator pattern is also used sometimes for enhancing the capabilities of a widget, making something scrollable could be done via a decorator. It all depends on how far you will need to go with your UI elements. Good Luck, it is not an easy task
EDT: Apply MVC wherever you can. The first candidates are any kind of list displays, don't make them responsible for keeping the items they are displaying. This definitely goes for the combo box, a list box, tables and trees, you could implement this for text inputs but that might not be worth the overhead.