bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

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

I'm using a tiling window manager with the GTK+ port of emacs 24. I
force the emacs frame to take the height of the entire screen.

After resizing, the minibuffer position is not aligned to the bottom of
the frame, but it's logically aligned to the last full line, leaving an
un-painted margin at the lower border of the frame (test_before.png).

However, when receiving a FocusIn event (just by cycling focus), emacs
properly aligns the minibuffer to the bottom, and displays a
partially-visible line just above the minibuffer (test_after.png).

I realize this is a very minor issue and ignoring size hints is bad(tm),
but since emacs properly aligns the minibuffer with
toggle-frame-fullscreen in order to fit the screen it shouldn't be hard
to fix.


In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2014-12-09 on gaia, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.0 (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

[-- Attachment #2: test_after.png --]
[-- Type: image/png, Size: 6052 bytes --]

[-- Attachment #3: test_before.png --]
[-- Type: image/png, Size: 8806 bytes --]

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 > I'm using a tiling window manager with the GTK+ port of emacs 24. I
 > force the emacs frame to take the height of the entire screen.

How do you do that?

 > After resizing, the minibuffer position is not aligned to the bottom of
 > the frame, but it's logically aligned to the last full line, leaving an
 > un-painted margin at the lower border of the frame (test_before.png).
 >
 > However, when receiving a FocusIn event (just by cycling focus), emacs
 > properly aligns the minibuffer to the bottom, and displays a
 > partially-visible line just above the minibuffer (test_after.png).
 >
 > I realize this is a very minor issue and ignoring size hints is bad(tm),
 > but since emacs properly aligns the minibuffer with
 > toggle-frame-fullscreen in order to fit the screen it shouldn't be hard
 > to fix.

What happens when you set `frame-resize-pixelwise' to t?

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/03/2015 06:47 PM, martin rudalics wrote:
>  > I'm using a tiling window manager with the GTK+ port of emacs 24. I
>  > force the emacs frame to take the height of the entire screen.
> 
> How do you do that?

Using awesomewm you can set "size_hints_honor = false".
With spectrwm there's no setting (the size hints are not honored if the
window is tiled, but are if the window is floating).
Xmonad is pretty similar to awesome in this sense (defaults to honor,
but not honoring is common).

>  > I realize this is a very minor issue and ignoring size hints is bad(tm),
>  > but since emacs properly aligns the minibuffer with
>  > toggle-frame-fullscreen in order to fit the screen it shouldn't be hard
>  > to fix.
> 
> What happens when you set `frame-resize-pixelwise' to t?

It does work, but I was wondering if this could be fixed irregardless,
since depending on the setting the hints might be honored or not.

When I put some debugging code in gtkutil.c:xg_frame_resized, it looks
like two resize events are received when the frame is mapped: one with
the real window size, and a second event with the size rounded-down to
the text size. Again, when the frame is focused, a third resize event is
received with the initial size, which causes the frame to render
correctly. This feels odd.

GTK might be trying to resize the window after the first event. In
xg_frame_resized itself it might be necessary to disable the size hints
to prevent that (as done in xg_frame_set_char_size). But I don't have
enough experience with GTK and/or low-level frame handling. I was hoping
for somebody else to chime in.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 >>   > I'm using a tiling window manager with the GTK+ port of emacs 24. I
 >>   > force the emacs frame to take the height of the entire screen.
 >>
 >> How do you do that?
 >
 > Using awesomewm you can set "size_hints_honor = false".
 > With spectrwm there's no setting (the size hints are not honored if the
 > window is tiled, but are if the window is floating).
 > Xmonad is pretty similar to awesome in this sense (defaults to honor,
 > but not honoring is common).

I still don't understand how you "force the emacs frame to take the
height of the entire screen".  Do you set the fullscreen frame parameter
to `fullheight'?

 >>   > I realize this is a very minor issue and ignoring size hints is bad(tm),
 >>   > but since emacs properly aligns the minibuffer with
 >>   > toggle-frame-fullscreen in order to fit the screen it shouldn't be hard
 >>   > to fix.
 >>
 >> What happens when you set `frame-resize-pixelwise' to t?
 >
 > It does work, but I was wondering if this could be fixed irregardless,
 > since depending on the setting the hints might be honored or not.

Do you mean you want hints honored when the frame is floating and not
honored when the frame is tiled?

 > When I put some debugging code in gtkutil.c:xg_frame_resized, it looks
 > like two resize events are received when the frame is mapped: one with
 > the real window size, and a second event with the size rounded-down to
 > the text size.

And if you set `frame-resize-pixelwise' to t you get only one resize
event?

 > Again, when the frame is focused, a third resize event is
 > received with the initial size, which causes the frame to render
 > correctly. This feels odd.

What is the "initial size"?  Who sets it?

 > GTK might be trying to resize the window after the first event. In
 > xg_frame_resized itself it might be necessary to disable the size hints
 > to prevent that (as done in xg_frame_set_char_size). But I don't have
 > enough experience with GTK and/or low-level frame handling. I was hoping
 > for somebody else to chime in.

In x_wm_set_size_hint we disable size hints for fullscreen and maximized
frames.  Is it that what you mean with "as done in
xg_frame_set_char_size"?

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/04/2015 07:45 PM, martin rudalics wrote:
>  > Using awesomewm you can set "size_hints_honor = false".
>  > With spectrwm there's no setting (the size hints are not honored if the
>  > window is tiled, but are if the window is floating).
>  > Xmonad is pretty similar to awesome in this sense (defaults to honor,
>  > but not honoring is common).
> 
> I still don't understand how you "force the emacs frame to take the
> height of the entire screen".  Do you set the fullscreen frame parameter
> to `fullheight'?

No, the window manager resizes the frame to the screen's height (or an
arbitrary height), ignoring WM size hints. I hope this clarifies. I
never use the fullscreen function (I use the WM own binding for this
purpose).

>  > It does work, but I was wondering if this could be fixed irregardless,
>  > since depending on the setting the hints might be honored or not.
> 
> Do you mean you want hints honored when the frame is floating and not
> honored when the frame is tiled?

Yes.

>  > When I put some debugging code in gtkutil.c:xg_frame_resized, it looks
>  > like two resize events are received when the frame is mapped: one with
>  > the real window size, and a second event with the size rounded-down to
>  > the text size.
> 
> And if you set `frame-resize-pixelwise' to t you get only one resize
> event?

I do.

>  > Again, when the frame is focused, a third resize event is
>  > received with the initial size, which causes the frame to render
>  > correctly. This feels odd.
> 
> What is the "initial size"?  Who sets it?

The first event is sent by the WM (probably with a reconfigure request).

> 
>  > GTK might be trying to resize the window after the first event. In
>  > xg_frame_resized itself it might be necessary to disable the size hints
>  > to prevent that (as done in xg_frame_set_char_size). But I don't have
>  > enough experience with GTK and/or low-level frame handling. I was hoping
>  > for somebody else to chime in.
> 
> In x_wm_set_size_hint we disable size hints for fullscreen and maximized
> frames.  Is it that what you mean with "as done in
> xg_frame_set_char_size"?

Yes. The second/third event I saw while debugging are not coming from
the window manager. I suspect it's GTK trying to reconfigure the window
according to the size hints (and failing).

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

Hi.

> 4 mar 2015 kl. 19:53 skrev Yuri D'Elia <yuri.delia@eurac.edu>:
> 
> On 03/04/2015 07:45 PM, martin rudalics wrote:
>> In x_wm_set_size_hint we disable size hints for fullscreen and maximized
>> frames.  Is it that what you mean with "as done in
>> xg_frame_set_char_size"?
> 
> Yes. The second/third event I saw while debugging are not coming from
> the window manager. I suspect it's GTK trying to reconfigure the window
> according to the size hints (and failing).

Gtk+ does have code that tries to resize a window if it did not get the size it requested.
Also, it does try to satisfy the size hints itself, which is wrong.  Hints are for the window manager to respect or ignore as it wishes.  It is nothing wrong with ignoring hints.  They are, after all, just that, hints.
This is an example why it doesn't work to do what Gtk+ does.  This is a major Gtk+ bug IMHO.
I'm afraid it is out of Emacs control.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/04/2015 08:22 PM, Jan D. wrote:
> Hi.
> 
>> 4 mar 2015 kl. 19:53 skrev Yuri D'Elia <yuri.delia@eurac.edu>:
>> 
>> On 03/04/2015 07:45 PM, martin rudalics wrote:
>>> In x_wm_set_size_hint we disable size hints for fullscreen and
>>> maximized frames.  Is it that what you mean with "as done in 
>>> xg_frame_set_char_size"?
>> 
>> Yes. The second/third event I saw while debugging are not coming
>> from the window manager. I suspect it's GTK trying to reconfigure
>> the window according to the size hints (and failing).
> 
> Gtk+ does have code that tries to resize a window if it did not get
> the size it requested. Also, it does try to satisfy the size hints
> itself, which is wrong.  Hints are for the window manager to respect
> or ignore as it wishes.  It is nothing wrong with ignoring hints.
> They are, after all, just that, hints. This is an example why it
> doesn't work to do what Gtk+ does.  This is a major Gtk+ bug IMHO. 

As I suspected, I recall having the same issue on my programs since
Gtk1.3, and I never exactly understood why Gtk behaved like that.

> I'm afraid it is out of Emacs control.

Since the gtk interface has some issues, is there anything really worth
in it compared to lucid? I switched to the gtk port only when debian
make it default, getting the impression that lucid was receiving less
love. Maybe rendering through gdk is faster?

Pure curiosity.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/04/2015 08:30 PM, Yuri D'Elia wrote:
> As I suspected, I recall having the same issue on my programs since
> Gtk1.3, and I never exactly understood why Gtk behaved like that.
> 
>> I'm afraid it is out of Emacs control.
> 
> Since the gtk interface has some issues, is there anything really worth
> in it compared to lucid? I switched to the gtk port only when debian
> make it default, getting the impression that lucid was receiving less
> love. Maybe rendering through gdk is faster?

And FYI, indeed the lucid variant is working correctly without having to
set `frame-resize-pixelwise'.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

> 4 mar 2015 kl. 20:30 skrev Yuri D'Elia <yuri.delia@eurac.edu>:
> 
> On 03/04/2015 08:22 PM, Jan D. wrote:
>> Hi.
> 
>> I'm afraid it is out of Emacs control.
> 
> Since the gtk interface has some issues, is there anything really worth
> in it compared to lucid? I switched to the gtk port only when debian
> make it default, getting the impression that lucid was receiving less
> love. Maybe rendering through gdk is faster?
> 
> Pure curiosity.

The toolbar, scrollbar and possibly menus look better.  There is a font chooser and a file dialog.
The dialogs look a bit better.  Also, they adapt to the desktop theme.

Gtk+ does rendering via cairo nowdays, it is not faster, but a bit slower actually than pure X that lucid uses.
Lucid only receives some updates to cope with changed coding standards and core Emacs changes.
The last new stuff was antialiased text in menus, and that was 4 years ago.
I think XEmacs Lucid version has more features, but I haven't investigated.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 >> Do you mean you want hints honored when the frame is floating and not
 >> honored when the frame is tiled?
 >
 > Yes.

How do you switch from floating to tiling mode and back?  Ideally,
tiling mode would set `frame-resize-pixelwise' to t with the appropriate
size hints and floating mode would reset it but that's hard to achieve
without the necessary information.  How does, for example,

 >> Using awesomewm you can set "size_hints_honor = false"

work in practice?  Is this a setting Emacs could inspect somewhere?

 > Yes. The second/third event I saw while debugging are not coming from
 > the window manager. I suspect it's GTK trying to reconfigure the window
 > according to the size hints (and failing).

So IIUC you get two xg_frame_resized events.  The first event seems to
come from your window manager and the requested size does not obey the
size hints.  The second event seems to come from Gtk and the requested
size obeys the previous hints.  Does anything significant happen in
between these two events?  That is, does Emacs issue a
xg_frame_set_char_size request and does x_wm_set_size_hint get called?

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 > Gtk+ does have code that tries to resize a window if it did not get the size it requested.

How does it do that?  Why does a first resize with an odd size
apparently get through at all?  Can't Gtk+ intercept thet first request?
And how comes that Gtk+ is apparently not able to intercept the focus in
reqest in the same way?

BTW, I never understood the following two comments in gtkutil.c:

   /* Must use GTK routines here, otherwise GTK resets the size hints
      to its own defaults.  */

and

       /* Don't set hints when maximized or fullscreen.  Apparently KWin and
          Gtk3 don't get along and the frame shrinks (!).

How could that possibly work?  According to the first comment when we
"don't set hints when maximized or fullscreen" we get "otherwise GTK
resets the size hints to its own defaults".

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

martin rudalics skrev den 2015-03-05 09:04:
>  > Gtk+ does have code that tries to resize a window if it did not get
> the size it requested.
>
> How does it do that?

It keeps track of what resize it has done, and when the ConfigureNotify 
event arrives, it checks to see if it matches its constraints.  See code 
in Gtk+, gtkwindow.c (it is a mess).


> Why does a first resize with an odd size
> apparently get through at all?

Why shouldn't it?

>  Can't Gtk+ intercept thet first request?
> And how comes that Gtk+ is apparently not able to intercept the focus in
> reqest in the same way?

What do you mean by intercept?  Intercept from who?

>
> BTW, I never understood the following two comments in gtkutil.c:
>
>    /* Must use GTK routines here, otherwise GTK resets the size hints
>       to its own defaults.  */
>
> and
>
>        /* Don't set hints when maximized or fullscreen.  Apparently KWin
> and
>           Gtk3 don't get along and the frame shrinks (!).
>
> How could that possibly work?

Fine so far.  The hints specify things like resize increments which are 
the character size, i.e. you can only resize one full row at the time 
(at least when that comment was made).  If you have a fullscreen frame, 
and the font changes, in principle the hints should change.  But a 
change leads to a war between KWin and Gtk+ regarding who shall control 
the size of the frame.  So we don't change hints, we leave the old in place.

Gtk+ has its own copy of hints, which it sets by itself from time to 
time, and which it tries to enforce.  If we where to set hints with X 
functions, Gtk+ would try to enforce something it has, while the window 
manager would enforce what we actually set.  So we use Gtk+ routines sp 
that Gtk+ and the window manager have the same hints.

These to comments are not really related to each other.

> According to the first comment when we
> "don't set hints when maximized or fullscreen" we get "otherwise GTK
> resets the size hints to its own defaults".

I.e. make sure the window manager and Gtk+ have the same hints, but 
don't change them when fullscreen because Gtk+ and KWin implements 
enforcements of hints differently.  Gtk+ and the window manager still 
has our last non-fullscreen hints.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 > It keeps track of what resize it has done, and when the
 > ConfigureNotify event arrives, it checks to see if it matches its
 > constraints.  See code in Gtk+, gtkwindow.c (it is a mess).
 >
 >> Why does a first resize with an odd size
 >> apparently get through at all?
 >
 > Why shouldn't it?
 >
 >>  Can't Gtk+ intercept thet first request?
 >> And how comes that Gtk+ is apparently not able to intercept the focus in
 >> reqest in the same way?
 >
 > What do you mean by intercept?  Intercept from who?

I have no idea how a resize request issued by the window manager is
handled.  I initially thought that a configure event is issued by the
window manager and passed on to us via Gtk.  Apparently, this is not the
case and the window manager only informs Gtk about the resize request
and Gtk takes the appropriate measures.  As far as focus requests are
concerned I don't understand why Gtk doesn't treat them like resize
requests.

 >> BTW, I never understood the following two comments in gtkutil.c:
 >>
 >>    /* Must use GTK routines here, otherwise GTK resets the size hints
 >>       to its own defaults.  */
 >>
 >> and
 >>
 >>        /* Don't set hints when maximized or fullscreen.  Apparently KWin
 >> and
 >>           Gtk3 don't get along and the frame shrinks (!).
 >>
 >> How could that possibly work?
 >

 > Fine so far.  The hints specify things like resize increments which
 > are the character size, i.e. you can only resize one full row at the
 > time (at least when that comment was made).  If you have a fullscreen
 > frame, and the font changes, in principle the hints should change.
 > But a change leads to a war between KWin and Gtk+ regarding who shall
 > control the size of the frame.  So we don't change hints, we leave the
 > old in place.

So if Emacs starts with a maximized frame we don't set any hints?

Apparently no such measure is needed for fullheight/-width frames.

 > I.e. make sure the window manager and Gtk+ have the same hints, but
 > don't change them when fullscreen because Gtk+ and KWin implements
 > enforcements of hints differently.  Gtk+ and the window manager still
 > has our last non-fullscreen hints.

With the according base height and width.  I always thought these should
reflect our current sizes.  Does the fullscreen status suspend that
temporarily?

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

Hi.

> 5 mar 2015 kl. 19:15 skrev martin rudalics <rudalics@gmx.at>:
> 
> > What do you mean by intercept?  Intercept from who?
> 
> I have no idea how a resize request issued by the window manager is
> handled.  I initially thought that a configure event is issued by the
> window manager and passed on to us via Gtk.  Apparently, this is not the
> case and the window manager only informs Gtk about the resize request
> and Gtk takes the appropriate measures.  As far as focus requests are
> concerned I don't understand why Gtk doesn't treat them like resize
> requests.

The window manager can resize the window, for example when you drag on its corners, or when you maximize it.
Or it can intercept Emacs resize request and modify it, so it is consistent with size hints.
In both cases a ConfigureNotify is sent.  Gtk+ does receive it.  The problem is that Gtk+ then tries to apply size hints also.

Focus events does not contain any information about width/height and can't be taken as a resize request.  That would be kind of perverse, focus has nothing to do with resize.

> 
> 
> So if Emacs starts with a maximized frame we don't set any hints?
> 

Yes.

> Apparently no such measure is needed for fullheight/-width frames.

The bug report that lead to the change mentioned no such problems.

> 
> > I.e. make sure the window manager and Gtk+ have the same hints, but
> > don't change them when fullscreen because Gtk+ and KWin implements
> > enforcements of hints differently.  Gtk+ and the window manager still
> > has our last non-fullscreen hints.
> 
> With the according base height and width.  I always thought these should
> reflect our current sizes.  Does the fullscreen status suspend that
> temporarily?

The window manager is what does the fullscreen happen, so it is free to ignore any hints, i.e. hints should not matter, fullscreen takes precedence.  But in principle hints during fullscreen may not reflect the "true" state of affairs.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 > The window manager can resize the window, for example when you drag on
 > its corners, or when you maximize it.  Or it can intercept Emacs
 > resize request and modify it, so it is consistent with size hints.  In
 > both cases a ConfigureNotify is sent.  Gtk+ does receive it.

In gtk_window_configure_event?

 > The
 > problem is that Gtk+ then tries to apply size hints also.

Via gtk_window_move_resize?  Which, in principle, is not entirely wrong.
Emacs gets what it asked for.  Can't we reset the size hints in between?
That's what I earlier meant by "interception".

 > Focus events does not contain any information about width/height and
 > can't be taken as a resize request.  That would be kind of perverse,
 > focus has nothing to do with resize.

Didn't the OP mention that during a focus event a resize also took
place?  That's what he said:

    However, when receiving a FocusIn event (just by cycling focus),
    emacs properly aligns the minibuffer to the bottom, and displays a
    partially-visible line just above the minibuffer (test_after.png).

 >> Apparently no such measure is needed for fullheight/-width frames.
 >
 > The bug report that lead to the change mentioned no such problems.

The OP said that:

    I force the emacs frame to take the height of the entire screen.

So this looks like a fullheight frame to me without, apparently,
explicitly specifying it as such.

 > The window manager is what does the fullscreen happen, so it is free
 > to ignore any hints, i.e. hints should not matter, fullscreen takes
 > precedence.  But in principle hints during fullscreen may not reflect
 > the "true" state of affairs.

Maybe the OP's problem is that the Window manager conceptually gives
Emacs the full height of the screen and Gtk+ is not aware of that.
Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
entry.

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/06/2015 10:21 AM, martin rudalics wrote:
> The OP said that:
> 
>     I force the emacs frame to take the height of the entire screen.
> 
> So this looks like a fullheight frame to me without, apparently,
> explicitly specifying it as such.

I should have never said 'full screen height', since this keeps
confusing you. In my particular configuration, I have no window borders,
so two windows side-by-side will automatically fit the screen height.
This is *not* a special case for a tiling window manger.

A tiling window manager will force the frame to fit a screen region,
_possibly_ ignoring size hints. That's all there is to it. It does that
*intentionally*, since you can imagine that having gaps between the
tiles is just plainly annoying. In a side-by-side configuration, you
don't want gaps on the lower corner of the screen.

> Maybe the OP's problem is that the Window manager conceptually gives
> Emacs the full height of the screen and Gtk+ is not aware of that.
> Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
> entry.

The problem with Gtk+ is that it tries to handle hints both on behalf of
the window manger and on the client. I have *no* clue of why it does
that. Maybe to handle TWM? Or more probably to handle the "Windows" port
which has no such feature?

The second issue with Gtk+ is that it notifies the application while
doing his own hint handling (or again, is that intentional?).

I would be perfectly happy to discuss this issue with Gtk+ folks, but I
remember that back in Gtk 1.3/2.0 days, many of my patches where
rejected since they fixed behavior that wasn't really intended "for the
common user", whatever that means. Gtk 3 seems to have regressed even
more in this area, so I just gave up in trying to argue.

To sum up, however, what about this:

Since we receive the first ConfigureNotify event with the unhinted
width/height, we *can* detect that the size hints have been ignored.
Couldn't we disable them at that point? This would fix Gtk+ trying to do
a reconfiguration attempt and remove the following two useless events.
This looks like a simple fix that would already improve the current
configuration, but I would need experience with the Mac/Win port to tell
if Gtk would fail in this scenario. Maybe an "ifdef X11" is required.

The question then becomes: would actually be possible to set the hints
immediately back on, so that in a further resize request the WM sees the
hints, but *without* having Gtk+ do it's mess? This would mean that we
would need to set the hints back on when the resize request has been
fully settled. Tricky. Setting them back-on on a further repaint/focus
in/out event is either too late or not enough.

As mentioned in my first request, this is a minor nuance fix for folks
with tiling window managers. My point is "can we handle it better?".

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

> 6 mar 2015 kl. 10:21 skrev martin rudalics <rudalics@gmx.at>:
> 
> > The window manager can resize the window, for example when you drag on
> > its corners, or when you maximize it.  Or it can intercept Emacs
> > resize request and modify it, so it is consistent with size hints.  In
> > both cases a ConfigureNotify is sent.  Gtk+ does receive it.
> 
> In gtk_window_configure_event?

No, in the Gtk+ event handler.

> 
> > The
> > problem is that Gtk+ then tries to apply size hints also.
> 
> Via gtk_window_move_resize?  Which, in principle, is not entirely wrong.

Yes it is.  They are called window manager hints for a reason.

> Emacs gets what it asked for.  Can't we reset the size hints in between?
> That's what I earlier meant by "interception".

I don't follow.

> 
> > Focus events does not contain any information about width/height and
> > can't be taken as a resize request.  That would be kind of perverse,
> > focus has nothing to do with resize.
> 
> Didn't the OP mention that during a focus event a resize also took
> place?  That's what he said:
> 
>   However, when receiving a FocusIn event (just by cycling focus),
>   emacs properly aligns the minibuffer to the bottom, and displays a
>   partially-visible line just above the minibuffer (test_after.png).

Emacs must have received a ConfigureNotify to adjust its size.  It is possible the OP missed it.

> 
> >> Apparently no such measure is needed for fullheight/-width frames.
> >
> > The bug report that lead to the change mentioned no such problems.
> 
> The OP said that:
> 
>   I force the emacs frame to take the height of the entire screen.
> 
> So this looks like a fullheight frame to me without, apparently,
> explicitly specifying it as such.

I meant the bug report that prompted our resetting size hints for fullscreen.
I think he said that he used a tiling window manager, so it is not a fullheight frame.

> 
> > The window manager is what does the fullscreen happen, so it is free
> > to ignore any hints, i.e. hints should not matter, fullscreen takes
> > precedence.  But in principle hints during fullscreen may not reflect
> > the "true" state of affairs.
> 
> Maybe the OP's problem is that the Window manager conceptually gives
> Emacs the full height of the screen and Gtk+ is not aware of that.
> Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
> entry.

It is none of Gtk+ business to know about fullscreen.  It is something between Emacs and the window manager.  Gtk+ gets sizes from the X server and the window manager via ConfigureNotify and should just accept what it gets.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

> 6 mar 2015 kl. 11:53 skrev Yuri D'Elia <yuri.delia@eurac.edu>:
> 
> On 03/06/2015 10:21 AM, martin rudalics wrote:
>> The OP said that:
>> 
>>    I force the emacs frame to take the height of the entire screen.
>> 
>> So this looks like a fullheight frame to me without, apparently,
>> explicitly specifying it as such.
> 
> I should have never said 'full screen height', since this keeps
> confusing you. In my particular configuration, I have no window borders,
> so two windows side-by-side will automatically fit the screen height.
> This is *not* a special case for a tiling window manger.
> 
> A tiling window manager will force the frame to fit a screen region,
> _possibly_ ignoring size hints. That's all there is to it. It does that
> *intentionally*, since you can imagine that having gaps between the
> tiles is just plainly annoying. In a side-by-side configuration, you
> don't want gaps on the lower corner of the screen.
> 
>> Maybe the OP's problem is that the Window manager conceptually gives
>> Emacs the full height of the screen and Gtk+ is not aware of that.
>> Maybe also Gtk+ doesn't even understand fullheight.  At least I can't
>> detect an entry for it in GtkWindowPrivate which OTOH has a 'tiled'
>> entry.
> 
> The problem with Gtk+ is that it tries to handle hints both on behalf of
> the window manger and on the client. I have *no* clue of why it does
> that. Maybe to handle TWM? Or more probably to handle the "Windows" port
> which has no such feature?

Thats sounds reasonable.  Probably also Wayland which has no window manager.

> 
> The second issue with Gtk+ is that it notifies the application while
> doing his own hint handling (or again, is that intentional?).
> 
> I would be perfectly happy to discuss this issue with Gtk+ folks, but I
> remember that back in Gtk 1.3/2.0 days, many of my patches where
> rejected since they fixed behavior that wasn't really intended "for the
> common user", whatever that means. Gtk 3 seems to have regressed even
> more in this area, so I just gave up in trying to argue.

I have no better experience than you.

> 
> To sum up, however, what about this:
> 
> Since we receive the first ConfigureNotify event with the unhinted
> width/height, we *can* detect that the size hints have been ignored.
> Couldn't we disable them at that point?

At what point would we re-enable them?

> This would fix Gtk+ trying to do
> a reconfiguration attempt and remove the following two useless events.
> This looks like a simple fix that would already improve the current
> configuration, but I would need experience with the Mac/Win port to tell
> if Gtk would fail in this scenario. Maybe an "ifdef X11" is required.

The NS/W32 port of Emacs can't use Gtk+ so it is already X11 only.

> 
> The question then becomes: would actually be possible to set the hints
> immediately back on, so that in a further resize request the WM sees the
> hints, but *without* having Gtk+ do it's mess? This would mean that we
> would need to set the hints back on when the resize request has been
> fully settled. Tricky. Setting them back-on on a further repaint/focus
> in/out event is either too late or not enough.
> 
> As mentioned in my first request, this is a minor nuance fix for folks
> with tiling window managers. My point is "can we handle it better?".

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On 03/06/2015 06:05 PM, Jan D. wrote:
>> Since we receive the first ConfigureNotify event with the unhinted
>> width/height, we *can* detect that the size hints have been ignored.
>> Couldn't we disable them at that point?
> 
> At what point would we re-enable them?

...

>> hints, but *without* having Gtk+ do it's mess? This would mean that we
>> would need to set the hints back on when the resize request has been
>> fully settled. Tricky. Setting them back-on on a further repaint/focus
>> in/out event is either too late or not enough.

Re-enabling them once at the first repaint (out of the resize handler)
*might* work, depending on how Gtk keeps its state. If the WM is
ignoring hits, we would be disabling/re-enabling Gtk hints at each event
when "live" resizing, though.

I would need to try or read Gtk sources to be sure. Maybe Gtk has some
synthetic events that we could use.

If not, leaving them disabled would still be a better option.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 > I should have never said 'full screen height', since this keeps
 > confusing you. In my particular configuration, I have no window borders,
 > so two windows side-by-side will automatically fit the screen height.
 > This is *not* a special case for a tiling window manger.
 >
 > A tiling window manager will force the frame to fit a screen region,
 > _possibly_ ignoring size hints. That's all there is to it. It does that
 > *intentionally*, since you can imagine that having gaps between the
 > tiles is just plainly annoying. In a side-by-side configuration, you
 > don't want gaps on the lower corner of the screen.

Accepted.  The frame is not fullheight; it just is as high as the screen.

 > The second issue with Gtk+ is that it notifies the application while
 > doing his own hint handling (or again, is that intentional?).
 >
 > I would be perfectly happy to discuss this issue with Gtk+ folks, but I
 > remember that back in Gtk 1.3/2.0 days, many of my patches where
 > rejected since they fixed behavior that wasn't really intended "for the
 > common user", whatever that means. Gtk 3 seems to have regressed even
 > more in this area, so I just gave up in trying to argue.
 >
 > To sum up, however, what about this:
 >
 > Since we receive the first ConfigureNotify event with the unhinted
 > width/height, we *can* detect that the size hints have been ignored.
 > Couldn't we disable them at that point?

This was the idea of "intercepting" I mentioned earlier.

 > This would fix Gtk+ trying to do
 > a reconfiguration attempt and remove the following two useless events.
 > This looks like a simple fix that would already improve the current
 > configuration, but I would need experience with the Mac/Win port to tell
 > if Gtk would fail in this scenario. Maybe an "ifdef X11" is required.

You can ignore other ports in this regard.

 > The question then becomes: would actually be possible to set the hints
 > immediately back on, so that in a further resize request the WM sees the
 > hints, but *without* having Gtk+ do it's mess? This would mean that we
 > would need to set the hints back on when the resize request has been
 > fully settled. Tricky. Setting them back-on on a further repaint/focus
 > in/out event is either too late or not enough.

I'm afraid this is the hard part. Emacs would have to know that the
window manager has stopped tiling.  I already said that GtkWindowPrivate
has a `tiled' entry.  I have no idea who can use or set that.

 > As mentioned in my first request, this is a minor nuance fix for folks
 > with tiling window managers. My point is "can we handle it better?".

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[martin rudalics]

 >> Emacs gets what it asked for.  Can't we reset the size hints in between?
 >> That's what I earlier meant by "interception".
 >
 > I don't follow.

If Emacs receives an xg_frame_resized request that does not fit into the
existing size hints scheme it could set new, fitting size hints.  This
way we would signal Gtk that we are OK with the requested values.

martin

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Jan D.]

