Subject: Re: bug#26537: Problems with Emacs frame (GTK)

From: martin rudalics <[email-masked]>
Date: Mon, 17 Apr 2017 17:43:16 +0200

Thanks for the dumps.  I see no problems with the frame size so I will
concentrate on the "window width" issue.  Thet fact that setting
‘x-gtk-use-window-move’ can affect the behavior is strange enough to
warrant deeper investigation.

 > For screen-with-desktop-OK.png (from 20170327 build):

 > #<window 3 on report_bug.txt>   parent: #<window 7>
 > char left: 0   top: 0   size: 83 x 48   new: 83

 > #<window 8 on *SPEEDBAR*>   parent: #<window 7>
 > char left: 83   top: 0   size: 30 x 48   new: 30

Here *SPEEDBAR* has a width of 30 characters which is what you wanted in
the first place according to your init.el.  But I have no idea how you
got there.  IIUC your steps were:

(1) Create an initial frame without any desktop involvement.  This
     should be the frame from screen-no-desktop.png.  I would need the
     dump for that frame (from a 20170327 build) first.  And, if it is
     different, a dump of that frame just before you save the desktop.  I
     suppose the screen-with-desktop-OK dump above then would stem from a
     new session using a desktop equivalent to the one saved here.  Is
     that assumption correct?

(2) Next you would have to repeat step (1) for the 20170416 build with
     `x-gtk-use-window-move' at its default t.

If the figures reported for (1) and (2) are both wrong (i.e., the
*SPEEDBAR* is initially not 30 characters wide), we would have to
investigate why.  If the figures reported for (1) and (2) differ, we'd
have to investigate that as well.

 > For screen-with-desktop-NOT_OK.png before saving desktop (from 20170416 build):

 > #<window 3 on *scratch*>   parent: #<window 5>
 > char left: 0   top: 0   size: 72 x 48   new: 48

 > #<window 6 on *SPEEDBAR*>   parent: #<window 5>
 > char left: 72   top: 0   size: 41 x 48   new: 48

Here *SPEEDBAR* has a width of 41 characters which is correctly
preserved in the dump below.

 > For screen-with-desktop-NOT_OK.png after desktop restored (from 20170416 build):

 > #<window 3 on *scratch*>   parent: #<window 7>
 > char left: 0   top: 0   size: 72 x 48   new: 48

 > #<window 8 on *SPEEDBAR*>   parent: #<window 7>
 > char left: 72   top: 0   size: 41 x 48   new: 48

If you think that this behavior is wrong, we'll have to discuss the
principles of the desktop save & restore policy.

If, as you said before, the behavior on Windows deviates from the one
observed here, it would be instructive to see the corresponding frame
dumps for the Windows build as well.

Thanks again, martin