Thank you, Steve!

At 9:55 PM -0400 7/3/02, Steve Elkins wrote:

>The thumbnails in the Tools flap don't match the tools.  The
>thumbnails have the classic look and the tools have the alternative
>(white background) look.  But I have deeper complaint, that changing
>the look (theme) doesn't change the thumbnails.  I used to destroy and
>restore flaps to work around this.  Lately "PartsBin initialize" is
>what's required.

Good spotting.  Actually, this was intentional, and only achieved 
after a certain amount of delicate effort.  To my eye, the 
characteristic colors of the tools do not exhibit themselves strongly 
enough when the icons are made from the alternate window look -- the 
icons look insipid, and do not whisper their function loudly enough 
to be easily heard.  I wonder what others' opinions are about this.

And you're right that the thumbnail cache persists across fresh 
launches of flaps, and you were clever to discover the magic potion 
of "PartsBin initialize" to reset the icon cache.  A more direct UI 
is also available for resetting the icon cache -- look in the halo 
menu of the Objects Tool.


>...Alt-o brings up the Objects tool in the 4889 image (just like the menu
>says) but it brings up a Workspace in gamma4.  Alt-k in 4889 opens a
>Workspace (like the menu says) but in gamma4 it opens a font menu.
>Alt-t and Alt-b work the same in the 2 images.

This has to do with the setting of the "mouseOverForKeyboardFocus" 
preference.  When this preference is *off* -- the default nowadays -- 
all keystrokes, including command-key gestures, get sent to the last 
active pane that was accepting keystrokes, even if the cursor is no 
longer over that pane; when this happens, the "desktop command keys" 
such as alt-k and alt-r and alt-b will not be fielded by the desktop 
if some window retains residual keyboard focus.

This is what happened when you hit alt-o -- some text window must 
have been retaining the keyboard focus, so alt-o was fielded by that 
text window, which interpreted it as a "spawn" request.

A simple click on the desktop will force the offending window to 
relinquish keyboard focus, whereupon the desktop command keys will 
work as expected -- alt-o will bring up the Objects tool, etc.

I personally prefer the classic *on* (true) setting for 
mouseOverForKeyboardFocus -- when this is set on, the desktop command 
keys are always immediately available.

Those who wish to keep mouseOverForKeyboardFocus *off* (i.e. set to 
false) and yet still have access to the desktop-keyboard-command 
shortcuts may benefit from using shift-esc to get the desktop menu 
regardless of current keyboard focus; once you have the desktop menu, 
you can issue the desktop command keys with impunity.


>That's it for now.  If I get a chance tomorrow, I'll push it around
>some more.

Thanks again, Steve.

Cheers,

   -- Scott