Re: Help with partial line needed (was: Bad resizing upon detaching/reattaching GTK toolbar)

Re: Help with partial line needed (was: Bad resizing upon detaching/reattaching GTK toolbar)

[Jan D.]

There is definitly some bug in fluxbox, it sends the most crazy 
configure notify events to Emacs when the tool bar is detached.  It 
usually sends three, two correct ones and one that is off by about 5 
pixels.  It is those missing 5 pixels that shrinks the window (i.e. 
Emacs rounds it to an even line).  There should only be one configure 
notify.

Emacs is special in the way it handles (or rather the GTK version) 
detaching and attaching of the tool bar.  It tries to keep the same 
lines as before, thus the resizing and the configure notify events.

I see that other applications instead keeps the total pixel size, so 
then no configure notify is sent (the frame size is kept).  I can change 
to that behaviour, but since the tool bar height may not be a multiple 
of the line height (as it is in other Emacs ports), there will most 
probably be a partial line.  And that partial line is the minibuffer.  
It would be better if that partial line was in a non-minibuffer.   Does 
anybody know how to achive that (I just call change_frame_size)?

There are another race condition involving configure notify and tool bar 
attach/detach, but they happen very seldom, and usually ends up growing 
the Emacs frame rather than shrink it.  The fluxbox behaviour is not 
changed by fixing that race condition.  I haven't checked in the fix for 
the race condition.  If there is a way to force the partial line to a 
non-minibuffer I think I'll go with that solution instead.

Sorry I couldn't help.

    Jan D.

David Kastrup wrote:

>"Jan D." <jan.h.d@swipnet.se> writes:
>
>  
>
>>David Kastrup wrote:
>>
>>    
>>
>>>This bug report will be sent to the Free Software Foundation,
>>>not to your local site managers!
>>>Please write in English if possible, because the Emacs maintainers
>>>usually do not have translators to read other languages for them.
>>>
>>>Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
>>>
>>>Please describe exactly what actions triggered the bug
>>>and the precise symptoms of the bug:
>>>
>>>When one detaches and reattaches the toolbar by dragging on its
>>>handle, each time the total size of the Emacs window shrinks.  This is
>>>particularly noisome since it is not easy to reattach the toolbar
>>>without the state attached/detached flickering a few times, and each
>>>time one line of the window is gone.
>>>      
>>>
>>I can not reproduce this, what window manager are you running?
>>    
>>
>
>Fluxbox.
>
>  
>
>>Do you get the same behaviour if you disable and enable
>>tool-bar-mode?
>>    
>>
>
>First I get a backtrace.  Sigh.
>
>Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
>  signal(wrong-type-argument (keymapp nil))
>  define-key-after(nil [customize] (menu-item "customize" customize :image (image :type xpm :file "/usr/local/emacs-21/share/emacs/21.3.50/lisp/toolbar/preferences.xpm") :help "Edit preferences (customize)"))
>  tool-bar-local-item("preferences" customize customize nil :help "Edit preferences (customize)")
>  apply(tool-bar-local-item "preferences" customize customize nil (:help "Edit preferences (customize)"))
>  tool-bar-add-item("preferences" customize customize :help "Edit preferences (customize)")
>  tool-bar-setup()
>  tool-bar-mode(toggle)
>  call-interactively(tool-bar-mode)
>  execute-extended-command(nil)
>  call-interactively(execute-extended-command)
>
>Then the frame gets oversized (namely, the text window size does not
>shrink to accommodate the toolbar size, and consequently the
>minibuffer gets off-screen).  If I disable the toolbar again, the
>frame shrinks to normal size again, as the window size stays the same.
>However, this first toggling is "neutral" only because of the back
>trace, apparently (I have debug-on-error set to t).
>
>The next time I call tool-bar-mode (no backtrace this time), the
>window-size _adapts_ to the reduced space.  Disabling tool-bar-mode
>again, the window does _not_ adapt to the additional space again.
>
>After that, enabling the toolbar makes the size adapt, so the frame
>size stays more or less the same while the window size shrinks, and
>disabling the toolbar lets the window size stay the same, thus causing
>the frame to shrink.
>
>The same happens when detaching and reattaching the toolbar: detach
>the toolbar, and the window does not grow in spite of the additional
>space, attach it again, and the window shrinks.
>
>Maybe this is an effect of the combination of my line height and the
>size of the toolbar?  I use 10x20 as my normal font, and the startup
>geometry is 80x35.
>
>My X resources contain Emacs.toolBar: 0, so I don't have a toolbar on
>startup normally.
>
>  
>

