GNU bug report logs - #16051
24.3.50; Emacs hang - resize frame manually

Previous Next

Full log

Message #122 received at 16051 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
Subject: Re: bug#16051: 24.3.50; Emacs hang - resize frame manually
Date: Tue, 24 Dec 2013 19:34:04 +0200

> Date: Tue, 24 Dec 2013 11:14:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jarekczek <at> poczta.onet.pl, 16051 <at> debbugs.gnu.org
> 
>  >>  > If you are right, then I'm confused: the call to
>  >>  > Fmodify_frame_parameters that changes the tool-bar-lines parameter
>  >>  > leads to a call to x_set_tool_bar_lines, which in turn resizes the
>  >>  > tool-bar window.  And the value is certainly not always 1, I've seen
>  >>  > it as large as 7.
>  >>
>  >> This must be the display code which takes the deviation via the frame
>  >> parameter to communicate the new size to resize_frame_windows.  Not very
>  >> clean IMHO.
>  >
>  > No, that's not what happens.  What happens is this call sequence:
>  >
>  >   Fmodify_frame_parameters
> 
> Who calls Fmodify_frame_parameters here?  It's redisplay_tool_bar in
> 
>        if (new_height != WINDOW_PIXEL_HEIGHT (w))
>            ...
> 	  Fmodify_frame_parameters (frame,
> 				    list1 (Fcons (Qtool_bar_lines,
> 						  make_number (new_lines))));
> 
> discovering that the present line doesn't suffice.

Right.

> /* Max tool-bar height.  Basically, this is what makes all other windows
>     disappear when the frame gets too small.  Rethink this!  */
> 
> #define MAX_FRAME_TOOL_BAR_HEIGHT(f) \
>    ((FRAME_LINE_HEIGHT (f) * FRAME_LINES (f)))
> 
> This means that the toolbar is allowed to grasp the whole frame, killing
> everything else.

Yes, it is.  Not very nice, but if the user wants that, she will get
what she asks for.

>  >> No.  I meant to keep the frame size fixed at some minimum value and let
>  >> the window manager do the clipping - just as it does now.
>  >
>  > The frame size should remain as it was -- as the user determined by
>  > dragging.
> 
> But this means that we currently do change the frame size.

I think we are miscommunicating, because we certainly don't change the
frame size; the user does.

>  > We should not change it.  The question is what value should
>  > we limit the tool bar to, given those constraints, and how much space
>  > should we leave to the rest of the root window of the frame.
> 
> What we do when there's no toolbar, I presume.  That is, if there's not
> enough space, then kill the toolbar.

That's too drastic I think.  We are perfectly capable of displaying
the tool bar truncated to the part that can be rendered.  If the user
doesn't like that, she can always turn off the tool bar manually.
After all, it's the user who caused this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.