emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Toolbar redraw causes unwanted selection


From: Kim F. Storm
Subject: Re: Toolbar redraw causes unwanted selection
Date: Tue, 19 Dec 2006 11:02:28 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

JD Smith <address@hidden> writes:

> 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.  

So why don't you turn it off then?

>                                               One toolbar size per
> frame would seem a good idea, 

That's already what tool-bar-lines in frame-paramteres do.

>                               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.

That's a nice idea, but quite impractical.  The tool-bar may depend on
a keymap property at specific buffer positions, so how can you know
what's needed?

I think the only practical approach is an explicit "grow-only" setting
for auto-resize-tool-bars, and then define some specific commands
which may reduce the toolbar size (e.g. C-l as RMS suggested).

> 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.

I'm not sure I understand.  Do you want a "line break" in the toolbar
lines or ?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]