size hints and tiling window managers

size hints and tiling window managers

[Jonas Bernoulli]

Hello

On X11 Emacs provides size hints to the window manager, which the latter
may choose to ignore.  When that happens Emacs paints the extra space at
the right and/or bottom with the background color of the default face.

There are legitimate reasons why a window manager chooses to ignore size
hints.  E.g. tiling window managers (dwm, awesome, xmonad, wmii, i3...)
place windows next to each using all available space and without any
window covering part of another window.

In other words tiling wms arrange (X11) windows as Emacs arranges
(Emacs) windows in an (Emacs) frame.

A tiling wm has several options how to deal with windows that provide
size hints.

1. Respect the hints and make the borders thicker, so that the window +
   the borders fill up the intended space.  Ugly.

2. Respect the hints, draw the border around it, and fill the space that
   is left using some "in between windows" color.  Also quite ugly.

3. Ignore the hints leaving it to the client to do something with the
   extra space.  This is what most tiling wms do, because the result
   *usually* looks good enough.

4. Respect the size hints and paint the extra space using some color
   instead of letting the client do it.  I am not aware of a wm that
   does this (it might have to use different colors for different
   clients).

When a terminal emulators is forced to paint some extra space because
the wm does not respect the size hints it does so using the background
color.

Emacs does the same thing: it paints the extra space using the
background color of the default face.  The problem is that Emacs frames
may also have fringes which usually don't have the same background
color.  As a result Emacs draws a "line" with the same color as *the*
background color to the right of the right fringe (and below the echo
area).

To work around the resulting ugliness I just did not use a right fringe,
but I don't want to do that any longer.

There are at least two better ways in which Emacs could deal with wms
not respecting size hints:

1. A quick (and not so bad) work-around would be to make the color used
   to paint the extra space independent of the background color of the
   default face.  This way users of tiling wms could just set it to the
   background color of the fringe instead.  Currently the following does
   not work:

   (set-frame-parameter (selected-frame)
                        'background-color
                        (face-attribute 'fringe :background))

   as it also changes the default background.

2. However I think it would be better if Emacs would just use any window
   size without having to paint some extra space to the right and below
   of the "actual" content.  One way of doing that could be to
   dynamically adjust the width of the fringes (and the height of the
   minibuffer/echo area).

I understand that implementing the latter probably isn't easy to do, so
I am already happy if someone could separate the default and "extra
space" backgrounds as suggested first.

But please also consider the second suggestion.  Since buffers can
contain text that have a different width than that of the default face
relying on size hints does not guarantee that text is never cut of in
the middle of a character.  And keep in mind that you would be doing
this for the benefit of tiling wms - the Emacsen among the window
managers :-)

  Best regards,
  Jonas

Re: size hints and tiling window managers

[martin rudalics]

 > 2. However I think it would be better if Emacs would just use any window
 >    size without having to paint some extra space to the right and below
 >    of the "actual" content.  One way of doing that could be to
 >    dynamically adjust the width of the fringes (and the height of the
 >    minibuffer/echo area).
 >
 > I understand that implementing the latter probably isn't easy to do, so
 > I am already happy if someone could separate the default and "extra
 > space" backgrounds as suggested first.

Eli said that he can provide arbitrary frame pixel sizes at any time.

martin

Re: size hints and tiling window managers

[Eli Zaretskii]

> Date: Fri, 07 Dec 2012 11:35:36 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  > 2. However I think it would be better if Emacs would just use any window
>  >    size without having to paint some extra space to the right and below
>  >    of the "actual" content.  One way of doing that could be to
>  >    dynamically adjust the width of the fringes (and the height of the
>  >    minibuffer/echo area).
>  >
>  > I understand that implementing the latter probably isn't easy to do, so
>  > I am already happy if someone could separate the default and "extra
>  > space" backgrounds as suggested first.
> 
> Eli said that he can provide arbitrary frame pixel sizes at any time.

Yes, but before that has any chance of happening, Someone™ should step
forward to help maintaining the Windows build, because lately that
eats up almost all of my free time, leaving just barely enough for
fixing redisplay related bugs.  I have no time left for developing
significant new display features.  As just one example, I wrote code
to support drop-down menus on TTYs, which eats dust on a local branch
awaiting testing since June(!), because I have no time to spend on it.

Re: size hints and tiling window managers

[James Cloos]

>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:

mr> Eli said that he can provide arbitrary frame pixel sizes at any time.

Doesn't it just require not setting the .width_inc and .height_inc
members of the size_hints struct in src/xterm.c and src/gtkutil.c,
and editing the .min_width and .min_height code to account for that?

Something like the (as yet untested, and X-only) code below?

If so, I presume that it should be configurable, yes?

That would require some effort to work out.

-JimC

=== modified file 'src/gtkutil.c'
--- src/gtkutil.c	2012-12-03 19:15:52 +0000
+++ src/gtkutil.c	2012-12-08 01:35:39 +0000
@@ -1357,9 +1357,7 @@
   size_hints = f->output_data.x->size_hints;
   hint_flags = f->output_data.x->hint_flags;
 
-  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
-  size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = FRAME_LINE_HEIGHT (f);
+  hint_flags |= GDK_HINT_MIN_SIZE;
 
   hint_flags |= GDK_HINT_BASE_SIZE;
   /* Use one row/col here so base_height/width does not become zero.
@@ -1374,8 +1372,8 @@
 
   size_hints.base_width = base_width;
   size_hints.base_height = base_height;
-  size_hints.min_width  = base_width + min_cols * size_hints.width_inc;
-  size_hints.min_height = base_height + min_rows * size_hints.height_inc;
+  size_hints.min_width  = base_width + min_cols * FRAME_COLUMN_WIDTH (f);
+  size_hints.min_height = base_height + min_rows * FRAME_LINE_HEIGHT (f);
 
   /* These currently have a one to one mapping with the X values, but I
      don't think we should rely on that.  */

=== modified file 'src/xterm.c'
--- src/xterm.c	2012-12-04 15:15:05 +0000
+++ src/xterm.c	2012-12-08 01:34:26 +0000
@@ -9534,8 +9534,6 @@
   size_hints.height = FRAME_PIXEL_HEIGHT (f);
   size_hints.width = FRAME_PIXEL_WIDTH (f);
 
-  size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = FRAME_LINE_HEIGHT (f);
   size_hints.max_width = x_display_pixel_width (FRAME_X_DISPLAY_INFO (f))
     - FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
   size_hints.max_height = x_display_pixel_height (FRAME_X_DISPLAY_INFO (f))
@@ -9564,8 +9562,8 @@
     size_hints.flags |= PBaseSize;
     size_hints.base_width = base_width;
     size_hints.base_height = base_height + FRAME_MENUBAR_HEIGHT (f);
-    size_hints.min_width  = base_width + min_cols * size_hints.width_inc;
-    size_hints.min_height = base_height + min_rows * size_hints.height_inc;
+    size_hints.min_width  = base_width + min_cols * FRAME_COLUMN_WIDTH (f);
+    size_hints.min_height = base_height + min_rows * FRAME_LINE_HEIGHT (f);
   }
 
   /* If we don't need the old flags, we don't need the old hint at all.  */



-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: size hints and tiling window managers

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Date: Fri, 07 Dec 2012 20:42:00 -0500
> Cc: martin rudalics <rudalics@gmx.at>, Jonas Bernoulli <jonas@bernoul.li>
> 
> >>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
> 
> mr> Eli said that he can provide arbitrary frame pixel sizes at any time.
> 
> Doesn't it just require not setting the .width_inc and .height_inc
> members of the size_hints struct in src/xterm.c and src/gtkutil.c,
> and editing the .min_width and .min_height code to account for that?

If you are asking me, I don't think I understand the problem well
enough to answer.  For starters, I don't understand how the "extra
space" you were talking about in your original report came into
being.  Specifically, what did Emacs ask for and what did the window
manager do instead?