Re: Help with partial line needed

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> There is definitly some bug in fluxbox, it sends the most crazy
> configure notify events to Emacs when the tool bar is detached.  It
> usually sends three, two correct ones and one that is off by about 5
> pixels.  It is those missing 5 pixels that shrinks the window
> (i.e. Emacs rounds it to an even line).  There should only be one
> configure notify.
>
> Emacs is special in the way it handles (or rather the GTK version)
> detaching and attaching of the tool bar.  It tries to keep the same
> lines as before, thus the resizing and the configure notify events.

Hm.

> I see that other applications instead keeps the total pixel size, so
> then no configure notify is sent (the frame size is kept).  I can
> change to that behaviour, but since the tool bar height may not be a
> multiple of the line height (as it is in other Emacs ports), there
> will most probably be a partial line.  And that partial line is the
> minibuffer.  It would be better if that partial line was in a
> non-minibuffer.  Does anybody know how to achive that (I just call
> change_frame_size)?

More concretely: it would be perfect if the _whole_ area from the
toolbar was added to the window immediately below the toolbar, and if
at the same time vscrol was adjusted by that amount, so that detaching
and reattaching the toolbar would not cause any text to move on the
screen.  There may be exceptions:
a) if the buffer display is already at the beginning of the buffer
when the toolbar gets detached, the window contents will have to move
up.
b) if attaching the toolbar moves the cursor off-screen, recentering
will become necessary.

And of course, the toolbar can't be attached in that manner if the top
window does not have the space to accommodate it.

> There are another race condition involving configure notify and tool
> bar attach/detach, but they happen very seldom, and usually ends up
> growing the Emacs frame rather than shrink it.  The fluxbox
> behaviour is not changed by fixing that race condition.  I haven't
> checked in the fix for the race condition.  If there is a way to
> force the partial line to a non-minibuffer I think I'll go with that
> solution instead.

That sounds much better.

> Sorry I couldn't help.

Well, if the problem with fluxbox could be wrapped in a bug report and
sent to the maintainers, this _could_ help.  For me, the effect is not
overly tragic since I usually don't use the toolbar, let alone detach
it.  Detached, I'd consider it quite more useful if it would be
vertically arranged, but I have no clue about what GTK+ might offer in
that respect.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Help with partial line needed

[Jan D.]

David Kastrup wrote:

>Sorry I couldn't help.
>  
>
>
>Well, if the problem with fluxbox could be wrapped in a bug report and
>sent to the maintainers, this _could_ help.  For me, the effect is not
>overly tragic since I usually don't use the toolbar, let alone detach
>it.  Detached, I'd consider it quite more useful if it would be
>vertically arranged, but I have no clue about what GTK+ might offer in
>that respect.
>
>  
>

I could perhaps wrap it in a smaller program, but currently I have not 
much time to spare.  The explanation seems to be some race condition or 
invalid caching of information in fluxbox.  This happens for me:

Emacs frame has a height of 783 pixels.  The base height is 63 pixels, 
and the height increment is 15 (see XSetWMSizeHints).  63 is the menu 
bar and the tool bar.  15 is the line height.  I have 48 lines, so 63 + 
15*48 = 768.  Everything is OK.

I detach the tool bar (38 pixels), so Emacs sets the base height to 27 
(63 - 36, because there is a 2 pixel remnant of the tool bar when detached).
Now, 27 + 15*48 = 747, so Emacs resizes the frame to 747 pixels.

But fluxbox has apprently not updated the base size for Emacs, it still 
uses the old value of 63:  (747 - 63)/15 is about 45.6.  The rule as 
stated in ICCCAM is that our frame size must be base_size + n * 
height_increment, so fluxbox drops the reminder and sends a 
ConfigureNotify to Emacs with the height 738 (63 + 15*45).

Emacs adapts to this (there is no way to tell that this wasn't a user 
resize), so the frame shrinks.

If I detach and attach slowly, it usually works OK, so I guess there is 
a timing problem in fluxbox.

    Jan D.