Re: Toolbar redraw causes unwanted selection

[JD Smith <jdsmith@as.arizona.edu>]

On Dec 15, 2006, at 2:24 PM, Richard Stallman wrote:

>> The reason I suggest waiting for C-l (or maybe for something else)
>> before making it smaller is that I think the frequent changes
>> in tool bar size, when switching back and forth between two windows,
>> could be annoying for the user.
>
>     I don't see an easy way to implement the "wait for C-l" -- and  
> for the
>     case at hand, it doesn't even solve the problem, as the abnormal
>     behaviour happens when the toolbar size is increased.
>
> You are right; this bug would still have to be fixed at the low level.
>
> Nonetheless, the change I suggest in the auto-resize behavior would
> avoid a behavior that might be quite annoying.  It only takes two
> characters to switch windows, and I often do that a few times in a
> row.  If the toolbar were to change size each time, it would be
> very distracting.  If it were to remain enlarged until I type C-l
> to let it shrink back down, that distraction would be gone.

As someone who often switches rapidly between row and 1-row toolbar  
windows (a C buffer and an IDLWAVE buffer, for instance), I can  
confirm that the constant resizing is a bit annoying -- though much  
less than the original unintended selection.  One toolbar size per  
frame would seem a good idea, based on the maximum number of rows  
required for all windows in that frame.  This way, as buffers are  
switched to other modes/etc., the toolbar resizes, but simply  
switching windows (by clicking, C-x o, etc.) won't trigger the resize.

Post-release, it would also be very nice to be able to specify the  
addition of a new row of toolbar buttons independent of frame width,  
for modes which append to the original set of buttons.  This would  
also result in less churn in toolbar height, and would be more  
visually appealing for modes which add a themed set of icons.

JD