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

[martin rudalics <rudalics@gmx.at>]

 > WM hints tell the window manager the width increment and height
 > increment that the Emacs frame wants to be resized in.  This means when
 > a user resizes by dragging the window border, the window manager only
 > allows resize increments by the specified width/height increments.

At least for the window manager of Windos XP this is not true.

 > So
 > there is no half characters showing.  In addition, when resize occurs
 > some, not all, window managers shows the size while resizing.  When
 > width/height increments have been set, the WM shows the size in these
 > units, which for Emacs translates to rows and columns.

Again with Windows XP resizing an Emacs frame shows the new sizes
pixelwise.  Only when releasing the mouse button the frame snaps back to
its previous size unless I made it beyond the character size barrier.
But in this case it's just Emacs not honoring the WM's request.

 > This does not mean that the toolbar, menubar, scrollbar, fringe etc. has
 > to be in a multiple of these increments.  In addition to the increments,
 > you also specify a base width/height in pixels.  That base width/height
 > is the non-text portions width/height.

Can you explain what the base width/height is?  Something like a minimum
size?

 > So at any time the WM maintains the invariant:
 >    width = base width + n x width increment
 >    height = base height + m x height increment
 >
 > n, m are integers.
 >
 > You can also specify a minimum size, but that is not relevant to this
 > issue.

A minimum size for what?

 > Note that for fullscreen, the WM does not keep this invariant, nor does
 > tiling window managers.

What about maximized frames?

 > For other types of resize (i.e. interactive
 > with the mouse) I'd like to keep the WM size hints, because it is more
 > userfriendly.

 From the Emacs POV this is easy: I could accept `frame-resize-pixelwise'
being a list that enumerates all WM operations that should be
interpreted pixelwise and have t stand for "all are pixelwise" and nil
for "none are".  The problem is that IIUC a maximize frame request
should be interpreted pixelwise but comes in just as a plain resize
request.  What are your experiences in this regard?  How does ns do
that?

 > If we want to make windows display partial lines that is OK, and even
 > preferrable for the fullscreen/tiling case, but we should not disregard
 > WM size hints for the other case.

I agree with you.  But we should make them customizable.

 >>> But I'd prefer if the text part is resizable only in terms of
 >>> lines/columns.
 >>
 >> Why?  Is there any other reason beyond WM hints?
 >
 > Usability.  For example, all terminal emulators does this.

OK.  But this should not impede us from providing an adequate graphical
implementation.

 >>> An exception to this is tiling window managers and fullscreen behaviour.
 >>
 >> If we cannot resize in pixels, we cannot make those exceptions, can
 >> we?
 >
 > We only need to make Emacs windows be resizable in pixels, not the frame
 > as I tried to explain above.

Tiling, fullscreen and maximization requests are all incarnations of
pixelwise resizing of frames.  How else would you call them?

martin