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

[martin rudalics]

>> - 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.

> 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.

> 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.

martin