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

[martin rudalics]

> When starting Emacs from a terminal/console window, GTK emits the
> following message in the terminal/console:
>
>    Gtk-WARNING **: gtk_window_parse_geometry() called on a window
>    with no visible children; the window should be set up before
>    gtk_window_parse_geometry() is called.
>
> The message is emitted n - 1 times, where n is the number of
> frames specified in the desktop file; with no desktop file, or
> with a desktop file specifying just the one frame, no such message
> is emitted.

Thinking about this twice - frameset should _not_ try to restore frame
positions by default.  If people think they need it, they should modify
`frameset-filter-alist' appropriately, but by default this option should
be off.  Introducing a gravity parameter might help but ISTR that most
window managers don't handle gravity correctly ...

> Once Emacs is up and running, creating new frames does not cause
> this message to be emitted.

Because IIRC restoring a frameset is the only case where Emacs tries to
position frames by default.

Anyway, I now introduced a variable `x-gtk-use-window-move' which, if
set, should avoid the problems with bug#25851 and bug#25943.  These bugs
are strangely related because they can be fixed (at least here) by
calling gtk_window_move, a function which apparently is capable of
shelving a requested position and pass it on to the window manager when
we eventually ask for mapping the frame via gtk_widget_show_all.

Obviously, my fix might be silly so if anyone has a better idea please
speak up.  The variable is off by default.  If a sufficient number of
people confirm that it works, I'll set it on by default and will mark
this bug as done.

Note that the variable affects GTK builds only and should affect the
behavior of Emacs iff you set frame positions "programmatically" -
either via a geometry specification, a `left' parameter in the arguments
of `make-frame' or `set-frame-parameter(s)' or via `set-frame-position'.
Moving a frame by dragging its title bar is not affected.  Indirectly,
however, all users of the desktop feature are.  So please try it.

Many thanks for the forensics, martin