GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 10:53:52 +0200

>> ** 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.  What
might be lacking is a better interface specification.  So far I have:

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

Some issues still deserve discussion:

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

- 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)?

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

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

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

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

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.