bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On any Motif or Lucid build, start Emacs with `-q', making sure that the
splash screen is displayed.  A single pixel at the bottom of the tool
bar will be overwritten by the window underneath it, until the frame is
resized again.

If I comment out this part of xfns.c:

      /* As long as tool_bar_resized is false, effectively try to change
	 F's native height.  */
      if (NILP (fullscreen) || EQ (fullscreen, Qfullwidth))
	adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
			   1, false, Qtool_bar_lines);
      else

The problem goes away, but I can't figure out why that is.

Thanks.

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

 > On any Motif or Lucid build, start Emacs with `-q', making sure that the
 > splash screen is displayed.  A single pixel at the bottom of the tool
 > bar will be overwritten by the window underneath it, until the frame is
 > resized again.
 >
 > If I comment out this part of xfns.c:
 >
 >        /* As long as tool_bar_resized is false, effectively try to change
 > 	 F's native height.  */
 >        if (NILP (fullscreen) || EQ (fullscreen, Qfullwidth))
 > 	adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
 > 			   1, false, Qtool_bar_lines);
 >        else
 >
 > The problem goes away, but I can't figure out why that is.

I cannot reproduce that here, neither with the release branch nor with
master.  See the attached screenshot and notice one pixel between tool
bar and root window that comes from 'tool-bar-border'.

martin

[-- Attachment #2: Lucid-master-emacs-q.png --]
[-- Type: image/png, Size: 138819 bytes --]

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

> I cannot reproduce that here, neither with the release branch nor with
> master.  See the attached screenshot and notice one pixel between tool
> bar and root window that comes from 'tool-bar-border'.

Maybe it's related to some code waiting for a configure event that never
arrives?

FWIW, the window manager I used to test was GNOME Shell.

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[martin rudalics]

 > FWIW, the window manager I used to test was GNOME Shell.

Then the reason is what I told you earlier: In x_wm_set_size_hint in
xterm.c I have


#ifndef USE_GTK
void
x_wm_set_size_hint (struct frame *f, long flags, bool user_position, bool base_size)
{
   XSizeHints size_hints;
   Window window = FRAME_OUTER_WINDOW (f);

   if (!window)
     return;

   /* 2021 REMIX: Don't call widget_update_wm_size_hints here since on
      GNOME shell get_wm_shell may fail to produce the wmshell widget.
      As a consequence, no size hints get set before we issue our resize
      request, mutter (presumably) refuses to resize the outer window as
      requested and we end up with a wrong initial frame size.

      It's not clear whether other calls of update_wm_hints are affected
      as well but not calling widget_update_wm_size_hints here seems
      sufficient to fix the bug.  */

/** #ifdef USE_X_TOOLKIT **/
/**   if (f->output_data.x->widget) **/
/**     { **/
/**       widget_update_wm_size_hints (f->output_data.x->widget); **/
/**       return; **/
/**     } **/
/** #endif **/

   /* Setting PMaxSize caused various problems.  */

...

which works around that problem.  (I didn't try your fix but am
convinced that it gets the initial frame height wrong.)

martin

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

>   /* 2021 REMIX: Don't call widget_update_wm_size_hints here since on
>      GNOME shell get_wm_shell may fail to produce the wmshell widget.
>      As a consequence, no size hints get set before we issue our resize
>      request, mutter (presumably) refuses to resize the outer window as
>      requested and we end up with a wrong initial frame size.
>
>      It's not clear whether other calls of update_wm_hints are affected
>      as well but not calling widget_update_wm_size_hints here seems
>      sufficient to fix the bug.  */
>
> /** #ifdef USE_X_TOOLKIT **/
> /**   if (f->output_data.x->widget) **/
> /**     { **/
> /**       widget_update_wm_size_hints (f->output_data.x->widget); **/
> /**       return; **/
> /**     } **/
> /** #endif **/
>
> which works around that problem.  (I didn't try your fix but am
> convinced that it gets the initial frame height wrong.)

I fixed the calls to widget_update_wm_size_hints on master, and it fixes
the bug, so if you're happy with that fix I'll close this bug now.

Thanks.

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[martin rudalics]

 > I fixed the calls to widget_update_wm_size_hints on master, and it fixes
 > the bug, so if you're happy with that fix I'll close this bug now.

If it works for you, close it.  I do not synch with master these days
because of Bug#52709.

martin

bug#53839: 29.0.50; Strange bug causes tool bar to be overwritten

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

>> I fixed the calls to widget_update_wm_size_hints on master, and it fixes
>> the bug, so if you're happy with that fix I'll close this bug now.

> If it works for you, close it.  I do not synch with master these days
> because of Bug#52709.

Thanks, closing.