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

[martin rudalics]

>>> This is insane. it means changing lots and lots of calls, and makes merging 
between branches harder.
>> Currently, change_frame_size doesn't know anything about the various
>> platforms' requirements going beyond those of the frame's text area.
>
> I don't understand what you are trying to say.

change_frame_size has no idea whether it is called for a text or a
graphical frame.  Text frames might want to call it as before using
character sizes.  Callers that are able to process pixels and want them
applied will call it with pixel sizes.  In any case, the callers have to
strip space used for tool- or menubars because change_frame_size does
not know whether these are part of the frame or not.

>>> Make a new function (change_frame_size_pixelwise for example), with the 
arguments above, and let change_frame_size call it with the last argument false.
>> And how would change_frame_size know what the new pixel dimensions of
>> the frame's text area are?
>
> As Emacs has always done, multiply by canonical character pixel size.

Doing that would just leave things as they are now.

When I maximize a frame, that frame may get a new pixel size which is
not necessarily a multiple of the frame's character size.  If I now want
to resize that frame's windows (and not leave some spare pixels at the
bottom of the frame as we do now) I have to communicate the new pixel
size of the frame's root window to the window resizing mechanism.  The
function that does that is change_frame_size.

martin