Hi.

> 6 mar 2015 kl. 19:54 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> Emacs gets what it asked for.  Can't we reset the size hints in between?
> >> That's what I earlier meant by "interception".
> >
> > I don't follow.
> 
> If Emacs receives an xg_frame_resized request that does not fit into the
> existing size hints scheme it could set new, fitting size hints.  This
> way we would signal Gtk that we are OK with the requested values.

You can try that.  But setting new fitting size hints to a size Gtk+ does not know about yet could make Gtk+ request a resize.  But I don't know, you have to try it with at least a couple of window managers.

	Jan D.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Stefan Kangas]

Yuri D'Elia <yuri.delia@eurac.edu> writes:

> I'm using a tiling window manager with the GTK+ port of emacs 24. I
> force the emacs frame to take the height of the entire screen.
>
> After resizing, the minibuffer position is not aligned to the bottom of
> the frame, but it's logically aligned to the last full line, leaving an
> un-painted margin at the lower border of the frame (test_before.png).
>
> However, when receiving a FocusIn event (just by cycling focus), emacs
> properly aligns the minibuffer to the bottom, and displays a
> partially-visible line just above the minibuffer (test_after.png).
>
> I realize this is a very minor issue and ignoring size hints is bad(tm),
> but since emacs properly aligns the minibuffer with
> toggle-frame-fullscreen in order to fit the screen it shouldn't be hard
> to fix.
>
>
> In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
>  of 2014-12-09 on gaia, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11604000
> System Description:	Debian GNU/Linux 8.0 (jessie)

