I remembered I have a keyboard for my Palm Vx which I can use on the train.
Let me know what other topics you would like me to cover.
andy
Widget Redisplay
Widget redisplay follows the general asynchronous nature of redisplay
in general - that is items for display are updated separately to their
actual visual representation. For instance a tab control has serveral
lisp structures associated with it. When the tab structure is changed,
thes lisp structures are changed, but it is not until redisplay proper
that you actually see any change. There are several reasons for doing
it this way, one is that it conforms more closely to the second rule
of redisplay - not to call lisp during redisplay. The actual mechanics
of this is encoded in two image instance methods -
update_image_instance and redisplay_subwindow with obvious
meanings. These methods delegate to widget specific versions via
update_widget and redisplay_widget. These in turn delegate to device
and format specific methods - for example layout_update and
mswindows_button_redisplay.
update_image_instance bears further discussion since it encapsulates
behaviour that is important to understand. To change a widget the
image instance is not manipulated directly, but rather its
instantiator is changed and then these changes are propogated to image
instances that are instantiated by this instantiator. However, in
order for this behaviour to work properly it is important that the
image instances are not recreated - as would be the case in a naive
implementation - unless absolutely necessary. Thus, the image instance
cache for widgets is keyed on the glyph identity and the widget type
*not* on the instantiator. When image_instantiate is called it looks
up the image_instance based on its glyph and domain and if a match is
found update_image_instance is called with the new instantiator. The
cache is keyed on the image type as well as the glyph because it would
be impossible to merely update an image instance representing one gui
widget to another; for instance converting a button to a tree-view.
update_image_instance compares the original instantiator and then
calls widget_update with only those keyword-value pairs that have
changed. The individual image instance update functions then update
the internal structure of the widget using those values.
However, herein lies a problem - redisplay optimizes which parts of
the screen it is going to display by comparing current and future
redisplay structures, however in the case of glyphs the glyphs are the
same object in both sets of structures. This is because otherwise
glyphs and image instances would be recreated each time redisplay was
called. So how does redisplay know whether to actually update the
displayed properties of image instances? The solution is a set of
`dirty' bits in the image instance which are set depending on what
changes update_image_instance has actually made. The flags also need
to be propagated up to the glyph so that redisplay can tell easily
whether something might have been changed or not. We say `might' here
because it is possible for the same glyph to have diffferent
instantiators in different domains and thus redisplay must update only
the image instances for the instantiator that has changed. The
dirtiness or otherwise of a glyph is encapsulated in
imge_instance_changed and also compare_runes. When a
determination of dirtiness has been made the image is redisplayed
using redisplay_subwindow. This propogates the lisp structure
changes (in gui_item) into on-screen properties and then marks the
structure and instantiator as up-to-date. In both X and mswindows a
lot of generic updating is done in mswindows_redisplay_widget and
x_redisplay_widget. In fact under X this is pretty much the only
function that gets called since the updates are then delegated to
lwlib to handle.