> Something like the (as yet untested, and X-only) code below?

Maybe I'm missing something, but all your changes do is refrain from
setting the width_inc and height_inc members of the XSizeHints
structure.  Can you explain how does this solve the problem?  Emacs
_does_ want its frame size be a multiple of FRAME_COLUMN_WIDTH; if we
don't ask the wm to do that, won't that produce bad display on _all_
window managers, instead of just some that ignore the hints?  And when
a wm is involved that doesn't honor the increment hints, what will
happen if we don't set those members of the XSizeHints structure?

> If so, I presume that it should be configurable, yes?

I'd prefer we fix this particular problem:

> Emacs does the same thing: it paints the extra space using the
> background color of the default face.  The problem is that Emacs frames
> may also have fringes which usually don't have the same background
> color.  As a result Emacs draws a "line" with the same color as *the*
> background color to the right of the right fringe (and below the echo
> area).

Can you show a screenshot of this?  Also, what would be a good
solution to this problem? make the right fringe wider? something else?

> 2. However I think it would be better if Emacs would just use any window
>    size without having to paint some extra space to the right and below
>    of the "actual" content.  One way of doing that could be to
>    dynamically adjust the width of the fringes (and the height of the
>    minibuffer/echo area).

Changing the width of the fringes dynamically is easy, actually,
because we already do so, albeit triggered by user commands.  Echo are
is harder, because it's just a window, so its size must currently be a
multiple of the default font's size.  Perhaps we could modify the
mode-line width instead, by changing the line-with attribute of the
mode-line face.  Can you try that?

> Since buffers can contain text that have a different width than that
> of the default face relying on size hints does not guarantee that
> text is never cut of in the middle of a character.

That is true (and Emacs already supports these situations, as you
probably know), but that's not the reason for the issue at hand.

The reason is that Emacs redisplay works in 2 distinct stages.  In the
first stage, a device-independent part of the display engine generates
a structure, called "glyph matrix", which holds, for each character
that is visible in an Emacs window, a structure called "glyph" with
sufficient information to draw that character.  Each window has its
own glyph matrix.  In the second stage, the glyph matrix is handed to
the device-dependent part of the display engine, which actually draws
the glyphs.

It should be clear that the device-independent stage _must_ produce a
glyph for every character, even if that character is only partially
visible.  And since the number of glyphs is always integer, you get
the limitation of the integral multiple of frame font's size.  IOW,
the issue here is _not_ that we cannot draw partially visible
character -- we can -- but that the glyph matrix _dimensions_ must be
integers.  The current limitation exists because asking the wm to
observe the same restrictions was the easiest way of reconciling an
internal requirement of integer dimensions of the glyph matrices with
the fact that GUI frames are drawn and sized in pixels.

Re: size hints and tiling window managers

[Jonas Bernoulli]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Eli Zaretskii writes:

> I'd prefer we fix this particular problem:
>
>> Emacs does the same thing: it paints the extra space using the
>> background color of the default face.  The problem is that Emacs frames
>> may also have fringes which usually don't have the same background
>> color.  As a result Emacs draws a "line" with the same color as *the*
>> background color to the right of the right fringe (and below the echo
>> area).
>
> Can you show a screenshot of this?


[-- Attachment #2: ignored-size-hints.png --]
[-- Type: image/png, Size: 26063 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6436 bytes --]


I have attached a screenshot that shows parts of four Emacs frames.  The
green areas are the X11 window borders and window titles drawn by the
window manager.  The cyan areas are the fringes.  In the upper left
window I have marked what I have called the "extra space" in my initial
report.

a. is the extra space between the fringe (and header-line) and the
   window border drawn by the wm. I have also called this "extra line".

b. is the extra space drawn below the minibuffer/echo area and above the
   window border drawn by the wm.

c. is both next to the fringe as well as below the minibuffer.  It's a
   corner case :-)

> Also, what would be a good solution to this problem? make the right
> fringe wider? something else?

