bug#25851: 25.2; GTK warning when starting Emacs when desktop file has more than one frame

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: 25851@debbugs.gnu.org
> Date: Fri, 24 Feb 2017 15:28:19 -0500
> 
> FWIW, the following expands on the information in my previous
> message.

Thanks, I think this clarifies the picture quite a bit, see below.

> 1. With a desktop file that specifies three frames, the first time
> we enter `xg_set_geometry' after starting Emacs (presumably when
> the first/main Emacs frame is created), `f->size_hint_flags' is 0,
> the body of the function is not executed,
> `gtk_window_parse_geometry' is not called, and no warning message
> is printed by GTK:
> [...]
> 2. Each of the next two times we enter `xg_set_geometry'
> (presumably as the second and third frame specified in the desktop
> file are created), `f->size_hint_flags' is 4, the body of the
> function is executed, `gtk_window_parse_geometry' is called, and
> the warning message is printed by GTK:

Right.  4 is PPosition flag, AFAIU.

The only place where we set the USPosition and PPosition flags in
size_hint_flags field of a frame structure is in function
x_figure_window_size (in frame.c), when the user-position parameter or
the top/left parameters are present in the parameters of the frame
being created.  And that explains the difference between restoring
desktop and simply creating a new frame: frameset.el restores the
frames at their recorded positions, which is why the PPosition flag is
set.  I think you should be able to reproduce the warning with the
likes of "C-x 5 b" and even just by starting Emacs, if you arrange for
frame coordinates to be specified in the frame parameters, e.g. with
the --geometry command-line option when invoking Emacs.

So we are back at square one: we need to understand why the warning
isn't get silenced by this:

      /* Silence warning about visible children.  */
      id = g_log_set_handler ("Gtk", G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL
                              | G_LOG_FLAG_RECURSION, my_log_handler, NULL);

Can you look into the source of g_warning and see why the above
doesn't avoid these warnings, and what should we do to avoid it?

Thanks.