I used to see this before running a tiling window manager (XMonad),
but it has gone away sometime in recent years.  I don't think I've
changed anything in my configuration.

Are you still seeing this on a modern version of Emacs?  If I don't
hear back from you within a couple of weeks, I'll just assume that
this is fixed and close this bug as unreproducible.

Best regards,
Stefan Kangas

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On Sat, Feb 29 2020, Stefan Kangas wrote:
> I used to see this before running a tiling window manager (XMonad),
> but it has gone away sometime in recent years.  I don't think I've
> changed anything in my configuration.
>
> Are you still seeing this on a modern version of Emacs?  If I don't
> hear back from you within a couple of weeks, I'll just assume that
> this is fixed and close this bug as unreproducible.

It still happens also on master:

"GNU Emacs 28.0.50 (build 40, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2020-03-01"

But it now happens only the first frame created right after starting
emacs (both regular or as a daemon).

After the first resize event and/or any new frame do not suffer from
this, so especially when used in daemon mode it's less noticeable.

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Stefan Kangas]

Yuri D'Elia <yuri.delia@eurac.edu> writes:

> It still happens also on master:
>
> "GNU Emacs 28.0.50 (build 40, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2020-03-01"
>
> But it now happens only the first frame created right after starting
> emacs (both regular or as a daemon).
>
> After the first resize event and/or any new frame do not suffer from
> this, so especially when used in daemon mode it's less noticeable.

Thanks for verifying that you're still seeing this.  Which window
manager (and version) are you using?

The previous discussion seems to indicate that this may be a problem
with Gtk only, and not Lucid.  But it's not clear to me from the
discussion if this happens because of a bug in Gtk or a bug in Emacs.

Best regards,
Stefan Kangas

bug#19990: 24.4; Bad resizing interaction when WM ignores size hints

[Yuri D'Elia]

On Mon, Mar 02 2020, Stefan Kangas wrote:
>> After the first resize event and/or any new frame do not suffer from
>> this, so especially when used in daemon mode it's less noticeable.
>
> Thanks for verifying that you're still seeing this.  Which window
> manager (and version) are you using?

I'm currently using spectrwm, but I did use awesomewm in the "tile" and
"max" layout with no gaps giving same results.

> The previous discussion seems to indicate that this may be a problem
> with Gtk only, and not Lucid.  But it's not clear to me from the
> discussion if this happens because of a bug in Gtk or a bug in Emacs.

Gtk would definitely add some extra complexity as I assume the main
frame would be a GtkWindow (at least with gtk2, gtk itself tried to
enforce size hints with more XConfigure requests! I hated that), but
I've been building for lucid exclusively for some years now.