I suggested that all "extra space" be painted using a color that can be
set independent of the background color of the default face.  (I did so
mostly because I think that it would be fairly easy do do; not because
that would solve the problem best.)

This way I could use cyan (or whatever color I use for the fringe) as
the "extra area color" to make (a) look as if it were part of the right
fringe.  (b) and (c) would still look wrong, as would the space next to
a header-line.

Making the right (or both) fringe wider is also something that I
considered.

>> 2. However I think it would be better if Emacs would just use any window
>>    size without having to paint some extra space to the right and below
>>    of the "actual" content.  One way of doing that could be to
>>    dynamically adjust the width of the fringes (and the height of the
>>    minibuffer/echo area).
>
> Changing the width of the fringes dynamically is easy, actually,
> because we already do so, albeit triggered by user commands.

I actually tried that approach.  I calculated the width of (a) and then
adjusted the width of the fringes accordingly.

,----
| (let ((d (- (frame-pixel-width)
|             (* (frame-width)
|                (frame-char-width)))))
|   (set-frame-parameter (selected-frame) 'left-fringe
|                        (/ d 2))
|   (set-frame-parameter (selected-frame) 'right-fringe
|                        (+ (/ d 2) (% d 2))))
`----

The result were wider fringes but the "extra space" did not go away, it
just changed it's width.

The size hint provided to the wm is still "make the width of the window
be a multitude of w" (w being the width of the default face).  The wm
still ignore the hint and Emacs still paint the resulting extra space
using the background color of the default face.  The width of the extra
space is likely different but it becoming 0 would be a coincidence.

So adjusting the width of the fringes can be part of the solution but
then Emacs would have to also detect that the fringes' pixel width isn't
a multitude of the character width and act accordingly:

,----
| (if (= (% (- (frame-pixel-width)
|              (frame-parameter (selected-frame) 'left-fringe)
|              (frame-parameter (selected-frame) 'right-fringe))
|           (frame-char-width))
|        0)
|     dont-paint-extra-space
|   paint-extra-space) ; or better adjust fringe width here
`----

It appears that Emacs currently does something like this instead:

