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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 10:53:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Glenn Morris <rgm@gnu.org>, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> ** Remove the limitation that window and frame widths and heights can
>  >>   be only full columns/lines.
>  >
>  > Right.  And I don't think the wording of the problem in both cases is
>  > accurate enough.  There is no such limitation, except in functions
>  > that actually resize the frame/window.  The display engine doesn't
>  > require integral number of character cells.
>  >
>  > So, if someone wants to bite the bullet, the way to go is:
>  >
>  >   . introduce interfaces to specify frame/window size in pixels
> 
> I'm mostly done with the low-level parts of the implementation.

Thanks.

> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>    requests from the window manager pixelwise to the frame and window
>    resizing routines.
> 
> - An option `window-resize-pixelwise' which, when non-nil, makes some
>    window resize functions (like `adjust-window-trailing-edge' or
>    `fit-window-to-buffer') operate pixelwise.
> 
> - Functions like `window-resize', `split-window' or `set-frame-size'
>    take an optional argument PIXELWISE which means to interpret their
>    size/delta/width/height argument pixelwise.

Sounds reasonable to me.  It might be a good idea to release this
as-is, and wait for comments and complaints by those who will use
them.

> - The window resize routines work pixelwise although when resizing I
>    still try to preserve full lines/columns first and give the remainder
>    to one window only.  That is, if I have three windows and 90 pixels
>    height to distribute, by default I assign 32, 32 and 26 pixels instead
>    of 30 pixels to each.  If you prefer a different solution tell me - I
>    have no strong opinion here.

I think what's important is to have a way of resizing a specific
window to a specific pixel-size.  What happens to other windows as
result is less important.

> - We currently include a frame's fringe widths and scroll bar widths in
>    the frame's pixel width but not in the frame's text width.  This is
>    very inconvenient on graphic systems and leads to all sorts of subtle
>    bugs like bug#14222.  Do we really care about this distinction or
>    could we simply say that specifying a frame's width specifies also the
>    width of that frame's root window (minus the internal border width)?

The fact that the fringes and the scroll bar are excluded from the
dimensions of the text area sounds correct to me.  Otherwise, it would
be confusing to have non-text portions included in the text area
dimensions, and could lead to subtle bugs due to this mental
dissonance.

What is the relation of these frame dimensions to the frame's root
window, though?  Can we handle the problem on that level, i.e. when
computing window dimensions from frame dimensions?

> - IIUC we currently do not allow to specify the sizes of display margins
>    pixelwise.  Are we interested in lifting this restriction?  We would
>    have to invent suitable terms for these.

Display margins are very rarely used.  I don't recommend enhancing
them without an explicit request and a use case that really requires
that.

> - We currently round fringe widths (in compute_fringe_widths) and scroll
>    bar widths (in x_set_scroll_bar_width) to columns.  Is this still
>    desirable or shall this be lifted too?

Should probably be lifted, but it doesn't have to be part of the
initial change that gets committed.

> - The heights of the tool and menubar are specified in lines.  Do we
>    intend to change that to pixels?

I don't think so: clipping the displayed stuff in these "windows"
doesn't make sense, IMO.  IOW, a tool bar whose icons are only
partially visible is ugly, and I'm not aware of a single application
that does that.  Likewise with the menu bar (only applicable to a
non-toolkit X build, btw).

>  >   . in the implementation of those interfaces, round up the sizes in
>  >     column and line units to the integral numbers, so that the glyph
>  >     matrices are large enough
> 
> I tried to do that.  Usually, the display routines are so robust that
> hardly anything could ever break them.

You should only need to do that where we allocate glyph matrices.