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: 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 13:01:52 +0200

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

There are some subtle issues.  Suppose I now have two adjacent windows
each 200 pixels high.  I have to give these windows suitable line
heights.  Giving them both either 12 lines or 13 lines will break
calculations based on the return values of `window-edges'.  So I have to
give one of these windows 12 lines and the other 13 lines although their
pixel heights are exactly the same.

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

But on Windows the toolbar is included in the frame's text height and
sometimes even the menubar is.  And the display margins, whether outside
or inside the fringes, are part of the text width.  Aren't these mental
dissonances as well?

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

OK

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

OK

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

I had in mind the case where toolbar elements and borders asked for some
arbitrary pixel height.  IIUC we currently do some rounding there to fit
them into screen line multiples.  Such rounding would not be needed any
more.

It goes without saying that clipping the toolbar doesn't make sense.
Note in this context that on Windows the toolbar is allowed to occupy
the entire frame, obscuring everything else, something we are usually
trying to avoid like the plague.

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

Hopefully.  There are some wrinkles with display areas not getting
cleared appropriately but these existed already with non-pixelwise
resizing.

martin

Previous Next

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