bug#25943: 21.5 Frame Display Difficulties

[martin rudalics <rudalics@gmx.at>]

 >   (frame-edges  frame  'outer=edges)

'outer-edges please

 > (599 256 1431 940) (599 256 1431 940) (599 256 1431 940))

The first value looks wrong supposedly due to the outer=edges mishap.

 > ;; Immediately after maximizing by clicking on the top-right +.  Note that
 > the value of frame is
 > ;; different.
 > frame
 > #<frame *scratch* 0x131b0b0>

That's normal.  The notation is cryptic but people are fond of it.
However, these values

 > (outer-size 2048 .
 > 1114)
...
 > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151))

sampled from GTK clearly mismatch those of the Emacs window management
routines

 > frame pixel: 832 x 684   cols/lines: 84 x 36   units: 10 x 19
 > frame text pixel: 800 x 684   cols/lines: 80 x 36

and represent what you see on your images: A window manager window of
2048 x 1114 pixels and an embedded Emacs frame of 832 x 684 pixels.  The
size has not propagated properly.

 > ;; Just after obtaining the information above the (real, not reported)
 > workarea expanded to its
 > ;; "proper" maximized size with no intentional input from me.  I ran the
 > checks again, and the
 > ;; results are different.

Now

 > (outer-size 2048 .
 > 1114)
...
 > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151))

are as before but

 > frame pixel: 2048 x 1051   cols/lines: 205 x 55   units: 10 x 19
 > frame text pixel: 2016 x 1051   cols/lines: 201 x 55

show that Emacs caught up with GTK.  What happens when you click the ‘+’
button three times in a row?  BTW, I suppose that this behavior shows up
only in your ssh setup and you cannot repeat it without tunneling.  Do
you observe a similar behavior via ssh when you substantially change the
frame size via ‘set-frame-size’?

Also, did you try the ssh experiment with your 23.2 build?  And it would
be interesting if you were able to reproduce the behavior with a 25.2 Lucid
or Motif build.

 > ;; I started a new emacs and ran (setq frame (make-frame '((tool-bar-lines
 > . 0))) ).  Then I set the
 > ;; fullscreen parameter with results indicated below.
 >
 > (set-frame-parameter  frame  'fullscreen  'maximized)
 > ;; The outersize changed to fullscreen, the (real) workarea did not change
 > in size, but it did
 > ;; relocate to Left Top.  In other words the result was very similar to a
 > normal, problem, start.
 >
 > (set-frame-parameter  frame  'fullscreen  'fullboth)
 > ;; From the position above, this caused the outerframe to increase in
 > size, eliminating the frame
 > ;; border.  The workarea moved, further Left Top, but did not change in
 > size.

With other words the behavior is the same regardless of whether you use
`set-frame-parameter', M-F10 or the ‘+’ button on the title bar.

 > (set-frame-parameter  frame  'fullscreen  'fullheight)
 > (set-frame-parameter  frame  'fullscreen  'fullwidth)
 > ;; I have never used these, so I do not know how they are intended to
 > work.  After these, the shape
 > ;; changed to fullheight and fullwidth, respectively.  The other dimension
 > changed to the width and
 > ;; height of the workarea and the whole outershape moved so that it was
 > centered horizontally and
 > ;; vertically respectively.  The attached screenshot shows one of these
 > configurations.

I can't tell about these because you haven't included the
‘frame-geometry’ output but I suppose they won't tell us anything new.

Thanks, martin