Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 26.01.2020 18:32, martin rudalics wrote:
>  > Okay. With xterm.diff applied it works like this:
>  >
>  > Breakpoint 1 is hit. I add breakpoint 2. Hit continue -> B 2 is hit.
>
> This is at least interesting so we could continue work from here.  IIUC
> B 2 is hit but no resizing occurs.  Is that correct?

Yes.

>  > Call resize-test again (target height is the same): B1 is hit, B2 is 
> not.
>
> OK per se, just that our frame does not have that height and we don't
> know.

Right.

>  > Change resize-test to call set-frame-height with a different HEIGHT 
> (e.g. 30). Call resize-test: B1 and B2 are both hit.
>  >
>  > Call resize-test again (however many times): only B1 is hit.
>
> OK, both.  Just that the frame still doesn't have that height.  Right?

Yup.

>  > IOW, something somewhere remembers the last value we've set HEIGHT 
> to, and doesn't send any more configureEvent's for the same value.
>
> That something should be Emacs itself.  At the time adjust_frame_size is
> called in say 'set-frame-height' it's not yet clear whether Emacs will
> issue a resize request.  The resize request is issued in this block
>
>        if (FRAME_TERMINAL (f)->set_window_size_hook)
>          FRAME_TERMINAL (f)->set_window_size_hook
>        (f, 0, new_text_width, new_text_height, 1);
>        f->resized_p = true;
>
> of adjust_frame_size so if you set B 1 there you will see whether Emacs
> has decided that the request is necessary so it gets dispatched to the
> various toolkit backends (or frontends depending on the way you look at
> them).  Please try.

AFAICT, the "if" predicate always returns true when resize-test is 
called: I set breakpoints on both the first and the second lines, and 
both of them are triggered when resize-test is called. Yet, the frame is 
not resized.

>  > The actual visible height of the child frame still doesn't change, 
> meanwhile.
>
> One thing that can be useful for further debugging: Put a background on
> the child frame like this (which also disables some additional things).
>
> (defun open-test (buffer)
>    (display-buffer-in-child-frame
>     buffer '((child-frame-parameters
>               . ((width . 10)
>                  (height . 10)
>                  (top . 50)
>                  (left . 50)
>          (undecorated . t)
> ;;         (override-redirect . t)
>          (inhibit-double-buffering . t)
>          (background-color . "yellow")
>          (minibuffer . nil)
>          (tool-bar-lines . 0)
>          (menu-bar-lines . 0)
>          (vertical-scroll-bars . nil)
>          (horizontal-scroll-bars . nil)
>          (left-fringe . 0)
>          (right-fringe . 0)
>          (border-width . 0)
>          (internal-border-width . 2)
>          (drag-internal-border . t)
>          (drag-with-mode-line . t)
>                  )))))
>
> The background color here is useful to discern window system operations
> that apparently do clear parts of the screen in reaction to our requests
> but do not send us the related ConfigureNotify message nor the messages
> to re-expose the obscured parts of the parent frame.

The child frame's background is now yellow. But I don't see anything 
else happen with it when I call resize-test.

> And finally try the attached patch for GTK builds to resize frames
> directly via gdk calls.  I doubt it changes anything but who knows.

Alas, no change. With override-redirect uncommented -- too.