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

[martin rudalics]

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

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

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

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

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

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

martin

gtkutil.diff
Description: Text Data