,----
| (if (= (% (frame-pixel-width)
|           (frame-char-width))
|        0)
|     dont-paint-extra-space
|   ;; for each window in frame and for simplicity pretending
|   ;; each window uses full width of frame and has fringes:
|   (let ((d (- (frame-width)
|               (window-width window)
|               (truncate (frame-parameter (selected-frame) 'left-fringe))
|               (truncate (frame-parameter (selected-frame) 'right-fringe)))))
|     (unless (= d 0)
|       (grow-or-shrink-window window d))) ; text area
|   paint-extra-space)
`----

> Echo area is harder, because it's just a window, so its size must
> currently be a multiple of the default font's size.  Perhaps we could
> modify the mode-line width instead, by changing the line-with
> attribute of the mode-line face.  Can you try that?

Adjusting the mode-line height would very likely result in the same
problem as adjusting the fringe width.

> It should be clear that the device-independent stage _must_ produce a
> glyph for every character, even if that character is only partially
> visible.  And since the number of glyphs is always integer, you get
> the limitation of the integral multiple of frame font's size.  IOW,
> the issue here is _not_ that we cannot draw partially visible
> character -- we can -- but that the glyph matrix _dimensions_ must be
> integers.  The current limitation exists because asking the wm to
> observe the same restrictions was the easiest way of reconciling an
> internal requirement of integer dimensions of the glyph matrices with
> the fact that GUI frames are drawn and sized in pixels.

I understand why the width of the text area has to be an integer and am
aware that it partially visible characters can be drawn; and why that is
a good thing.

But the width of the fringes could still be dynamically adjusted to make
up for extra pixels when frame-pixel-width / frame-char-width isn't an
integer.

On my system the default font width is 9.  Therefor X11 windows can be
at most 8 pixels to width to be a multitude of frame-pixel-width.  Since
I use both fringes each fringe (having a integer width of 1) should be
dynamcically adjusted to have a pixel width of between 9 and 13 pixels.

If I understood you correctly you agree that could be an option; but as
I have tried to explain above that cannot be done from elisp at the
moment because Emacs ignores the pixel width of the fringes when setting
the character width of the text area.

>> From: James Cloos <cloos@jhcloos.com>
>> Doesn't it just require not setting the .width_inc and .height_inc
>> members of the size_hints struct in src/xterm.c and src/gtkutil.c,
>> and editing the .min_width and .min_height code to account for that?

> Maybe I'm missing something, but all your changes do is refrain from
> setting the width_inc and height_inc members of the XSizeHints
> structure.  Can you explain how does this solve the problem?

It seems that you think the above was written by the same person as the
original report.  It is not.

I agree with you that all this does is to not provide size hints and
that as a result the display problems that are now limited to wms that
ignore size hints would instead affect all wms.

  Best,
  Jonas

Re: size hints and tiling window managers

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: "James Cloos" <cloos@jhcloos.com>, emacs-devel@gnu.org, rudalics@gmx.at
> Date: Sun, 09 Dec 2012 20:23:30 +0100
> 
> I have attached a screenshot that shows parts of four Emacs frames.  The
> green areas are the X11 window borders and window titles drawn by the
> window manager.  The cyan areas are the fringes.  In the upper left
> window I have marked what I have called the "extra space" in my initial
> report.

Thanks.  I wanted to be sure I understand the problem.

> > Changing the width of the fringes dynamically is easy, actually,
> > because we already do so, albeit triggered by user commands.
> 
> I actually tried that approach.  I calculated the width of (a) and then
> adjusted the width of the fringes accordingly.
> 
> ,----
> | (let ((d (- (frame-pixel-width)
> |             (* (frame-width)
> |                (frame-char-width)))))
> |   (set-frame-parameter (selected-frame) 'left-fringe
> |                        (/ d 2))
> |   (set-frame-parameter (selected-frame) 'right-fringe
> |                        (+ (/ d 2) (% d 2))))
> `----
> 
> The result were wider fringes but the "extra space" did not go away, it
> just changed it's width.

This cannot be done from Lisp, only from C.  Sorry, I should have made
myself clear.

> > Echo area is harder, because it's just a window, so its size must
> > currently be a multiple of the default font's size.  Perhaps we could
> > modify the mode-line width instead, by changing the line-with
> > attribute of the mode-line face.  Can you try that?
> 
> Adjusting the mode-line height would very likely result in the same
> problem as adjusting the fringe width.

Maybe so, but did you actually try that?  The display engine surprised
me more than once.

> > It should be clear that the device-independent stage _must_ produce a
> > glyph for every character, even if that character is only partially
> > visible.  And since the number of glyphs is always integer, you get
> > the limitation of the integral multiple of frame font's size.  IOW,
> > the issue here is _not_ that we cannot draw partially visible
> > character -- we can -- but that the glyph matrix _dimensions_ must be
> > integers.  The current limitation exists because asking the wm to
> > observe the same restrictions was the easiest way of reconciling an
> > internal requirement of integer dimensions of the glyph matrices with
> > the fact that GUI frames are drawn and sized in pixels.
> 
> I understand why the width of the text area has to be an integer and am
> aware that it partially visible characters can be drawn; and why that is
> a good thing.

Actually, the above was written in the hope to make clear that the
width of the text area does _not_ have to be an integer number of
frame font's width units.  The dimensions of the glyph matrix must be
inger, of course, but the last glyph can be only partially visible.
IOW, the matrix dimensions should be computed as the round-up of the
result of dividing the window width by the width of the default font.

> >> From: James Cloos <cloos@jhcloos.com>
> >> Doesn't it just require not setting the .width_inc and .height_inc
> >> members of the size_hints struct in src/xterm.c and src/gtkutil.c,
> >> and editing the .min_width and .min_height code to account for that?
> 
> > Maybe I'm missing something, but all your changes do is refrain from
> > setting the width_inc and height_inc members of the XSizeHints
> > structure.  Can you explain how does this solve the problem?
> 
> It seems that you think the above was written by the same person as the
> original report.

No, I don't think I did.  (Why does that matter, anyway?)

> I agree with you that all this does is to not provide size hints and
> that as a result the display problems that are now limited to wms that
> ignore size hints would instead affect all wms.

OK, so we are in violent agreement.

Re: size hints and tiling window managers

[Jonas Bernoulli]

Eli Zaretskii writes:

>> > Echo area is harder, because it's just a window, so its size must
>> > currently be a multiple of the default font's size.  Perhaps we could
>> > modify the mode-line width instead, by changing the line-with
>> > attribute of the mode-line face.  Can you try that?
>> 
>> Adjusting the mode-line height would very likely result in the same
>> problem as adjusting the fringe width.
>
> Maybe so, but did you actually try that?  The display engine surprised
> me more than once.

I have tried to adjust the _height_ of the mode-line face.  This caused
the last line of the text area to be displayed only partially and the
height of the extra space below the echo area did not change as we had
hoped.

I also tried using the display property:

,----
| (setq mode-line-format
|       (list "" 'mode-line-buffer-identification
| 	      (propertize " " 'display '((space :height (30))))))
`----

Also tried the above combined with t as the value of the line-height
property of the final newline.  (Which didn't have an effect at all, the
newline was displayed as ^J and the height of the mode-line did not
change; is there actually a way to have a multi-line mode-line?)

  Jonas

Re: size hints and tiling window managers

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: cloos@jhcloos.com, emacs-devel@gnu.org, rudalics@gmx.at
> Date: Sun, 16 Dec 2012 00:33:36 +0100
> 
> I have tried to adjust the _height_ of the mode-line face.  This caused
> the last line of the text area to be displayed only partially and the
> height of the extra space below the echo area did not change as we had
> hoped.
> 
> I also tried using the display property:
> 
> ,----
> | (setq mode-line-format
> |       (list "" 'mode-line-buffer-identification
> | 	      (propertize " " 'display '((space :height (30))))))
> `----

Thanks.  I guess some of my assumptions about how the echo-area size
is determined were wrong.  I will take a look when I have time.

> is there actually a way to have a multi-line mode-line?

No.

Re: size hints and tiling window managers

[Giorgos Keramidas]

Στις 08/12/2012 10:01 πμ, ο/η Eli Zaretskii έγραψε:
 >> From: James Cloos <cloos@jhcloos.com> Date: Fri, 07 Dec 2012
 >> 20:42:00 -0500 Cc: martin rudalics <rudalics@gmx.at>, Jonas
 >> Bernoulli <jonas@bernoul.li>
 >>
 >> Emacs does the same thing: it paints the extra space using the
 >> background color of the default face.  The problem is that Emacs
 >> frames may also have fringes which usually don't have the same
 >> background color.  As a result Emacs draws a "line" with the same
 >> color as *the* background color to the right of the right fringe
 >> (and below the echo area).
 >
 > Can you show a screenshot of this?  Also, what would be a good
 > solution to this problem? make the right fringe wider? something
 > else?

FWIW, tiled windows may be slightly larger pixel-wise in at least two
directions: right *and* bottom.  So it may be useful to apply the same
solution to both the right fringe and the mode-line.

Re: size hints and tiling window managers

[Eli Zaretskii]

> Date: Tue, 11 Dec 2012 09:07:03 +0100
> From: Giorgos Keramidas <gkeramidas@gmail.com>
> CC: James Cloos <cloos@jhcloos.com>, rudalics@gmx.at, jonas@bernoul.li, 
>  emacs-devel@gnu.org
> 
>  > Can you show a screenshot of this?  Also, what would be a good
>  > solution to this problem? make the right fringe wider? something
>  > else?
> 
> FWIW, tiled windows may be slightly larger pixel-wise in at least two
> directions: right *and* bottom.  So it may be useful to apply the same
> solution to both the right fringe and the mode-line.

As I explained in this thread, it cannot be the same solution, because
there's no fringe at the bottom.

Re: size hints and tiling window managers

[Jan Djärv]

Hello.

Min_height/width is not that important, they dont have to be a multiple of frame_height/width.
Not setting the height/width_inc would mean that Emacs resizes a pixel at a time, not a row/column at the time.  And those window managers that provide resize feedback would be showing width x height as pixels instead of columns x rows.  That would be a bigger bug IMHO, than having some pixels off at the edges.

	Jan D.


8 dec 2012 kl. 02:42 skrev James Cloos <cloos@jhcloos.com>:

>>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
> 
> mr> Eli said that he can provide arbitrary frame pixel sizes at any time.
> 
> Doesn't it just require not setting the .width_inc and .height_inc
> members of the size_hints struct in src/xterm.c and src/gtkutil.c,
> and editing the .min_width and .min_height code to account for that?
> 
> Something like the (as yet untested, and X-only) code below?
> 
> If so, I presume that it should be configurable, yes?
> 
> That would require some effort to work out.
> 
> -JimC
> 
> === modified file 'src/gtkutil.c'
> --- src/gtkutil.c	2012-12-03 19:15:52 +0000
> +++ src/gtkutil.c	2012-12-08 01:35:39 +0000
> @@ -1357,9 +1357,7 @@
>   size_hints = f->output_data.x->size_hints;
>   hint_flags = f->output_data.x->hint_flags;
> 
> -  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
> -  size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
> -  size_hints.height_inc = FRAME_LINE_HEIGHT (f);
> +  hint_flags |= GDK_HINT_MIN_SIZE;
> 
>   hint_flags |= GDK_HINT_BASE_SIZE;
>   /* Use one row/col here so base_height/width does not become zero.
> @@ -1374,8 +1372,8 @@
> 
>   size_hints.base_width = base_width;
>   size_hints.base_height = base_height;
> -  size_hints.min_width  = base_width + min_cols * size_hints.width_inc;
> -  size_hints.min_height = base_height + min_rows * size_hints.height_inc;
> +  size_hints.min_width  = base_width + min_cols * FRAME_COLUMN_WIDTH (f);
> +  size_hints.min_height = base_height + min_rows * FRAME_LINE_HEIGHT (f);
> 
>   /* These currently have a one to one mapping with the X values, but I
>      don't think we should rely on that.  */
> 
> === modified file 'src/xterm.c'
> --- src/xterm.c	2012-12-04 15:15:05 +0000
> +++ src/xterm.c	2012-12-08 01:34:26 +0000
> @@ -9534,8 +9534,6 @@
>   size_hints.height = FRAME_PIXEL_HEIGHT (f);
>   size_hints.width = FRAME_PIXEL_WIDTH (f);
> 
> -  size_hints.width_inc = FRAME_COLUMN_WIDTH (f);
> -  size_hints.height_inc = FRAME_LINE_HEIGHT (f);
>   size_hints.max_width = x_display_pixel_width (FRAME_X_DISPLAY_INFO (f))
>     - FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
>   size_hints.max_height = x_display_pixel_height (FRAME_X_DISPLAY_INFO (f))
> @@ -9564,8 +9562,8 @@
>     size_hints.flags |= PBaseSize;
>     size_hints.base_width = base_width;
>     size_hints.base_height = base_height + FRAME_MENUBAR_HEIGHT (f);
> -    size_hints.min_width  = base_width + min_cols * size_hints.width_inc;
> -    size_hints.min_height = base_height + min_rows * size_hints.height_inc;
> +    size_hints.min_width  = base_width + min_cols * FRAME_COLUMN_WIDTH (f);
> +    size_hints.min_height = base_height + min_rows * FRAME_LINE_HEIGHT (f);
>   }
> 
>   /* If we don't need the old flags, we don't need the old hint at all.  */
> 
> 
> 
> -- 
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6