GNU bug report logs - #16013
24.3.50; Rows in height is interpreted as pixels.

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "16013 <at> debbugs.gnu.org" <16013 <at> debbugs.gnu.org>
Subject: bug#16013: 24.3.50; Rows in height is interpreted as pixels.
Date: Sat, 18 Jan 2014 12:30:43 +0100

Hello.

16 jan 2014 kl. 11:03 skrev martin rudalics <rudalics <at> gmx.at>:

> 
> (1) When the window manager asks us to resize a frame, we do not
>    subtract the toolbar height.  That is, the height of the toolbar is
>    included in the frame's text height afterwards, defeating our
>    illusion that it's counted separately.  This means an even less
>    trivial fix than the one mentioned above.
> 
> (2) The real height of the toolbar is with tool_bar_height which might
>    not fit the one we assume (in x_figure_window_size) anyway.  One
>    more non-trivial fix since tool_bar_height is not available
>    initially but only after the display engine handled it.  But the
>    display engine wants the initial height of the frame so we have a
>    chicken-and-egg problem here.
> 
> (3) Lucid/Motif/No toolkit/Windows can wrap the toolbar (something Gtk
>    doesn't).  The display engine does this by stealing the necessary
>    height from the editing area - that is, the root window - and
>    autonomously updating the `tool-bar-lines' frame parameter.  This
>    complicates subsequent frame resizing since we don't know a priori
>    whether the toolbar will wrap again.
> 
> So while I agree with you that menu and tool bar should not be
> considered content, I see no easy way to work around this assumption on
> the systems in question.  Suggestions welcome.

Disable wrapping of the toolbar?

	Jan D.

Previous Next

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