bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

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