all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: jarekczek@poczta.onet.pl, 16051@debbugs.gnu.org
Subject: bug#16051: 24.3.50; Emacs hang - resize frame manually
Date: Tue, 24 Dec 2013 19:34:04 +0200	[thread overview]
Message-ID: <83a9fq6tmb.fsf@gnu.org> (raw)
In-Reply-To: <52B95E81.6070208@gmx.at>

> Date: Tue, 24 Dec 2013 11:14:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jarekczek@poczta.onet.pl, 16051@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.





  reply	other threads:[~2013-12-24 17:34 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 14:40 bug#16051: 24.3.50; Emacs hang - resize frame manually Drew Adams
2013-12-04 17:56 ` Eli Zaretskii
2013-12-05 14:03   ` martin rudalics
2013-12-05 17:52     ` Eli Zaretskii
2013-12-05 17:59       ` martin rudalics
2013-12-05 18:21         ` Eli Zaretskii
2013-12-05 18:27           ` martin rudalics
2013-12-05 18:30           ` Eli Zaretskii
2013-12-06 14:32             ` martin rudalics
2013-12-06 15:31               ` Eli Zaretskii
2013-12-06 16:21                 ` martin rudalics
2013-12-06 18:16                   ` Eli Zaretskii
2013-12-06 18:57                     ` martin rudalics
2013-12-06 19:07                       ` Eli Zaretskii
2013-12-07 12:25                         ` martin rudalics
2013-12-07 12:31                           ` martin rudalics
2013-12-07 13:12                           ` Eli Zaretskii
2013-12-07 14:23                             ` martin rudalics
2013-12-07 15:18                               ` Eli Zaretskii
2013-12-07 15:47                                 ` martin rudalics
2013-12-07 16:28                                   ` Eli Zaretskii
2013-12-07 17:00                                   ` Dani Moncayo
2013-12-07 17:36                                     ` martin rudalics
     [not found]                                 ` <<52A342F7.1070707@gmx.at>
     [not found]                                   ` <<83siu4zkuh.fsf@gnu.org>
2013-12-07 20:37                                     ` Drew Adams
2014-12-25 10:55   ` martin rudalics
2013-12-21 13:44 ` Jarek Czekalski
2013-12-21 15:12   ` Eli Zaretskii
2013-12-21 15:16     ` Eli Zaretskii
2013-12-21 15:46     ` Jarek Czekalski
2013-12-21 16:19       ` Eli Zaretskii
2013-12-21 17:13         ` martin rudalics
2013-12-21 18:48           ` Eli Zaretskii
2013-12-21 19:40             ` martin rudalics
2013-12-23 16:57           ` Eli Zaretskii
2013-12-23 18:44             ` martin rudalics
2013-12-23 19:31               ` Eli Zaretskii
2013-12-23 20:02                 ` martin rudalics
2013-12-23 20:18                   ` Eli Zaretskii
2013-12-24 10:14                     ` martin rudalics
2013-12-24 17:34                       ` Eli Zaretskii [this message]
2013-12-24 18:45                         ` martin rudalics
2013-12-24 18:55                           ` Eli Zaretskii
2013-12-26 11:51                             ` martin rudalics
2013-12-26 17:30                               ` Eli Zaretskii
2013-12-26 18:04                                 ` martin rudalics
2013-12-26 18:47                                   ` Eli Zaretskii
2013-12-26 19:56                                     ` martin rudalics
     [not found] <<3eea48d4-9267-45fa-84c8-3eb9c9290558@default>
     [not found] ` <<83siu833gc.fsf@gnu.org>
2013-12-04 18:45   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a9fq6tmb.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=16051@debbugs.gnu.org \
    --cc=jarekczek@poczta.onet.pl \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.