>Every now and then while Squeaking, we arrive at some inconsistent 
>user interface state.  You know, a bit of the screen is munged 
>graphically, a list's highlighting is set so that an item is 
>hilighted when deselected and vice-versa; that sort of thing.
>
>Though I'm not yet a Smalltalk GUI maven, I thought a perspicacious 
>report of some repeatable outstanding bugs might be useful to those 
>who do this sort of thing for real.
>
>For example, consider the following experiment in MVC:
>
>	1.  Open a workspace.
>	2.  Type "3 inspect," and then select doIt from the scrollbar 
>menu.  Note that the scrollbar correctly disappears as the workspace 
>window is deactivated as the inspector is activated.
>	3.  Now, do the same thing, but hit command-D.  Note that the 
>scrollbar remains.  Clearly this is not the intended state, as 
>selecting "restore display" redraws the screen without the 
>scrollbar, per example 2 above.
>
>I belive this may be responsible for some of the pixel spore 
>occasionally hanging around my desktop.  Not a problem, as "restore 
>display" tends to fix it all, but perhaps there is a simple fix for 
>this one?
>
>Morphic appears to behave responsibly in this regard.


Here's another one.  Take any browser list panel that needs to be 
scrolled.  Select the top element of the list, and then scroll down 
so that the element is no longer visible.  Return to the top, and the 
element is unhilighted, appearing to be de-selected, though the 
browser otherwise behaves as thought it were selected.

Click on it again, and the line will show as hilighted.  however, the 
browser will behave as though it were deselected.  Then, for maximum 
cognitive dissonance, select another item, and watch both elements 
remain hilighted.

As with the above, this is MVC only.