GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

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: Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 14:56:47 +0200

Hello.

2013-04-20 13:00, martin rudalics skrev:
>  >> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>  >>  requests from the window manager pixelwise to the frame and window
>  >>  resizing routines.
> [...]
>  > How does these interact with WM size hints?  Are you turning them off when
> resizing pixelwise?
>
> No.  But I've tested this on Windows only where in an initial stage I
> did in x_wm_set_size_hint
>
> SetWindowLong (window, WND_FONTWIDTH_INDEX, 1);
> SetWindowLong (window, WND_LINEHEIGHT_INDEX, 1);
>
> which worked.  But later I found out that this was not needed - all I
> had to do was turning off rounding in the case of WM_WINDOWPOSCHANGING
> in w32_wnd_proc.
>
> So you will probably have to tell me on which platforms turning off WM
> size hints is needed.

We should not turn off WM size hints on any platform IMHO.  If we do that, the 
resize feedback from the window manager shows pixels instead of rows x 
columns.  The latter is much more useful.  I don't understand why we want to 
resize in pixels instead of characters.

But if you insist on resizing with pixels instead of characters, you have turn 
WM hints off for NS and X.  You should thoroughly test this change on X with a 
couple of different window manager before checking it in.  Resizing is a bit 
of a mess on X because the intreactions with the window manager, and the 
strange ways Emacs deals with GUI elements.

>
>  > Are you proposing that the width of the scroll bar and the fringe be
> included in the text width?  You need to explain this better.
>
> Yes.  Have you tried the scenario of bug#14222 ?  I think it's a direct
> consequence of the dichotomy that OT1H we do want changing fringe widths
> affect the size of the frame on the screen but OTOH do not want these
> changes to have any impact immediately.
>
> BTW: When the toolbar is part of the frame we do include its height in
> the frame's text height (obviously so, because otherwise wrapping the
> toolbar would resize the frame) and IIUC we always include margins in
> the frame's text width but do refuse to so with fringes and scrollbars.

I'd rather see that text is text.  Fringe and scrollbars should not be 
included, nor should margins or borders.  Non-text portions should be able to 
have any width/height in pixels.  This includes the native toolbar.

But I'd prefer if the text part is resizable only in terms of lines/columns. 
An exception to this is tiling window managers and fullscreen behaviour.

So resizing fringes and scrollbars ought to resize the frame.

>
>  > This is dependent on the port.  For the Gtk+ port, toolbar and menubar
> height has no restriction to be in lines.  A value > 0 means "on".  The actual
> height is not the height of a line, but whatever height the toolkit chooses.
>
> I know.  I just wanted to know whether we should do that on other ports
> as well and how to specify that.

IMHO we should do that on all ports.

	Jan D.

Previous Next

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