bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14233: 24.3; Don't constrain frame size to character multiples


From: Jan Djärv
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 14:56:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]