bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager)

[martin rudalics <rudalics@gmx.at>]

 > Let me just repeat my initial analysis, which I still believe is
 > correct and which might have gotten lost somewhere.
 >
 > There are two problems:
 > (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first
 > calling x_wm_set_size_hint (gtkutil.c), which would propagate the
 > `frame-resize-pixelwise' flag to have an effect on GTK/GDK

I understand that now.  You don't run do_ewmh_fullscreen.  So the bug
_only_ occurs when you want to make a fullscreen frame?  This was not
clear from you initial report.

 > (2) x_wm_set_size_hint returns without propagating the
 > `frame-resize-pixelwise' flag when the frame's fullscreen property is
 > 'maximized or 'fullboth.
 >
 > The first appears to be simple oversight, but the second is
 > intentional to work around a KWin bug.

I faintly remember that bug now.  What I don't understand is the remedy.
When we do

   fs_state = Fframe_parameter (frame, Qfullscreen);
   if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))

the parameter has been already set but the frame is not yet fullscreen.
Does this shrinking occur when the frame is already fullscreen or does
it occur when a user wants to switch to fullscreen?

 > I've attached a patch which fixes things for me (at least when
 > tool-bar-mode is disabled :( ), but presumably breaks things for KWin
 > users, so it should not go in as it is until that matter has been
 > cleared; maybe that'll help clarify matters.

When worse comes to worse we could condition that somehow: Invent an
option which is off by default and call x_wm_set_size_hint when it's on.

 > We do hit that code (in gtkutil.c) twice: once during early
 > initialization, when frame_resize_pixelwise is still false, and once
 > after GDK has decided to resize us to not-quite-full-screen size, when
 > it's too late. We should hit it once more, from x_check_fullscreen,
 > but don't do so for the two reasons listed above.

I see.  If in frame.c you initialize frame_resize_pixelwise to 1 then
everything works OK?

 >> Can you check how apparently an "integral" (the increment is a multiple
 >> of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via
 >> size_hints in your case?
 >
 > Oh, I see what you mean now. I'll investigate that next.

Not necessary.  It won't help anyway.

 >>>> So it's possible that Xnest or some other X component refuses to resize
 >>>> your frame because the size hints were set up inappropriately.
 >>>
 >>> I'm pretty sure that's not what's happening, but I'll be happy to
 >>> provide traces to demonstrate my analysis is correct...or to prove it
 >>> wrong, of course! The attached gdb log shows quite clearly that it's
 >>> GDK making the second (erroneous) call to XResizeWindow, not Xnest
 >>> (there is no window manager).
 >>
 >> OK.  I won't doubt what you say here.
 >
 > Feel free to, of course, though I understand sifting through gdb logs
 > is best avoided unless it's absolutely necessary.

Well... I didn't understand the problem at that time.

 >>>> Does it also fail when `frame-resize-pixelwise' is set to t in your
 >>>> initial file?
 >>>
 >>> Yes, it does.
 >>
 >> That's bad.  It can only mean that we send an integral resize request
 >> _before_ Emacs reads the initial file and the subsequent "real" resize
 >> request fails because the size hints have been already set up wrongly.
 >
 > No, we call Fsetq and so on fine, I think it's just that we never call
 > x_set_wm_size_hints afterwards.

We could invent a function `set-frame-resize-pixelwise' which sends the
size hints (maybe iff when a frame is not fullscreen, or so to avoid the
KWin bug).

 > It appears to ignore the fullscreen resize; as you point out, that's
 > as expected, by the "don't resize twice without a redisplay" rule.

It's rather a don't resize and change the fullscreen status without a
redisplay.

 >> However, in
 >> xg_frame_set_char_size (which is responsible for the resize in the GTK
 >> case) we could do the
 >
 > That's a very interesting point, because xg_frame_set_char_size never
 > appears to get called here after early initialization. Instead, we
 > call XResizeWindow directly, then GDK catches the ConfigureNotify and
 > decides it doesn't like it, so it sends another (erroneous)
 > XResizeWindow.

Interesting indeed.  Something's not right here, I'm afraid.  I'll have
to look into this.

martin