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

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

[N. Jackson]

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.

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

I tried deleting the desktop file and starting fresh, but the
problem persists.

I'm seeing this in rc2 of Emacs 25.2 built from the tarball. I
didn't see it in Emacs 25.1. I do however see it in 25.1.91.

If needed I'm happy to try to find a minimal recipe for this from
`emacs -Q' but I would need some pointers on how to create / read
desktop files from `emacs -Q'.


In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version
 3.22.8) of 2017-02-23 built on moondust.localdomain Windowing
 system distributor 'Fedora Project', version 11.0.11901000 System
 Description: Fedora release 25 (Twenty Five)

Configured using:
 'configure --prefix=/home/nlj/local/ --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3 -ggdb''

Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY GNUTLS
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  pdf-occur-global-minor-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  display-battery-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  save-place-mode: t
  electric-pair-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent messages:
[ REDACTED ]

Load-path shadows:
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-contacts hides ~/.emacs.d/modules/org-contacts
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-habit hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-habit
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-python hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-python
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-clojure hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-clojure
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-md hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-md
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-macs hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-macs
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-odt hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-odt
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-texinfo hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-texinfo
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-protocol hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-protocol
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-io hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-io
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-list hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-list
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-scheme hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-scheme
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-docview hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-docview
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-latex hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-latex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-html hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-html
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-ctags hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-ctags
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-src hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-src
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-octave hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-octave
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-w3m hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-w3m
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-bibtex hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-bibtex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-info hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-info
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-beamer hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-beamer
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-maxima hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-maxima
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-table hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-table
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-R hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-R
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-publish hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-publish
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-mscgen hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-mscgen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-scala hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-scala
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-keys hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-keys
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-css hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-css
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-haskell hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-haskell
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-picolisp hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-picolisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-timer hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-timer
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-feed hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-feed
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-emacs-lisp hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-emacs-lisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-mhe hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-mhe
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-exp hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-exp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-rmail hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-rmail
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-attach hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-attach
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-lilypond hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-lilypond
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-version hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-version
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-makefile hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-makefile
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-sql hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-sql
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-lob hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-lob
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-java hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-java
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-loaddefs hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-loaddefs
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-element hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-element
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-id hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-id
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-crypt hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-crypt
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-plot hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-plot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-ruby hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-ruby
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-matlab hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-matlab
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-ditaa hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-ditaa
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-irc hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-irc
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-gnus hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-gnus
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-C hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-C
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-comint hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-comint
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-colview hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-colview
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-tangle hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-tangle
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-dot hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-dot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-mobile hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-mobile
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-eshell hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-eshell
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-sass hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-sass
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-gnuplot hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-gnuplot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-icalendar hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-icalendar
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-man hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-man
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-capture hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-capture
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-plantuml hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-plantuml
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-footnote hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-footnote
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-clock hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-clock
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-js hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-js
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-latex hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-latex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-ascii hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-ascii
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-ref hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-ref
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-ocaml hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-ocaml
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-agenda hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-agenda
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-indent hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-indent
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-core hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-core
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-pcomplete hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-pcomplete
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-datetree hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-datetree
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-ledger hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-ledger
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-shen hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-shen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-entities hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-entities
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-macro hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-macro
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-mouse hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-mouse
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-sqlite hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-sqlite
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox-org hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox-org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-screen hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-screen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-asymptote hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-asymptote
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-eval hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-eval
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-archive hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-archive
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ox hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ox
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-org hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-perl hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-perl
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-faces hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-faces
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-bbdb hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-bbdb
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-compat hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-compat
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-lisp hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-lisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-install hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-install
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-awk hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-awk
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-calc hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-calc
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/org-inlinetask hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/org-inlinetask
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-table hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-table
/home/nlj/.emacs.d/elpa/org-plus-contrib-20161224/ob-fortran hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/org/ob-fortran
/home/nlj/.emacs.d/elpa/soap-client-3.1.1/soap-client hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/net/soap-client
/home/nlj/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/net/soap-inspect
~/.emacs.d/modules/emms/lisp/tq hides /data/projects/vc/emacs/emacs-25.2.rc2/lisp/emacs-lisp/tq

Features:
(shadow bbdb-message mail-extr emacsbug sendmail mm-archive url-http
url-gw url-cache url-auth url-handlers nnrss xml mm-url nndraft nnmh
utf-7 server pinentry epa-file epa derived network-stream nsm starttls
nnfolder bbdb-gnus bbdb-mua nnnil gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg nntp gnus-cache flyspell ispell sage
sage-load rx emms-bookmarks emms-cue emms-mode-line-icon emms-browser
sort emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd emms-playing-time emms-lyrics emms-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util url-parse url-vars emms-streams emms-tag-editor emms-mark
emms-mode-line emms-cache emms-info-ogginfo emms-info-mp3info emms-info
later-do emms-playlist-mode emms-player-vlc emms-player-mplayer
emms-player-simple emms-source-playlist emms-source-file locate
emms-setup emms emms-compat calfw-org calfw holidays hol-loaddefs cl
pdf-occur ibuf-ext ibuffer tablist tablist-filter semantic/wisent/comp
semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util
semantic semantic/tag semantic/lex semantic/fw mode-local cedet
pdf-isearch let-alist pdf-misc imenu pdf-tools compile cus-edit pdf-view
bookmark pp pdf-cache pdf-info tq pdf-util org-contacts org-capture
gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-sum
gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls
gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range message
rfc822 mml mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus gnus-ems
nnheader mail-utils org-eldoc org-w3m org-rmail org-mhe org-irc org-info
org-habit org-gnus org-docview doc-view subr-x jka-compr image-mode
dired org-bibtex bibtex org-bbdb org-agenda org-element avl-tree org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-latex ob-emacs-lisp ob
ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint tramp
tramp-compat auth-source cl-seq eieio eieio-core cl-macs gnus-util
mm-util help-fns mail-prsvr password-cache tramp-loaddefs trampver
ucs-normalize shell pcomplete advice comint ansi-color ring ob-core
ob-eval org-compat org-macs org-loaddefs format-spec find-func
bbdb-anniv diary-lib diary-loaddefs cal-menu calendar cal-loaddefs
bbdb-com crm mailabbrev bbdb bbdb-site timezone bbdb-loaddefs finder-inf
tex-site info package epg-config seq byte-opt gv bytecomp byte-compile
cl-extra help-mode cconv edmacro kmacro recentf tree-widget wid-edit
easymenu battery time wheatgrass-theme paren savehist saveplace
elec-pair desktop frameset cl-loaddefs pcase cl-lib delsel cua-base
cus-start cus-load time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 550688 26688)
 (symbols 48 99628 0)
 (miscs 40 432 265)
 (strings 32 134429 9535)
 (string-bytes 1 4846315)
 (vectors 16 65023)
 (vector-slots 8 1061254 8856)
 (floats 8 607 650)
 (intervals 56 629 54)
 (buffers 976 31))

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)
> Date: Thu, 23 Feb 2017 11:08:28 -0500
> 
> 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.
> 
> Once Emacs is up and running, creating new frames does not cause
> this message to be emitted.
> 
> I tried deleting the desktop file and starting fresh, but the
> problem persists.
> 
> I'm seeing this in rc2 of Emacs 25.2 built from the tarball. I
> didn't see it in Emacs 25.1. I do however see it in 25.1.91.
> 
> If needed I'm happy to try to find a minimal recipe for this from
> `emacs -Q' but I would need some pointers on how to create / read
> desktop files from `emacs -Q'.

Thanks.  It might be enough if you run Emacs under a debugger with a
breakpoint in the GTK function which emits this warning, then show us
the backtrace from that function.  That should point to the code that
gets executed when it probably shouldn't.

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

[N. Jackson]

At 18:24 +0200 on Thursday 2017-02-23, Eli Zaretskii wrote:
>
> Thanks. It might be enough if you run Emacs under a debugger
> with a breakpoint in the GTK function which emits this warning,
> then show us the backtrace from that function. That should point
> to the code that gets executed when it probably shouldn't.

This warning is emitted by line 11414 of
`gtk_window_parse_geometry' in gtkwindow.c in the gtk+-3.22.8
sources. The code looks like this:

  gboolean
  gtk_window_parse_geometry (GtkWindow   *window,
                             const gchar *geometry)
  {
    gint result, x = 0, y = 0;
    guint w, h;
    GtkWidget *child;
    GdkGravity grav;
    gboolean size_set, pos_set;
    GdkScreen *screen;

    g_return_val_if_fail (GTK_IS_WINDOW (window), FALSE);
    g_return_val_if_fail (geometry != NULL, FALSE);

    child = gtk_bin_get_child (GTK_BIN (window));
    if (!child || !gtk_widget_get_visible (child))
      g_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.");
  ...

There is a note in the commentary preceding the function that
echos the warning message:

   * Note that for gtk_window_parse_geometry() to work as
   * expected, it has to be called when the window has its “final”
   * size, i.e. after calling gtk_widget_show_all() on the
   * contents and gtk_window_set_geometry_hints() on the window.

The only place in the Emacs sources where I see
`gtk_window_parse_geometry' being called is in `xg_set_geometry'
at line 802 of gtkutil.c where the code looks like 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);

  if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
                                  geom_str))
    fprintf (stderr, "Failed to parse: '%s'\n", geom_str);

So it looks like a previous attempt to avoid the warning message
is no longer successful.


As requested, here is the backtrace when the warning is emitted:

#0  0x00000000005657ee in xg_set_geometry (f=0x10aa9f0) at gtkutil.c:806
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x10aa9f0) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x10aa9f0) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=57485619) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffff8ec8) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9400) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffff9a80) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffff9a78) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9a70) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffff9a70) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffff9a68) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffa010) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffa010) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa008) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffa568) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=1, arg_vector=0x7fffffffa560) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa558) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11217524, vector=11217557, maxdepth=22, args_template=2054, nargs=2, args=0x7fffffffaad8) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11217469, nargs=2, arg_vector=0x7fffffffaac8) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=3, args=0x7fffffffaac0) at eval.c:2748
#22 0x000000000067664b in exec_byte_code (bytestr=29837764, vector=20327621, maxdepth=70, args_template=4114, nargs=4, args=0x7fffffffb0e0) at bytecode.c:880
#23 0x000000000062cd50 in funcall_lambda (fun=25722397, nargs=4, arg_vector=0x7fffffffb0c0) at eval.c:2863
#24 0x000000000062c68f in Ffuncall (nargs=5, args=0x7fffffffb0b8) at eval.c:2748
#25 0x000000000067664b in exec_byte_code (bytestr=18636228, vector=22137909, maxdepth=122, args_template=1542, nargs=9, args=0x7fffffffb618) at bytecode.c:880
#26 0x000000000062cd50 in funcall_lambda (fun=21872565, nargs=9, arg_vector=0x7fffffffb610) at eval.c:2863
#27 0x000000000062c68f in Ffuncall (nargs=10, args=0x7fffffffb608) at eval.c:2748
#28 0x000000000067664b in exec_byte_code (bytestr=19811332, vector=21941397, maxdepth=42, args_template=2, nargs=0, args=0x7fffffffbba8) at bytecode.c:880
#29 0x000000000062cd50 in funcall_lambda (fun=21941501, nargs=0, arg_vector=0x7fffffffbba8) at eval.c:2863
#30 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffbba0) at eval.c:2748
#31 0x000000000067664b in exec_byte_code (bytestr=19804484, vector=21941597, maxdepth=66, args_template=1026, nargs=0, args=0x7fffffffc100) at bytecode.c:880
#32 0x000000000062cd50 in funcall_lambda (fun=20574093, nargs=0, arg_vector=0x7fffffffc100) at eval.c:2863
#33 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc0f8) at eval.c:2748
#34 0x000000000067664b in exec_byte_code (bytestr=19384580, vector=18492589, maxdepth=18, args_template=2, nargs=0, args=0x7fffffffc6d0) at bytecode.c:880
#35 0x000000000062cd50 in funcall_lambda (fun=21708709, nargs=0, arg_vector=0x7fffffffc6d0) at eval.c:2863
#36 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc6c8) at eval.c:2748
#37 0x000000000062b780 in funcall_nil (nargs=1, args=0x7fffffffc6c8) at eval.c:2338
#38 0x000000000062bc60 in run_hook_with_args (nargs=1, args=0x7fffffffc6c8, funcall=0x62b75d <funcall_nil>) at eval.c:2515
#39 0x000000000062b807 in Frun_hook_with_args (nargs=1, args=0x7fffffffc6c8) at eval.c:2380
#40 0x000000000062bcea in run_hook (hook=21708709) at eval.c:2528
#41 0x000000000062b7c4 in Frun_hooks (nargs=2, args=0x7fffffffc7d0) at eval.c:2362
#42 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffc7c8) at eval.c:2679
#43 0x000000000067664b in exec_byte_code (bytestr=11253852, vector=11253885, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffcd88) at bytecode.c:880
#44 0x000000000062cd50 in funcall_lambda (fun=11253805, nargs=0, arg_vector=0x7fffffffcd88) at eval.c:2863
#45 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcd80) at eval.c:2748
#46 0x000000000067664b in exec_byte_code (bytestr=11249860, vector=11249893, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd230) at bytecode.c:880
#47 0x000000000062cd50 in funcall_lambda (fun=11249813, nargs=0, arg_vector=0x7fffffffd230) at eval.c:2863
#48 0x000000000062c9f7 in apply_lambda (fun=11249813, args=0, count=4) at eval.c:2800
#49 0x000000000062b026 in eval_sub (form=21000067) at eval.c:2217
#50 0x000000000062a512 in Feval (form=21000067, lexical=0) at eval.c:1994
#51 0x0000000000581380 in top_level_2 () at keyboard.c:1121
#52 0x0000000000628baf in internal_condition_case (bfun=0x58135d <top_level_2>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#53 0x00000000005813c1 in top_level_1 (ignore=0) at keyboard.c:1129
#54 0x000000000062817e in internal_catch (tag=45936, func=0x581382 <top_level_1>, arg=0) at eval.c:1080
#55 0x00000000005812b5 in command_loop () at keyboard.c:1090
#56 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#57 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#58 0x000000000057e832 in main (argc=1, argv=0x7fffffffd758) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffff8ed0)
"x-create-frame-with-faces" (0xffff9408)
0x1550b80 PVEC_COMPILED
"apply" (0xffff9a70)
"frame-creation-function" (0xffffa010)
"make-frame" (0xffffa560)
"make-frame-on-display" (0xffffaac8)
"frameset--restore-frame" (0xffffb0c0)
"frameset-restore" (0xffffb610)
"desktop-restore-frameset" (0xffffbba8)
"desktop-read" (0xffffc100)
0x14b3fa0 PVEC_COMPILED
"run-hooks" (0xffffc7d0)
"command-line" (0xffffcd88)
"normal-top-level" (0xffffd230)


I hopes this helps and please let me know if I can provide further
information. Thanks.

N.

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: Thu, 23 Feb 2017 21:33:33 -0500
> 
> At 18:24 +0200 on Thursday 2017-02-23, Eli Zaretskii wrote:
> >
> > Thanks. It might be enough if you run Emacs under a debugger
> > with a breakpoint in the GTK function which emits this warning,
> > then show us the backtrace from that function. That should point
> > to the code that gets executed when it probably shouldn't.
> 
> This warning is emitted by line 11414 of
> `gtk_window_parse_geometry' in gtkwindow.c in the gtk+-3.22.8
> sources. The code looks like this:

Thanks for the footwork and all the useful information this
uncovered.  I will look closer at that later, but right now I believe
I am (or was) confused...

> Lisp Backtrace:
> "x-create-frame" (0xffff8ed0)
> "x-create-frame-with-faces" (0xffff9408)
> 0x1550b80 PVEC_COMPILED
> "apply" (0xffff9a70)
> "frame-creation-function" (0xffffa010)
> "make-frame" (0xffffa560)
> "make-frame-on-display" (0xffffaac8)
> "frameset--restore-frame" (0xffffb0c0)
> "frameset-restore" (0xffffb610)
> "desktop-restore-frameset" (0xffffbba8)
> "desktop-read" (0xffffc100)

This seems to indicate Emacs is restoring desktop into a new GUI
session.  But in your original report you said:

> When starting Emacs from a terminal/console window, GTK emits the
> following message

which I interpreted to mean you were starting "emacs -nw".  Did I
misinterpret what you were saying?  If so, what is the significance of
the "terminal/console window" part?

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

[N. Jackson]

At 10:07 +0200 on Friday 2017-02-24, Eli Zaretskii wrote:

> right now I believe I am (or was) confused...
>
>> Lisp Backtrace:
>> "x-create-frame" (0xffff8ed0)
>> "x-create-frame-with-faces" (0xffff9408)
>> 0x1550b80 PVEC_COMPILED
>> "apply" (0xffff9a70)
>> "frame-creation-function" (0xffffa010)
>> "make-frame" (0xffffa560)
>> "make-frame-on-display" (0xffffaac8)
>> "frameset--restore-frame" (0xffffb0c0)
>> "frameset-restore" (0xffffb610)
>> "desktop-restore-frameset" (0xffffbba8)
>> "desktop-read" (0xffffc100)
>
> This seems to indicate Emacs is restoring desktop into a new GUI
> session.  But in your original report you said:
>
>> When starting Emacs from a terminal/console window, GTK emits
>> the following message
>
> which I interpreted to mean you were starting "emacs -nw". Did I
> misinterpret what you were saying?  If so, what is the
> significance of the "terminal/console window" part?

Sorry for the confusion there, Eli. What I mean(t) is that I start
a new GUI Emacs by entering

  src/emacs &

in a terminal/console such as XTerm or Konsole. (This is how I
normally start Emacs.)

The only relevance of the start from the terminal/console is that
I then see the warnings and errors emitted. (If I had started it
from the window manager / desktop environment then those would not
be visible to me.)

N.

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

[N. Jackson]

At 08:41 -0500 on Friday 2017-02-24, N. Jackson wrote:
>
> What I mean(t) is that I start a new GUI Emacs by entering
>
>   src/emacs &
>
> in a terminal/console such as XTerm or Konsole. (This is how I
> normally start Emacs.)

Properly I should call it a graphical terminal emulator, I guess.
Without being aware, one gets sloppy referring to things in one's
every day world!

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 08:41:15 -0500
> 
> Sorry for the confusion there, Eli. What I mean(t) is that I start
> a new GUI Emacs by entering
> 
>   src/emacs &
> 
> in a terminal/console such as XTerm or Konsole. (This is how I
> normally start Emacs.)
> 
> The only relevance of the start from the terminal/console is that
> I then see the warnings and errors emitted. (If I had started it
> from the window manager / desktop environment then those would not
> be visible to me.)

Right, got it.

So the question now becomes: how is invoking x-create-frame-with-faces
via frameset-restore is different from the same operation invoked,
say, via "C-x 5 b"?  (I understand that the latter doesn't cause GTK
to emit the warning, right?)

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

[N. Jackson]

At 16:10 +0200 on Friday 2017-02-24, Eli Zaretskii wrote:
>
> So the question now becomes: how is invoking
> x-create-frame-with-faces via frameset-restore is different from
> the same operation invoked, say, via "C-x 5 b"? (I understand
> that the latter doesn't cause GTK to emit the warning, right?)

Right. And the answer is that with `C-x 5 2' (and `C-x 5 b'),
while `xg_set_geometry' is called, the body of it seems to be
skipped [you had better check my use of GDB, here because the
results confuse me so maybe I'm using it wrong] so
`gtk_window_parse_geometry' never gets called.

For convenience, the full code, with line numbers, of
`xg_set_geometry' is:

  (gdb) list gtkutil.c:780
  775     static void
  776     xg_set_geometry (struct frame *f)
  777     {
  778       if (f->size_hint_flags & (USPosition | PPosition))
  779         {
  780           int left = f->left_pos;
  781           int xneg = f->size_hint_flags & XNegative;
  782           int top = f->top_pos;
  783           int yneg = f->size_hint_flags & YNegative;
  784           char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
  (gdb) list +20
  800                                   | G_LOG_FLAG_RECURSION, my_log_handler, NULL);
  801
  802           if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
  803                                           geom_str))
  804             fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
  805
  806           g_log_remove_handler ("Gtk", id);
  807         }
  808     }
  809

This is my interaction with GDB after `C-x 5 2':

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x386d000) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) print f->size_hint_flags 
  $3 = 0
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) print (USPosition | PPosition)
  No symbol "USPosition" in current context.
  (gdb) print (f->size_hint_flags & (USPosition | PPosition))
  No symbol "USPosition" in current context.
  (gdb) n
  808     }
  (gdb)

Is my syntax wrong when I try to get the values?

Thanks.

N.

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

[N. Jackson]

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

At 11:09 -0500 on Friday 2017-02-24, N. Jackson wrote:
>
>   (gdb) list gtkutil.c:780
>   775     static void
>   776     xg_set_geometry (struct frame *f)
>   777     {
>   778       if (f->size_hint_flags & (USPosition | PPosition))
>   779         {
>   780           int left = f->left_pos;
>   781           int xneg = f->size_hint_flags & XNegative;
>   782           int top = f->top_pos;
>   783           int yneg = f->size_hint_flags & YNegative;
>   784           char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
>   (gdb) list +20
>   800                                   | G_LOG_FLAG_RECURSION, my_log_handler, NULL);
>   801
>   802           if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
>   803                                           geom_str))
>   804             fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
>   805
>   806           g_log_remove_handler ("Gtk", id);
>   807         }
>   808     }
>   809

FWIW, the following expands on the information in my previous
message.

I have breakpoints set a) at the entry to `xg_set_geometry' so
that I can see when it is called even when the body is not
executed, b) at the call to `gtk_window_parse_geometry' (line
802), and c) at line 806 just after the call to
`gtk_window_parse_geometry' so I can see if the GTK warning
message is emitted.

  (gdb) break xg_set_geometry 
  Breakpoint 3 at 0x5656b4: file gtkutil.c, line 778.
  (gdb) break gtkutil.c:802   
  Breakpoint 4 at 0x565799: file gtkutil.c, line 802.
  (gdb) break gtkutil.c:806
  Breakpoint 5 at 0x5657ee: file gtkutil.c, line 806.

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:

  (gdb) run
  Starting program: /data/projects/vc/emacs/emacs-25.2.rc2/src/emacs 
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  [New Thread 0x7fffe166d700 (LWP 15522)]
  [New Thread 0x7fffe07fa700 (LWP 15523)]
  [New Thread 0x7fffde714700 (LWP 15524)]

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x13b4c30) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) bt
  [ *See bt-first-no-warning.txt attached* ]
  (gdb) print f->size_hint_flags 
  $9 = 0
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) s
  808     }
  (gdb) c
  Continuing.
  Detaching after vfork from child process 15530.
  Detaching after vfork from child process 15531.
  Detaching after vfork from child process 15532.
  Detaching after vfork from child process 15533.
  Detaching after vfork from child process 15534.
  Detaching after vfork from child process 15536.
  Detaching after vfork from child process 15537.
  Detaching after vfork from child process 15538.
  Detaching after vfork from child process 15539.
  Detaching after vfork from child process 15540.
  Detaching after vfork from child process 15541.
  Detaching after vfork from child process 15542.
  Detaching after vfork from child process 15543.
  Detaching after vfork from child process 15544.
  Detaching after vfork from child process 15545.
  Detaching after vfork from child process 15546.
  Detaching after vfork from child process 15547.
  Detaching after vfork from child process 15548.
  Detaching after vfork from child process 15549.
  Detaching after vfork from child process 15550.
  Detaching after vfork from child process 15551.

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:

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x31d79a0) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) bt
  [ *See bt-second-warns.txt attached* ]
  (gdb) print f->size_hint_flags 
  $10 = 4
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) s
  780           int left = f->left_pos;
  (gdb) c
  Continuing.

  Thread 1 "emacs" hit Breakpoint 4, xg_set_geometry (f=0x31d79a0) at gtkutil.c:802
  802           if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
  (gdb) c
  Continuing.

  (emacs:15521): 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.

  Thread 1 "emacs" hit Breakpoint 5, xg_set_geometry (f=0x31d79a0) at gtkutil.c:806
  806           g_log_remove_handler ("Gtk", id);
  (gdb) c
  Continuing.

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x390cdc8) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) bt
  [ *See bt-third-warns.txt attached* ]
  (gdb) print f->size_hint_flags 
  $11 = 4
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) s
  780           int left = f->left_pos;
  (gdb) c
  Continuing.

  Thread 1 "emacs" hit Breakpoint 4, xg_set_geometry (f=0x390cdc8) at gtkutil.c:802
  802           if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
  (gdb) c
  Continuing.

  (emacs:15521): 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.

  Thread 1 "emacs" hit Breakpoint 5, xg_set_geometry (f=0x390cdc8) at gtkutil.c:806
  806           g_log_remove_handler ("Gtk", id);
  (gdb) c
  Continuing.

3. Now, creating a frame interactively with `C-x 5 2', we enter
`xg_set_geometry', `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:

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x472a1a0) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) bt
  [ *See bt-interactive-no-warning.txt attached* ]
  (gdb) print f->size_hint_flags 
  $12 = 0
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) s
  808     }
  (gdb) c
  Continuing.

4. Finally, starting a new instance with no desktop file, we enter
`xg_set_geometry' just once, `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:

  (gdb) run --no-desktop
  Starting program: /data/projects/vc/emacs/emacs-25.2.rc2/src/emacs --no-desktop
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  [New Thread 0x7fffe166d700 (LWP 16966)]
  [New Thread 0x7fffe07fa700 (LWP 16967)]
  [New Thread 0x7fffde714700 (LWP 16968)]

  Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x13b4c30) at gtkutil.c:778
  778       if (f->size_hint_flags & (USPosition | PPosition))
  (gdb) bt
  [ *See bt-no-desktop-no-warning.txt attached* ]
  (gdb) print f->size_hint_flags 
  $14 = 0
  (gdb) print USPosition
  No symbol "USPosition" in current context.
  (gdb) print PPosition
  No symbol "PPosition" in current context.
  (gdb) s
  808     }
  (gdb) c
  Continuing.
  Detaching after vfork from child process 16971.
  Detaching after vfork from child process 16973.
  Detaching after vfork from child process 16974.
  Detaching after vfork from child process 16975.
  Detaching after vfork from child process 16976.
  Detaching after vfork from child process 16978.
  Detaching after vfork from child process 16979.
  Detaching after vfork from child process 16980.
  Detaching after vfork from child process 16981.
  Detaching after vfork from child process 16982.
  Detaching after vfork from child process 16983.
  Detaching after vfork from child process 16984.


(Note: I don't understand why the variables USPosition' and
`PPosition' (or are they preprocessor macros?) are reported to be
undefined. I don't understand how the bit mask in the conditional
could execute if this were true.)



[-- Attachment #2: bt-first-no-warning.txt --]
[-- Type: text/plain, Size: 4010 bytes --]

#0  0x00000000005656b4 in xg_set_geometry (f=0x13b4c30) at gtkutil.c:778
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x13b4c30) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x13b4c30) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=18836883) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffffac08) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb140) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffffb7c0) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffffb7b8) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb7b0) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffffb7b0) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffb7a8) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffbd50) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffbd50) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffbd48) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffc298) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=1, arg_vector=0x7fffffffc290) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffc288) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11215204, vector=11215237, maxdepth=26, args_template=2, nargs=0, args=0x7fffffffc7d0) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11215157, nargs=0, arg_vector=0x7fffffffc7d0) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc7c8) at eval.c:2748
#22 0x000000000067664b in exec_byte_code (bytestr=11253852, vector=11253885, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffcd88) at bytecode.c:880
#23 0x000000000062cd50 in funcall_lambda (fun=11253805, nargs=0, arg_vector=0x7fffffffcd88) at eval.c:2863
#24 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcd80) at eval.c:2748
#25 0x000000000067664b in exec_byte_code (bytestr=11249860, vector=11249893, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd230) at bytecode.c:880
#26 0x000000000062cd50 in funcall_lambda (fun=11249813, nargs=0, arg_vector=0x7fffffffd230) at eval.c:2863
#27 0x000000000062c9f7 in apply_lambda (fun=11249813, args=0, count=4) at eval.c:2800
#28 0x000000000062b026 in eval_sub (form=21000067) at eval.c:2217
#29 0x000000000062a512 in Feval (form=21000067, lexical=0) at eval.c:1994
#30 0x0000000000581380 in top_level_2 () at keyboard.c:1121
#31 0x0000000000628baf in internal_condition_case (bfun=0x58135d <top_level_2>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#32 0x00000000005813c1 in top_level_1 (ignore=0) at keyboard.c:1129
#33 0x000000000062817e in internal_catch (tag=45936, func=0x581382 <top_level_1>, arg=0) at eval.c:1080
#34 0x00000000005812b5 in command_loop () at keyboard.c:1090
#35 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#36 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#37 0x000000000057e832 in main (argc=1, argv=0x7fffffffd758) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffffac10)
"x-create-frame-with-faces" (0xffffb148)
0x1550b80 PVEC_COMPILED
"apply" (0xffffb7b0)
"frame-creation-function" (0xffffbd50)
"make-frame" (0xffffc290)
"frame-initialize" (0xffffc7d0)
"command-line" (0xffffcd88)
"normal-top-level" (0xffffd230)

[-- Attachment #3: bt-second-warns.txt --]
[-- Type: text/plain, Size: 6461 bytes --]

#0  0x00000000005656b4 in xg_set_geometry (f=0x31d79a0) at gtkutil.c:778
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x31d79a0) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x31d79a0) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=61360467) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffff8ec8) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9400) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffff9a80) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffff9a78) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9a70) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffff9a70) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffff9a68) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffa010) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffa010) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa008) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffa568) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=1, arg_vector=0x7fffffffa560) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa558) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11217524, vector=11217557, maxdepth=22, args_template=2054, nargs=2, args=0x7fffffffaad8) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11217469, nargs=2, arg_vector=0x7fffffffaac8) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=3, args=0x7fffffffaac0) at eval.c:2748
#22 0x000000000067664b in exec_byte_code (bytestr=26778052, vector=20327621, maxdepth=70, args_template=4114, nargs=4, args=0x7fffffffb0e0) at bytecode.c:880
#23 0x000000000062cd50 in funcall_lambda (fun=25718301, nargs=4, arg_vector=0x7fffffffb0c0) at eval.c:2863
#24 0x000000000062c68f in Ffuncall (nargs=5, args=0x7fffffffb0b8) at eval.c:2748
#25 0x000000000067664b in exec_byte_code (bytestr=18636164, vector=22137909, maxdepth=122, args_template=1542, nargs=9, args=0x7fffffffb618) at bytecode.c:880
#26 0x000000000062cd50 in funcall_lambda (fun=21872565, nargs=9, arg_vector=0x7fffffffb610) at eval.c:2863
#27 0x000000000062c68f in Ffuncall (nargs=10, args=0x7fffffffb608) at eval.c:2748
#28 0x000000000067664b in exec_byte_code (bytestr=19811332, vector=21941397, maxdepth=42, args_template=2, nargs=0, args=0x7fffffffbba8) at bytecode.c:880
#29 0x000000000062cd50 in funcall_lambda (fun=21941501, nargs=0, arg_vector=0x7fffffffbba8) at eval.c:2863
#30 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffbba0) at eval.c:2748
#31 0x000000000067664b in exec_byte_code (bytestr=19804484, vector=21941597, maxdepth=66, args_template=1026, nargs=0, args=0x7fffffffc100) at bytecode.c:880
#32 0x000000000062cd50 in funcall_lambda (fun=20574093, nargs=0, arg_vector=0x7fffffffc100) at eval.c:2863
#33 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc0f8) at eval.c:2748
#34 0x000000000067664b in exec_byte_code (bytestr=19384388, vector=18492589, maxdepth=18, args_template=2, nargs=0, args=0x7fffffffc6d0) at bytecode.c:880
#35 0x000000000062cd50 in funcall_lambda (fun=21708709, nargs=0, arg_vector=0x7fffffffc6d0) at eval.c:2863
#36 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc6c8) at eval.c:2748
#37 0x000000000062b780 in funcall_nil (nargs=1, args=0x7fffffffc6c8) at eval.c:2338
#38 0x000000000062bc60 in run_hook_with_args (nargs=1, args=0x7fffffffc6c8, funcall=0x62b75d <funcall_nil>) at eval.c:2515
#39 0x000000000062b807 in Frun_hook_with_args (nargs=1, args=0x7fffffffc6c8) at eval.c:2380
#40 0x000000000062bcea in run_hook (hook=21708709) at eval.c:2528
#41 0x000000000062b7c4 in Frun_hooks (nargs=2, args=0x7fffffffc7d0) at eval.c:2362
#42 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffc7c8) at eval.c:2679
#43 0x000000000067664b in exec_byte_code (bytestr=11253852, vector=11253885, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffcd88) at bytecode.c:880
#44 0x000000000062cd50 in funcall_lambda (fun=11253805, nargs=0, arg_vector=0x7fffffffcd88) at eval.c:2863
#45 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcd80) at eval.c:2748
#46 0x000000000067664b in exec_byte_code (bytestr=11249860, vector=11249893, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd230) at bytecode.c:880
#47 0x000000000062cd50 in funcall_lambda (fun=11249813, nargs=0, arg_vector=0x7fffffffd230) at eval.c:2863
#48 0x000000000062c9f7 in apply_lambda (fun=11249813, args=0, count=4) at eval.c:2800
#49 0x000000000062b026 in eval_sub (form=21000067) at eval.c:2217
#50 0x000000000062a512 in Feval (form=21000067, lexical=0) at eval.c:1994
#51 0x0000000000581380 in top_level_2 () at keyboard.c:1121
#52 0x0000000000628baf in internal_condition_case (bfun=0x58135d <top_level_2>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#53 0x00000000005813c1 in top_level_1 (ignore=0) at keyboard.c:1129
#54 0x000000000062817e in internal_catch (tag=45936, func=0x581382 <top_level_1>, arg=0) at eval.c:1080
#55 0x00000000005812b5 in command_loop () at keyboard.c:1090
#56 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#57 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#58 0x000000000057e832 in main (argc=1, argv=0x7fffffffd758) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffff8ed0)
"x-create-frame-with-faces" (0xffff9408)
0x1550b80 PVEC_COMPILED
"apply" (0xffff9a70)
"frame-creation-function" (0xffffa010)
"make-frame" (0xffffa560)
"make-frame-on-display" (0xffffaac8)
"frameset--restore-frame" (0xffffb0c0)
"frameset-restore" (0xffffb610)
"desktop-restore-frameset" (0xffffbba8)
"desktop-read" (0xffffc100)
0x14b3fa0 PVEC_COMPILED
"run-hooks" (0xffffc7d0)
"command-line" (0xffffcd88)
"normal-top-level" (0xffffd230)

[-- Attachment #4: bt-third-warns.txt --]
[-- Type: text/plain, Size: 6461 bytes --]

#0  0x00000000005656b4 in xg_set_geometry (f=0x390cdc8) at gtkutil.c:778
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x390cdc8) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x390cdc8) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=60954691) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffff8ec8) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9400) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffff9a80) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffff9a78) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffff9a70) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffff9a70) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffff9a68) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffa010) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffa010) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa008) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffa568) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=1, arg_vector=0x7fffffffa560) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffa558) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11217524, vector=11217557, maxdepth=22, args_template=2054, nargs=2, args=0x7fffffffaad8) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11217469, nargs=2, arg_vector=0x7fffffffaac8) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=3, args=0x7fffffffaac0) at eval.c:2748
#22 0x000000000067664b in exec_byte_code (bytestr=26778052, vector=20327621, maxdepth=70, args_template=4114, nargs=4, args=0x7fffffffb0e0) at bytecode.c:880
#23 0x000000000062cd50 in funcall_lambda (fun=25718301, nargs=4, arg_vector=0x7fffffffb0c0) at eval.c:2863
#24 0x000000000062c68f in Ffuncall (nargs=5, args=0x7fffffffb0b8) at eval.c:2748
#25 0x000000000067664b in exec_byte_code (bytestr=18636164, vector=22137909, maxdepth=122, args_template=1542, nargs=9, args=0x7fffffffb618) at bytecode.c:880
#26 0x000000000062cd50 in funcall_lambda (fun=21872565, nargs=9, arg_vector=0x7fffffffb610) at eval.c:2863
#27 0x000000000062c68f in Ffuncall (nargs=10, args=0x7fffffffb608) at eval.c:2748
#28 0x000000000067664b in exec_byte_code (bytestr=19811332, vector=21941397, maxdepth=42, args_template=2, nargs=0, args=0x7fffffffbba8) at bytecode.c:880
#29 0x000000000062cd50 in funcall_lambda (fun=21941501, nargs=0, arg_vector=0x7fffffffbba8) at eval.c:2863
#30 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffbba0) at eval.c:2748
#31 0x000000000067664b in exec_byte_code (bytestr=19804484, vector=21941597, maxdepth=66, args_template=1026, nargs=0, args=0x7fffffffc100) at bytecode.c:880
#32 0x000000000062cd50 in funcall_lambda (fun=20574093, nargs=0, arg_vector=0x7fffffffc100) at eval.c:2863
#33 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc0f8) at eval.c:2748
#34 0x000000000067664b in exec_byte_code (bytestr=19384388, vector=18492589, maxdepth=18, args_template=2, nargs=0, args=0x7fffffffc6d0) at bytecode.c:880
#35 0x000000000062cd50 in funcall_lambda (fun=21708709, nargs=0, arg_vector=0x7fffffffc6d0) at eval.c:2863
#36 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc6c8) at eval.c:2748
#37 0x000000000062b780 in funcall_nil (nargs=1, args=0x7fffffffc6c8) at eval.c:2338
#38 0x000000000062bc60 in run_hook_with_args (nargs=1, args=0x7fffffffc6c8, funcall=0x62b75d <funcall_nil>) at eval.c:2515
#39 0x000000000062b807 in Frun_hook_with_args (nargs=1, args=0x7fffffffc6c8) at eval.c:2380
#40 0x000000000062bcea in run_hook (hook=21708709) at eval.c:2528
#41 0x000000000062b7c4 in Frun_hooks (nargs=2, args=0x7fffffffc7d0) at eval.c:2362
#42 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffc7c8) at eval.c:2679
#43 0x000000000067664b in exec_byte_code (bytestr=11253852, vector=11253885, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffcd88) at bytecode.c:880
#44 0x000000000062cd50 in funcall_lambda (fun=11253805, nargs=0, arg_vector=0x7fffffffcd88) at eval.c:2863
#45 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcd80) at eval.c:2748
#46 0x000000000067664b in exec_byte_code (bytestr=11249860, vector=11249893, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd230) at bytecode.c:880
#47 0x000000000062cd50 in funcall_lambda (fun=11249813, nargs=0, arg_vector=0x7fffffffd230) at eval.c:2863
#48 0x000000000062c9f7 in apply_lambda (fun=11249813, args=0, count=4) at eval.c:2800
#49 0x000000000062b026 in eval_sub (form=21000067) at eval.c:2217
#50 0x000000000062a512 in Feval (form=21000067, lexical=0) at eval.c:1994
#51 0x0000000000581380 in top_level_2 () at keyboard.c:1121
#52 0x0000000000628baf in internal_condition_case (bfun=0x58135d <top_level_2>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#53 0x00000000005813c1 in top_level_1 (ignore=0) at keyboard.c:1129
#54 0x000000000062817e in internal_catch (tag=45936, func=0x581382 <top_level_1>, arg=0) at eval.c:1080
#55 0x00000000005812b5 in command_loop () at keyboard.c:1090
#56 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#57 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#58 0x000000000057e832 in main (argc=1, argv=0x7fffffffd758) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffff8ed0)
"x-create-frame-with-faces" (0xffff9408)
0x1550b80 PVEC_COMPILED
"apply" (0xffff9a70)
"frame-creation-function" (0xffffa010)
"make-frame" (0xffffa560)
"make-frame-on-display" (0xffffaac8)
"frameset--restore-frame" (0xffffb0c0)
"frameset-restore" (0xffffb610)
"desktop-restore-frameset" (0xffffbba8)
"desktop-read" (0xffffc100)
0x14b3fa0 PVEC_COMPILED
"run-hooks" (0xffffc7d0)
"command-line" (0xffffcd88)
"normal-top-level" (0xffffd230)

[-- Attachment #5: bt-interactive-no-warning.txt --]
[-- Type: text/plain, Size: 4103 bytes --]

#0  0x00000000005656b4 in xg_set_geometry (f=0x472a1a0) at gtkutil.c:778
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x472a1a0) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x472a1a0) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=74635283) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffffada8) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb2e0) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffffb960) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffffb958) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb950) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffffb950) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffb948) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffbef0) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffbef0) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffbee8) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=0, args=0x7fffffffc430) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=0, arg_vector=0x7fffffffc430) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc428) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11218412, vector=11218445, maxdepth=10, args_template=2, nargs=0, args=0x7fffffffcae0) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11218357, nargs=0, arg_vector=0x7fffffffcae0) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcad8) at eval.c:2748
#22 0x0000000000622c37 in Ffuncall_interactively (nargs=1, args=0x7fffffffcad8) at callint.c:252
#23 0x000000000062c2d5 in Ffuncall (nargs=2, args=0x7fffffffcad0) at eval.c:2679
#24 0x000000000062b31d in Fapply (nargs=3, args=0x7fffffffcad0) at eval.c:2280
#25 0x000000000062313d in Fcall_interactively (function=5525680, record_flag=0, keys=14644629) at callint.c:389
#26 0x000000000062c47b in Ffuncall (nargs=4, args=0x7fffffffcd58) at eval.c:2706
#27 0x000000000067664b in exec_byte_code (bytestr=10945124, vector=10945157, maxdepth=54, args_template=4102, nargs=1, args=0x7fffffffd2b0) at bytecode.c:880
#28 0x000000000062cd50 in funcall_lambda (fun=10945077, nargs=1, arg_vector=0x7fffffffd2a8) at eval.c:2863
#29 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffd2a0) at eval.c:2748
#30 0x000000000062bdd3 in call1 (fn=14832, arg1=5525680) at eval.c:2558
#31 0x0000000000581f12 in command_loop_1 () at keyboard.c:1484
#32 0x0000000000628baf in internal_condition_case (bfun=0x5816f8 <command_loop_1>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#33 0x000000000058133a in command_loop_2 (ignore=0) at keyboard.c:1112
#34 0x000000000062817e in internal_catch (tag=45936, func=0x581311 <command_loop_2>, arg=0) at eval.c:1080
#35 0x00000000005812dc in command_loop () at keyboard.c:1091
#36 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#37 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#38 0x000000000057e832 in main (argc=1, argv=0x7fffffffd758) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffffadb0)
"x-create-frame-with-faces" (0xffffb2e8)
0x1550b80 PVEC_COMPILED
"apply" (0xffffb950)
"frame-creation-function" (0xffffbef0)
"make-frame" (0xffffc430)
"make-frame-command" (0xffffcae0)
"funcall-interactively" (0xffffcad8)
"call-interactively" (0xffffcd60)
"command-execute" (0xffffd2a8)

[-- Attachment #6: bt-no-desktop-no-warning.txt --]
[-- Type: text/plain, Size: 4010 bytes --]

#0  0x00000000005656b4 in xg_set_geometry (f=0x13b4c30) at gtkutil.c:778
#1  0x00000000005667cf in xg_create_frame_widgets (f=0x13b4c30) at gtkutil.c:1216
#2  0x000000000054fc76 in x_window (f=0x13b4c30) at xfns.c:2727
#3  0x0000000000551d79 in Fx_create_frame (parms=18836851) at xfns.c:3484
#4  0x000000000062c40d in Ffuncall (nargs=2, args=0x7fffffffabf8) at eval.c:2699
#5  0x000000000067664b in exec_byte_code (bytestr=10582108, vector=10582141, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#6  0x000000000062d16f in funcall_lambda (fun=10582045, nargs=1, arg_vector=0xa1787d <pure+531805>) at eval.c:2929
#7  0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb130) at eval.c:2748
#8  0x000000000067664b in exec_byte_code (bytestr=23626564, vector=14868461, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffffb7b0) at bytecode.c:880
#9  0x000000000062cd50 in funcall_lambda (fun=22350725, nargs=1, arg_vector=0x7fffffffb7a8) at eval.c:2863
#10 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffb7a0) at eval.c:2748
#11 0x000000000062b382 in Fapply (nargs=2, args=0x7fffffffb7a0) at eval.c:2284
#12 0x000000000062c2d5 in Ffuncall (nargs=3, args=0x7fffffffb798) at eval.c:2679
#13 0x000000000067664b in exec_byte_code (bytestr=23644068, vector=21208917, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffbd40) at bytecode.c:880
#14 0x000000000062cd50 in funcall_lambda (fun=19980181, nargs=1, arg_vector=0x7fffffffbd40) at eval.c:2863
#15 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffbd38) at eval.c:2748
#16 0x000000000067664b in exec_byte_code (bytestr=11218740, vector=11218773, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffc288) at bytecode.c:880
#17 0x000000000062cd50 in funcall_lambda (fun=11218685, nargs=1, arg_vector=0x7fffffffc280) at eval.c:2863
#18 0x000000000062c68f in Ffuncall (nargs=2, args=0x7fffffffc278) at eval.c:2748
#19 0x000000000067664b in exec_byte_code (bytestr=11215204, vector=11215237, maxdepth=26, args_template=2, nargs=0, args=0x7fffffffc7c0) at bytecode.c:880
#20 0x000000000062cd50 in funcall_lambda (fun=11215157, nargs=0, arg_vector=0x7fffffffc7c0) at eval.c:2863
#21 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffc7b8) at eval.c:2748
#22 0x000000000067664b in exec_byte_code (bytestr=11253852, vector=11253885, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffcd78) at bytecode.c:880
#23 0x000000000062cd50 in funcall_lambda (fun=11253805, nargs=0, arg_vector=0x7fffffffcd78) at eval.c:2863
#24 0x000000000062c68f in Ffuncall (nargs=1, args=0x7fffffffcd70) at eval.c:2748
#25 0x000000000067664b in exec_byte_code (bytestr=11249860, vector=11249893, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd220) at bytecode.c:880
#26 0x000000000062cd50 in funcall_lambda (fun=11249813, nargs=0, arg_vector=0x7fffffffd220) at eval.c:2863
#27 0x000000000062c9f7 in apply_lambda (fun=11249813, args=0, count=4) at eval.c:2800
#28 0x000000000062b026 in eval_sub (form=21000067) at eval.c:2217
#29 0x000000000062a512 in Feval (form=21000067, lexical=0) at eval.c:1994
#30 0x0000000000581380 in top_level_2 () at keyboard.c:1121
#31 0x0000000000628baf in internal_condition_case (bfun=0x58135d <top_level_2>, handlers=19104, hfun=0x580d8a <cmd_error>) at eval.c:1315
#32 0x00000000005813c1 in top_level_1 (ignore=0) at keyboard.c:1129
#33 0x000000000062817e in internal_catch (tag=45936, func=0x581382 <top_level_1>, arg=0) at eval.c:1080
#34 0x00000000005812b5 in command_loop () at keyboard.c:1090
#35 0x000000000058087a in recursive_edit_1 () at keyboard.c:697
#36 0x0000000000580a7a in Frecursive_edit () at keyboard.c:768
#37 0x000000000057e832 in main (argc=2, argv=0x7fffffffd748) at emacs.c:1629

Lisp Backtrace:
"x-create-frame" (0xffffac00)
"x-create-frame-with-faces" (0xffffb138)
0x1550b80 PVEC_COMPILED
"apply" (0xffffb7a0)
"frame-creation-function" (0xffffbd40)
"make-frame" (0xffffc280)
"frame-initialize" (0xffffc7c0)
"command-line" (0xffffcd78)
"normal-top-level" (0xffffd220)

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.

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

[N. Jackson]

At 10:17 +0200 on Saturday 2017-02-25, Eli Zaretskii wrote:
>
> 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?

Hello Eli,

I was unsuccessful in this assignment (so far at least). I suspect
the answer is that GTK is using structured logging, but that is
just a wild guess at this point.

[I don't know how to do source-level debugging of code that I
didn't build myself. Both glib and Gtk+ on my system were
built/installed by the distribution's package manager and I have
only the source code from upstream, not the source code for the
exact versions on my system.]

I did ascertain that the log handler `my_log_handler' that we
install in the code snippet above is never called.

For testing purposes, I also installed a catch-all handler, with
g_log_set_default_handler(), and that doesn't get called either.

I have no direct experience at all with either glib or Gtk+, but
the documentation at [1] [I don't know for what version this is
for, or if it's even relevant], seems to say that
g_log_set_handler() has no effect if structured logging is turned
on. It seems to say that structured logging is in effect if
G_LOG_USE_STRUCTURED is defined.

There is some indication that Gtk+3.22.8 might use the new
structured logging. For example:

  $ grep -rn "G_LOG_USE_STRUCTURED" /data/projects/vc/gtk+-3.22.8/                             
  /data/projects/vc/gtk+-3.22.8/gdk/mir/Makefile.in:526:  -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/mir/Makefile.am:9:    -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/Makefile.in:697:      -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/win32/Makefile.in:602:        -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/win32/Makefile.am:9:  -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/wayland/Makefile.in:537:      -DG_LOG_USE_STRUCTURED=1                \
  /data/projects/vc/gtk+-3.22.8/gdk/wayland/Makefile.am:9:        -DG_LOG_USE_STRUCTURED=1                \
  /data/projects/vc/gtk+-3.22.8/gdk/Makefile.am:38:       -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/x11/Makefile.in:535:  -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/x11/Makefile.am:9:    -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/quartz/Makefile.in:531:       -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/quartz/Makefile.am:8: -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/broadway/Makefile.in:574:     -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/broadway/Makefile.am:10:      -DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gtk/Makefile.in:1325:     -DG_LOG_USE_STRUCTURED=1                        \
  /data/projects/vc/gtk+-3.22.8/gtk/Makefile.am:7:        -DG_LOG_USE_STRUCTURED=1                        \
  ...

I don't have any more direct evidence at this stage. I might press
on with this enquiry, but I admit I am way out of my depth at this
stage.

N.

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

[N. Jackson]

At 17:41 -0500 on Sunday 2017-02-26, N. Jackson wrote:

> the documentation at [1] [I don't know for what version this is
> for, or if it's even relevant], seems to say that

Sorry, I omitted the reference:

[1] https://developer.gnome.org/glib/stable/glib-Message-Logging.html

It says (amongst other things):

- "To use structured logging (rather than the old-style logging),
  either use the g_log_structured() and g_log_structured_array()
  functions; or define G_LOG_USE_STRUCTURED before including any
  GLib header..."

- "[g_log_set_handler()] has no effect if structured logging is
  enabled"

N.

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: Sun, 26 Feb 2017 19:31:03 -0500
> 
> [1] https://developer.gnome.org/glib/stable/glib-Message-Logging.html
> 
> It says (amongst other things):
> 
> - "To use structured logging (rather than the old-style logging),
>   either use the g_log_structured() and g_log_structured_array()
>   functions; or define G_LOG_USE_STRUCTURED before including any
>   GLib header..."
> 
> - "[g_log_set_handler()] has no effect if structured logging is
>   enabled"

Unless Martin will be able to resolve the issue "properly", I guess
the only way of shutting up the warning is to use
g_log_set_writer_func to temporarily set the glib log writer function
to a dummy one that does nothing, then restore the original writer
function.  That's gross, but what else can be done when you deal with
libraries which think they are smarter than you are?..

Thanks.

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

[N. Jackson]

At 18:18 +0200 on Monday 2017-02-27, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Cc: 25851@debbugs.gnu.org
>> Date: Sun, 26 Feb 2017 19:31:03 -0500
>> 
>> [1] https://developer.gnome.org/glib/stable/glib-Message-Logging.html
>> 
>> It says (amongst other things):
>> 
>> - "To use structured logging (rather than the old-style logging),
>>   either use the g_log_structured() and g_log_structured_array()
>>   functions; or define G_LOG_USE_STRUCTURED before including any
>>   GLib header..."
>> 
>> - "[g_log_set_handler()] has no effect if structured logging is
>>   enabled"
>
> Unless Martin will be able to resolve the issue "properly", I guess
> the only way of shutting up the warning is to use
> g_log_set_writer_func to temporarily set the glib log writer function
> to a dummy one that does nothing, then restore the original writer
> function.  That's gross, but what else can be done when you deal with
> libraries which think they are smarter than you are?..
>
> Thanks.

[I'm sure your question is rhetorical, but if it weren't, at one time I
would have said the what could be done is to leave the world of
paternalistic proprietary software and use Free software instead! Sadly,
the paternalistic-proprietary-software thinking has infected Free
software and we increasingly see libraries and tools that do what they
think the user should want them to do, rather than flexibly doing what the
user asks them to do.]

But that does raise the possibly naive question:

Rather that trying to cover up the warning, can we not just do what the
library wants; is it impossible for us to call "gtk_widget_show_all() on
the contents and gtk_window_set_geometry_hints() on the window" before
calling gtk_window_parse_geometry()?

N.

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, Martin Rudalics <rudalics@gmx.at>
> Date: Mon, 27 Feb 2017 13:26:43 -0500
> 
> At 18:18 +0200 on Monday 2017-02-27, Eli Zaretskii wrote:
> 
> > Unless Martin will be able to resolve the issue "properly", I guess
> > the only way of shutting up the warning is to use
> > g_log_set_writer_func to temporarily set the glib log writer function
> > to a dummy one that does nothing, then restore the original writer
> > function.  That's gross, but what else can be done when you deal with
> > libraries which think they are smarter than you are?..
> >
> > Thanks.
> 
> [I'm sure your question is rhetorical, but if it weren't, at one time I
> would have said the what could be done is to leave the world of
> paternalistic proprietary software and use Free software instead! Sadly,
> the paternalistic-proprietary-software thinking has infected Free
> software and we increasingly see libraries and tools that do what they
> think the user should want them to do, rather than flexibly doing what the
> user asks them to do.]

Hear, hear.

> Rather that trying to cover up the warning, can we not just do what the
> library wants; is it impossible for us to call "gtk_widget_show_all() on
> the contents and gtk_window_set_geometry_hints() on the window" before
> calling gtk_window_parse_geometry()?

That's what I meant with "resolve the issue properly".  Hopefully,
Martin will be able to rescue us from ourselves (and from glib's log
tyranny).

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

[martin rudalics]

 > Rather that trying to cover up the warning, can we not just do what the
 > library wants; is it impossible for us to call "gtk_widget_show_all() on
 > the contents and gtk_window_set_geometry_hints() on the window" before
 > calling gtk_window_parse_geometry()?

Did you try?  I suppose that gtk_widget_show_all would introduce some
additional flicker.

martin

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

[N. Jackson]

At 10:46 +0100 on Tuesday 2017-02-28, martin rudalics wrote:

>> Rather that trying to cover up the warning, can we not just do what the
>> library wants; is it impossible for us to call "gtk_widget_show_all() on
>> the contents and gtk_window_set_geometry_hints() on the window" before
>> calling gtk_window_parse_geometry()?
>
> Did you try?  I suppose that gtk_widget_show_all would introduce some
> additional flicker.

No, sorry, I didn't try. This is my first glimpse of any of the Emacs
window management code, and I'm not familiar with the GTK. Is there
documentation anywhere giving an overview of this area of Emacs? For
example, the "Commentary" section in frame.el is empty.

The question above was simply from a higher-level perspective. It looks
like we're not using the library in the way it is designed to be used,
so I assumed that there must be a reason why we are not. And I wondered
if that reason might not be worth reconsidering.

As for additional flicker, when I start Emacs things jump about like a
scalded cat, including a phantom random vertical scroll bar that often
makes a momentary appearance in the middle of my display. I've never
really understood why Emacs does this then other programs seem to manage
without such problems, but I've come to accept the behaviour -- after
all, it's only momentary while Emacs starts up -- and I don't think
additional flicker would necessary be much worse!

N.

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

[martin rudalics]

 > As for additional flicker, when I start Emacs things jump about like a
 > scalded cat, including a phantom random vertical scroll bar that often
 > makes a momentary appearance in the middle of my display. I've never
 > really understood why Emacs does this then other programs seem to manage
 > without such problems, but I've come to accept the behaviour -- after
 > all, it's only momentary while Emacs starts up -- and I don't think
 > additional flicker would necessary be much worse!

Could you try to investigate these flickering experiences somehow?  Do
they occur only when you restore the desktop or are there more specific
occasions when you see them?

Thanks, martin

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

[N. Jackson]

At 09:00 +0100 on Thursday 2017-03-23, martin rudalics wrote:
>
> Could you try to investigate these flickering experiences
> somehow? Do they occur only when you restore the desktop or are
> there more specific occasions when you see them?

They occur only when Emacs starts up. They don't happen with `-Q'.
On the other hand, they still occur (to a much lesser extent) with
`--no-desktop' (in this case it seems (appearance-wise -- I didn't
look a the code) that the frame is displayed before the font size
is set and then after the font size is set, the frame changes
size).

N.

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

[martin rudalics]

 > They occur only when Emacs starts up. They don't happen with `-Q'.
 > On the other hand, they still occur (to a much lesser extent) with
 > `--no-desktop' (in this case it seems (appearance-wise -- I didn't
 > look a the code) that the frame is displayed before the font size
 > is set and then after the font size is set, the frame changes
 > size).

It might be interesting to separate the issues involved here.  I recall
the font size being one major trouble in this context but a good recipe
would be valuable even if we can't do anything about it.

Meanwhile please try my patch.  If after a week or so you don't see any
troubles I intend to make it the default.

martin

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

[N. Jackson]

Hi Martin,

At 10:01 +0100 on Friday 2017-03-24, martin rudalics wrote:
>
> Meanwhile please try my patch.  If after a week or so you don't see any
> troubles I intend to make it the default.

Sorry for the delay. I haven't used master for a while and it doesn't
like my init file. I've been spending my time on troubleshooting
that. But now I have things mostly up and running.

1. I am currently running master from earlier today which includes
your patch from the 23rd (commit
fe3af8d4f2a4cd67958f76d1b708e8a78e68cd4f) which I assume is the
one you want me to test?

2. I have not applied your proposed definition of
`xg_set_geometry' from Message #122
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122). [But I
still have that in my 25.2 rc2 Emacs, which is currently my
everyday Emacs.]

3. I have put

  (setq x-gtk-use-window-move t)

in the working part of my init file [the rest of my init file --
about 10% of it -- is commented out right now].

4. In my desktop file I have three frames specified each with
a distinctive size and position.

The result is that:

- Frames are successfully restored to their former size and
position.

- No GTK warning messages are being emitted.

However:

- When I switch between frames using the window manager Alt-tab
window switching, there is a big flash almost every time when an
Emacs frame is displayed. I've never seen this problem before.
(Occasionally I've seen a single line of the display flicker while
scrolling, but I've never seen Emacs make the whole screen flash
like this before.)

[The flash is too fast to describe other than to say it is light
in colour and appears to be horizontal, almost as if there is a
white or grey highlight being applied randomly to about half the
lines in the frame and then turned off again.]

[This was after I'd maximized the three frames so that I could use
them, rather than when they were the smaller size at which they
were specified in the desktop file I tested with. I tried
restoring them down to their previous size and didn't see the
flash, then maximised them again and the flashing was back. I
suppose that the flashing might also be happening when they're
small but that my eye isn't fast enough to detect it; not sure.]

Of course this flashing might be unrelated, it might be due to a
change elsewhere in master.


The display antics at startup are slightly different but still
there. The sequence seems to be (with three frames in my desktop
file with distinctive sizes and positions):

a) A largish light-colour-scheme frame is displayed.

b) It shrinks but is still a light colour scheme. (Presumably my
default font is applied here.)

c) It changes to a dark colour scheme. (Presumably my colour
scheme is being applied here.)

d) It sits there for a bit with the various startup messages
appearing in the echo area.

e) It disappears and the three frames in my init file appear.
(Alternative explanation: It changes its size and position to that
of one of the frames in my init file, and the other two frames
from my init file are displayed.)

These antics are different from with Emacs 25 where I never see a
light-colour-scheme frame unless I start with `-Q'.

I hope this helps. Please let me know if you have further
questions for me.

N.

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: Eli Zaretskii <eliz@gnu.org>,  25851@debbugs.gnu.org
> Date: Fri, 24 Mar 2017 16:28:54 -0400
> 
> These antics are different from with Emacs 25 where I never see a
> light-colour-scheme frame unless I start with `-Q'.

Could be the result of double-buffering implemented on master.  What
was the date your previous master-derived version was built?  If that
was before January, it could be before double-buffering was pushed.
Try disabling that via initial-frame-alist in your .emacs and see if
doing that helps.

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

[N. Jackson]

At 09:26 +0300 on Saturday 2017-03-25, Eli Zaretskii wrote:

> Could be the result of double-buffering implemented on master.
> What was the date your previous master-derived version was
> built? If that was before January, it could be before
> double-buffering was pushed.  Try disabling that via
> initial-frame-alist in your .emacs and see if doing that helps.

Yes, I haven't built master for a while, almost certainly not
since January.

But no it is not obviously the double-buffering IIUC. I evaluated:

  (modify-frame-parameters nil '((inhibit-double-buffering . t)))

in each of the frames, but the flashing when switching between
them was not effected.

N.

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

[martin rudalics]

 > But no it is not obviously the double-buffering IIUC. I evaluated:
 >
 >    (modify-frame-parameters nil '((inhibit-double-buffering . t)))
 >
 > in each of the frames, but the flashing when switching between
 > them was not effected.

Earlier you said that:

   [This was after I'd maximized the three frames so that I could use
   them, rather than when they were the smaller size at which they
   were specified in the desktop file I tested with. I tried
   restoring them down to their previous size and didn't see the
   flash, then maximised them again and the flashing was back. I
   suppose that the flashing might also be happening when they're
   small but that my eye isn't fast enough to detect it; not sure.]

Is the flashing reproducible with emacs -Q, two times C-x 5 2, <M-f10>
for each frame and then Alt-tabbing between the resulting frames?  Or do
you need additional customizations?

martin

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

[martin rudalics]

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

 > Sorry for the delay. I haven't used master for a while and it doesn't
 > like my init file. I've been spending my time on troubleshooting
 > that. But now I have things mostly up and running.
 >
 > 1. I am currently running master from earlier today which includes
 > your patch from the 23rd (commit
 > fe3af8d4f2a4cd67958f76d1b708e8a78e68cd4f) which I assume is the
 > one you want me to test?

Yes.  I attach it so you can (hopefully) apply it to your Emacs 25
instead of ...

 > 2. I have not applied your proposed definition of
 > `xg_set_geometry' from Message #122
 > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122). [But I
 > still have that in my 25.2 rc2 Emacs, which is currently my
 > everyday Emacs.]

... this and test it in your everyday work.

 > 3. I have put
 >
 >    (setq x-gtk-use-window-move t)
 >
 > in the working part of my init file [the rest of my init file --
 > about 10% of it -- is commented out right now].
 >
 > 4. In my desktop file I have three frames specified each with
 > a distinctive size and position.
 >
 > The result is that:
 >
 > - Frames are successfully restored to their former size and
 > position.
 >
 > - No GTK warning messages are being emitted.

OK.

 > However:
 >
 > - When I switch between frames using the window manager Alt-tab
 > window switching, there is a big flash almost every time when an
 > Emacs frame is displayed. I've never seen this problem before.
 > (Occasionally I've seen a single line of the display flicker while
 > scrolling, but I've never seen Emacs make the whole screen flash
 > like this before.)
 >
 > [The flash is too fast to describe other than to say it is light
 > in colour and appears to be horizontal, almost as if there is a
 > white or grey highlight being applied randomly to about half the
 > lines in the frame and then turned off again.]
 >
 > [This was after I'd maximized the three frames so that I could use
 > them, rather than when they were the smaller size at which they
 > were specified in the desktop file I tested with. I tried
 > restoring them down to their previous size and didn't see the
 > flash, then maximised them again and the flashing was back. I
 > suppose that the flashing might also be happening when they're
 > small but that my eye isn't fast enough to detect it; not sure.]
 >
 > Of course this flashing might be unrelated, it might be due to a
 > change elsewhere in master.

I'm sure that Eli's suggestion is correct, so please inhibit double
buffering in your init file.

 > The display antics at startup are slightly different but still
 > there. The sequence seems to be (with three frames in my desktop
 > file with distinctive sizes and positions):
 >
 > a) A largish light-colour-scheme frame is displayed.
 >
 > b) It shrinks but is still a light colour scheme. (Presumably my
 > default font is applied here.)
 >
 > c) It changes to a dark colour scheme. (Presumably my colour
 > scheme is being applied here.)

I don't know what a colour scheme is.  Please send me yours and I'll try
adding it to my .emacs to see which behavior it causes.

BTW I never thought about possible mergings of `initial-frame-alist' or
`default-frame-alist' and the parameter alists applied by desktop.

 > d) It sits there for a bit with the various startup messages
 > appearing in the echo area.
 >
 > e) It disappears and the three frames in my init file appear.
 > (Alternative explanation: It changes its size and position to that
 > of one of the frames in my init file, and the other two frames
 > from my init file are displayed.)

I suppose you mean "desktop" instead of "init" file here?

 > These antics are different from with Emacs 25 where I never see a
 > light-colour-scheme frame unless I start with `-Q'.

To get one aspect right: Do you see the light-colour-scheme frame also
when you don't restore the desktop - with one or three initial frames?
(And what else does master dislike about your init file?)

martin

[-- Attachment #2: gtk_window_move.diff --]
[-- Type: text/plain, Size: 4724 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 3a00e36..63f0143 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -783,33 +783,55 @@ struct xg_frame_tb_info
 {
   if (f->size_hint_flags & (USPosition | PPosition))
     {
-      int left = f->left_pos;
-      int xneg = f->size_hint_flags & XNegative;
-      int top = f->top_pos;
-      int yneg = f->size_hint_flags & YNegative;
-      char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
-      guint id;
-
-      if (xneg)
-        left = -left;
-      if (yneg)
-        top = -top;
-
-      sprintf (geom_str, "=%dx%d%c%d%c%d",
-               FRAME_PIXEL_WIDTH (f),
-               FRAME_PIXEL_HEIGHT (f),
-               (xneg ? '-' : '+'), left,
-               (yneg ? '-' : '+'), top);
-
-      /* 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);
-
-      if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-                                      geom_str))
-        fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
-
-      g_log_remove_handler ("Gtk", id);
+      if (x_gtk_use_window_move)
+	{
+	  /* Handle negative positions without consulting
+	     gtk_window_parse_geometry (Bug#25851).  The position will
+	     be off by scrollbar width + window manager decorations.  */
+	  if (f->size_hint_flags & XNegative)
+	    f->left_pos = (x_display_pixel_width (FRAME_DISPLAY_INFO (f))
+			   - FRAME_PIXEL_WIDTH (f) + f->left_pos);
+
+	  if (f->size_hint_flags & YNegative)
+	    f->top_pos = (x_display_pixel_height (FRAME_DISPLAY_INFO (f))
+			  - FRAME_PIXEL_HEIGHT (f) + f->top_pos);
+
+	  gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   f->left_pos, f->top_pos);
+
+	  /* Reset size hint flags.  */
+	  f->size_hint_flags &= ~ (XNegative | YNegative);
+	}
+      else
+	{
+	  int left = f->left_pos;
+	  int xneg = f->size_hint_flags & XNegative;
+	  int top = f->top_pos;
+	  int yneg = f->size_hint_flags & YNegative;
+	  char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
+	  guint id;
+
+	  if (xneg)
+	    left = -left;
+	  if (yneg)
+	    top = -top;
+
+	  sprintf (geom_str, "=%dx%d%c%d%c%d",
+		   FRAME_PIXEL_WIDTH (f),
+		   FRAME_PIXEL_HEIGHT (f),
+		   (xneg ? '-' : '+'), left,
+		   (yneg ? '-' : '+'), top);
+
+	  /* 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);
+
+	  if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+					  geom_str))
+	    fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
+
+	  g_log_remove_handler ("Gtk", id);
+	}
     }
 }
 
@@ -1406,6 +1428,13 @@ struct xg_frame_tb_info
   else if (win_gravity == StaticGravity)
     size_hints.win_gravity = GDK_GRAVITY_STATIC;
 
+  if (x_gtk_use_window_move)
+    {
+      if (flags & PPosition) hint_flags |= GDK_HINT_POS;
+      if (flags & USPosition) hint_flags |= GDK_HINT_USER_POS;
+      if (flags & USSize) hint_flags |= GDK_HINT_USER_SIZE;
+    }
+
   if (user_position)
     {
       hint_flags &= ~GDK_HINT_POS;
diff --git a/src/xterm.c b/src/xterm.c
index 7856793..4f9eff6 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10056,11 +10056,26 @@ struct x_error_message_stack {
 	f->size_hint_flags |= YNegative;
       f->win_gravity = NorthWestGravity;
     }
+
   x_calc_absolute_position (f);
 
   block_input ();
   x_wm_set_size_hint (f, 0, false);
 
+#ifdef USE_GTK
+  if (x_gtk_use_window_move)
+    {
+      /* When a position change was requested and the outer GTK widget
+	 has been realized already, leave it to gtk_window_move to DTRT
+	 and return.  Used for Bug#25851 and Bug#25943.  */
+      if (change_gravity != 0 && FRAME_GTK_OUTER_WIDGET (f))
+	gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 f->left_pos, f->top_pos);
+      unblock_input ();
+      return;
+    }
+#endif /* USE_GTK */
+
   modified_left = f->left_pos;
   modified_top = f->top_pos;
 
@@ -12905,4 +12920,11 @@ click on a frame to select it (give it focus).  In that case, a value
 Set this variable only if your window manager cannot handle the
 transition between the various maximization states.  */);
   x_frame_normalize_before_maximize = false;
+
+  DEFVAR_BOOL ("x-gtk-use-window-move", x_gtk_use_window_move,
+    doc: /* Non-nil means rely on gtk_window_move to set frame positions.
+If this variable is t, the GTK build uses the function gtk_window_move
+to set or store frame positions and disables some time consuming frame
+position adjustments.  */);
+  x_gtk_use_window_move = false;
 }

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

[N. Jackson]

At 16:28 -0400 on Friday 2017-03-24, N. Jackson wrote:

> - When I switch between frames using the window manager Alt-tab
> window switching, there is a big flash almost every time when an
> Emacs frame is displayed. I've never seen this problem before.

It seems that this side problem of the flashing might not have
been directly related to Emacs.

There has been a lot of churn on my system with what feels like
very frequent kernel updates, as well as updates to the window
manager and to Xorg. The flashing problem started, and soon after
stopped, during this period.

Sorry for the noise.

N.

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

[martin rudalics]

 > Meanwhile please try my patch.  If after a week or so you don't see any
 > troubles I intend to make it the default.

It's now the default.

martin

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

[N. Jackson]

At 08:49 +0200 on Tuesday 2017-04-11, martin rudalics wrote:

>> Meanwhile please try my patch. If after a week or so you don't
>> see any troubles I intend to make it the default.
>
> It's now the default.
>
> martin

Sorry, Martin, I got sidetracked.

If your patch is in master but not the emacs-25 branch, then it
seems to work -- see my previous message to this bug thread.

Also I had no problems, over the past month or two, using your fix
to the definition of `xg_set_geometry' from Message #122
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122) which
also fixed the bug successfully in Emacs 25.2rc2.

Is there any possibility of your patch being cherry-picked to
emacs-25? Or is the plan to go to Emacs 26 next, rather Emacs
25.3?

Thanks.

N.

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

[martin rudalics]

 > Also I had no problems, over the past month or two, using your fix
 > to the definition of `xg_set_geometry' from Message #122
 > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122) which
 > also fixed the bug successfully in Emacs 25.2rc2.
 >
 > Is there any possibility of your patch being cherry-picked to
 > emacs-25? Or is the plan to go to Emacs 26 next, rather Emacs
 > 25.3?

 > Is there any possibility of your patch being cherry-picked to
 > emacs-25? Or is the plan to go to Emacs 26 next, rather Emacs
 > 25.3?

Currently there are no plans for Emacs 25.3.  But doesn't your Emacs 25
already contain the patch?  The only difference I made lately was to set
the default value of ‘x-gtk-use-window-move’ so all you have to do is to
make the last line of your xterm.c read

x_gtk_use_window_move = true;

martin

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

[N. Jackson]

Hi Martin,

At 12:30 +0200 on Saturday 2017-04-29, martin rudalics wrote:

> But doesn't your Emacs 25 already contain the patch?

No. Not if I understand correctly.

_My_ Emacs 25.2.rc2 is modified so that the entire body of
xg_set_geometry() is deleted and replaced by a call to
gtk_window_move(). This fixes the bug and did not produce any
adverse effects in six weeks of use (on my system at least).

My Emacs 25.2 is the stock release from the tarball. I don't know
if it contains any patch for this bug, but if it does that patch
does not appear to work.

> The only difference I made lately was to set the default value
> of ‘x-gtk-use-window-move’ so all you have to do is to make the
> last line of your xterm.c read
>
> x_gtk_use_window_move = true;

The symbol `x_gtk_use_window_move' is not defined in the emacs-25
branch, only in master.

Thanks.

N.

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

[martin rudalics]

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

 >> But doesn't your Emacs 25 already contain the patch?
 >
 > No. Not if I understand correctly.
 >
 > _My_ Emacs 25.2.rc2 is modified so that the entire body of
 > xg_set_geometry() is deleted and replaced by a call to
 > gtk_window_move(). This fixes the bug and did not produce any
 > adverse effects in six weeks of use (on my system at least).
 >
 > My Emacs 25.2 is the stock release from the tarball. I don't know
 > if it contains any patch for this bug, but if it does that patch
 > does not appear to work.
 >
 >> The only difference I made lately was to set the default value
 >> of ‘x-gtk-use-window-move’ so all you have to do is to make the
 >> last line of your xterm.c read
 >>
 >> x_gtk_use_window_move = true;
 >
 > The symbol `x_gtk_use_window_move' is not defined in the emacs-25
 > branch, only in master.

Sorry.  I forgot to tell you to apply that change to your Emacs 25 back
then.  Please remove any changes I proposed earlier and try to apply the
attached x_gtk_use_window_move.diff to your Emacs 25.

Thanks, martin

[-- Attachment #2: x_gtk_use_window_move.diff --]
[-- Type: text/plain, Size: 4691 bytes --]

--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -783,33 +783,55 @@ xg_set_geometry (struct frame *f)
 {
   if (f->size_hint_flags & (USPosition | PPosition))
     {
-      int left = f->left_pos;
-      int xneg = f->size_hint_flags & XNegative;
-      int top = f->top_pos;
-      int yneg = f->size_hint_flags & YNegative;
-      char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
-      guint id;
-
-      if (xneg)
-        left = -left;
-      if (yneg)
-        top = -top;
-
-      sprintf (geom_str, "=%dx%d%c%d%c%d",
-               FRAME_PIXEL_WIDTH (f),
-               FRAME_PIXEL_HEIGHT (f),
-               (xneg ? '-' : '+'), left,
-               (yneg ? '-' : '+'), top);
-
-      /* 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);
-
-      if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-                                      geom_str))
-        fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
-
-      g_log_remove_handler ("Gtk", id);
+      if (x_gtk_use_window_move)
+	{
+	  /* Handle negative positions without consulting
+	     gtk_window_parse_geometry (Bug#25851).  The position will
+	     be off by scrollbar width + window manager decorations.  */
+	  if (f->size_hint_flags & XNegative)
+	    f->left_pos = (x_display_pixel_width (FRAME_DISPLAY_INFO (f))
+			   - FRAME_PIXEL_WIDTH (f) + f->left_pos);
+
+	  if (f->size_hint_flags & YNegative)
+	    f->top_pos = (x_display_pixel_height (FRAME_DISPLAY_INFO (f))
+			  - FRAME_PIXEL_HEIGHT (f) + f->top_pos);
+
+	  gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   f->left_pos, f->top_pos);
+
+	  /* Reset size hint flags.  */
+	  f->size_hint_flags &= ~ (XNegative | YNegative);
+	}
+      else
+	{
+	  int left = f->left_pos;
+	  int xneg = f->size_hint_flags & XNegative;
+	  int top = f->top_pos;
+	  int yneg = f->size_hint_flags & YNegative;
+	  char geom_str[sizeof "=x--" + 4 * INT_STRLEN_BOUND (int)];
+	  guint id;
+
+	  if (xneg)
+	    left = -left;
+	  if (yneg)
+	    top = -top;
+
+	  sprintf (geom_str, "=%dx%d%c%d%c%d",
+		   FRAME_PIXEL_WIDTH (f),
+		   FRAME_PIXEL_HEIGHT (f),
+		   (xneg ? '-' : '+'), left,
+		   (yneg ? '-' : '+'), top);
+
+	  /* 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);
+
+	  if (!gtk_window_parse_geometry (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+					  geom_str))
+	    fprintf (stderr, "Failed to parse: '%s'\n", geom_str);
+
+	  g_log_remove_handler ("Gtk", id);
+	}
     }
 }

@@ -1406,6 +1428,13 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
   else if (win_gravity == StaticGravity)
     size_hints.win_gravity = GDK_GRAVITY_STATIC;

+  if (x_gtk_use_window_move)
+    {
+      if (flags & PPosition) hint_flags |= GDK_HINT_POS;
+      if (flags & USPosition) hint_flags |= GDK_HINT_USER_POS;
+      if (flags & USSize) hint_flags |= GDK_HINT_USER_SIZE;
+    }
+
   if (user_position)
     {
       hint_flags &= ~GDK_HINT_POS;
diff --git a/src/xterm.c b/src/xterm.c
index 7856793..4f9eff6 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10056,11 +10056,26 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_
 	f->size_hint_flags |= YNegative;
       f->win_gravity = NorthWestGravity;
     }
+
   x_calc_absolute_position (f);

   block_input ();
   x_wm_set_size_hint (f, 0, false);

+#ifdef USE_GTK
+  if (x_gtk_use_window_move)
+    {
+      /* When a position change was requested and the outer GTK widget
+	 has been realized already, leave it to gtk_window_move to DTRT
+	 and return.  Used for Bug#25851 and Bug#25943.  */
+      if (change_gravity != 0 && FRAME_GTK_OUTER_WIDGET (f))
+	gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 f->left_pos, f->top_pos);
+      unblock_input ();
+      return;
+    }
+#endif /* USE_GTK */
+
   modified_left = f->left_pos;
   modified_top = f->top_pos;

@@ -12905,4 +12920,11 @@ state.
 Set this variable only if your window manager cannot handle the
 transition between the various maximization states.  */);
   x_frame_normalize_before_maximize = false;
+
+  DEFVAR_BOOL ("x-gtk-use-window-move", x_gtk_use_window_move,
+    doc: /* Non-nil means rely on gtk_window_move to set frame positions.
+If this variable is t, the GTK build uses the function gtk_window_move
+to set or store frame positions and disables some time consuming frame
+position adjustments.  */);
+  x_gtk_use_window_move = true;
 }

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

[N. Jackson]

At 10:32 +0200 on Sunday 2017-04-30, martin rudalics wrote:
>
> Please remove any changes I proposed earlier and try to apply the
> attached x_gtk_use_window_move.diff to your Emacs 25.

Thanks Martin,

I have just applied your x_gtk_use_window_move.diff patch to Emacs
25. That fixes the bug.

Can the patch be applied to the emacs-25 branch in case there is
ever an Emacs 25.3?

Thanks.

N.

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

[martin rudalics]

 > Can the patch be applied to the emacs-25 branch in case there is
 > ever an Emacs 25.3?

If and when there is let's discuss this with Eli.

martin

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

[martin rudalics]

 > Unless Martin will be able to resolve the issue "properly",

I still fail to understand what Jan had in mind when he eliminated the
gtk_window_move call from xg_set_geometry with PPosition set.  We could
try to revert that change and see what happens.

 > I guess
 > the only way of shutting up the warning is to use
 > g_log_set_writer_func to temporarily set the glib log writer function
 > to a dummy one that does nothing, then restore the original writer
 > function.  That's gross, but what else can be done when you deal with
 > libraries which think they are smarter than you are?..

IIUC most of what GTK's gometry parsing does is trying to avoid that a
frame appears offscreen.  So it's not really about being smart.  Emacs
is asking for it.

martin

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

[Eli Zaretskii]

> Date: Tue, 28 Feb 2017 10:46:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 25851@debbugs.gnu.org
> 
>  > Unless Martin will be able to resolve the issue "properly",
> 
> I still fail to understand what Jan had in mind when he eliminated the
> gtk_window_move call from xg_set_geometry with PPosition set.  We could
> try to revert that change and see what happens.

If no better idea comes up, I think we should indeed do that.

>  > I guess
>  > the only way of shutting up the warning is to use
>  > g_log_set_writer_func to temporarily set the glib log writer function
>  > to a dummy one that does nothing, then restore the original writer
>  > function.  That's gross, but what else can be done when you deal with
>  > libraries which think they are smarter than you are?..
> 
> IIUC most of what GTK's gometry parsing does is trying to avoid that a
> frame appears offscreen.  So it's not really about being smart.  Emacs
> is asking for it.

Sorry, I'm not following: what is Emacs asking for?

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

[martin rudalics]

 > Sorry, I'm not following: what is Emacs asking for?

Troubles.  IIUC we do all this trickery to make a new frame with the
left or top edge off-screen.  This does make sense to me and does not
work here anyway.

martin

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

[Eli Zaretskii]

> Date: Tue, 28 Feb 2017 19:42:41 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
> IIUC we do all this trickery to make a new frame with the left or
> top edge off-screen.

Do we understand the purpose of this?

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

[martin rudalics]

 >> IIUC we do all this trickery to make a new frame with the left or
 >> top edge off-screen.
 >
 > Do we understand the purpose of this?

The purpose of what?  If you asked why people want to show a frame with
the top or left edge off-screen, then the major goup of clients might be
those who want to move the titlebar out of view.

Nothing against the use of (make-frame '((left . (+ -100)))) as long as
it's done within .emacs.  It's a pain, however, when such idioms get
distributed in packages because then their authors will redirect users
to this list whenever a window manager refuses to comply.

martin

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

[Eli Zaretskii]

> Date: Wed, 01 Mar 2017 09:29:31 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
>  >> IIUC we do all this trickery to make a new frame with the left or
>  >> top edge off-screen.
>  >
>  > Do we understand the purpose of this?
> 
> The purpose of what?  If you asked why people want to show a frame with
> the top or left edge off-screen, then the major goup of clients might be
> those who want to move the titlebar out of view.

Yes, that's what I asked.

If that's the reason, and we think doing that is legitimate, is there
any other solution but to shut up the warning?

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

[martin rudalics]

 > If that's the reason, and we think doing that is legitimate, is there
 > any other solution but to shut up the warning?

I think that warning is legitimate.  And even if I thought that what we
are doing is legitimate - xfwm would still refuse to put the top-left
corner of my new frame off-screen.

martin

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

[Eli Zaretskii]

> Date: Wed, 01 Mar 2017 20:36:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
>  > If that's the reason, and we think doing that is legitimate, is there
>  > any other solution but to shut up the warning?
> 
> I think that warning is legitimate.

It's legitimate, but what we do as legitimate as well, right?  And
emitting a warning in such use cases will only annoy users, right?

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

[Eli Zaretskii]

> Date: Wed, 01 Mar 2017 21:47:08 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
> It's legitimate, but what we do as legitimate as well, right?
                                  ^^
"is"

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

[martin rudalics]

 > It's legitimate, but what we do as legitimate as well, right?  And
 > emitting a warning in such use cases will only annoy users, right?

The doc-string of gtk_window_parse_geometry says

  * Note that for gtk_window_parse_geometry() to work as expected, it has
  * to be called when the window has its “final” size, i.e. after calling
  * gtk_widget_show_all() on the contents and gtk_window_set_geometry_hints()
  * on the window.

and also

  * Deprecated: 3.20: Geometry handling in GTK is deprecated.

If this were our doc-string, would you say that calling that function as
we do now is legitimate?

IIUC we call gtk_window_parse_geometry here because we cannot call
gtk_window_set_geometry_hints at this early stage because of

   /* Don't set size hints during initialization; that apparently leads
      to a race condition.  See the thread at
      http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00033.html  */
   if (NILP (Vafter_init_time)
       || !FRAME_GTK_OUTER_WIDGET (f)
       || FRAME_PARENT_FRAME (f))
     return;

Aren't we desperately trying to shoot ourselves in the foot?  If we
can't set hints realiably during initialization, we shouldn't try doing
it through some backdoor.

martin

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

[Eli Zaretskii]

> Date: Thu, 02 Mar 2017 12:00:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
>  > It's legitimate, but what we do as legitimate as well, right?  And
>  > emitting a warning in such use cases will only annoy users, right?
> 
> The doc-string of gtk_window_parse_geometry says
> 
>   * Note that for gtk_window_parse_geometry() to work as expected, it has
>   * to be called when the window has its “final” size, i.e. after calling
>   * gtk_widget_show_all() on the contents and gtk_window_set_geometry_hints()
>   * on the window.
> 
> and also
> 
>   * Deprecated: 3.20: Geometry handling in GTK is deprecated.
> 
> If this were our doc-string, would you say that calling that function as
> we do now is legitimate?
> 
> IIUC we call gtk_window_parse_geometry here because we cannot call
> gtk_window_set_geometry_hints at this early stage because of
> 
>    /* Don't set size hints during initialization; that apparently leads
>       to a race condition.  See the thread at
>       http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00033.html  */
>    if (NILP (Vafter_init_time)
>        || !FRAME_GTK_OUTER_WIDGET (f)
>        || FRAME_PARENT_FRAME (f))
>      return;
> 
> Aren't we desperately trying to shoot ourselves in the foot?

I'm sorry, I'm confused.  Earlier you explained that we do that
because users want the ability of placing frames outside of the
visible area, so I concluded that the fact we allow that is because we
want to cater to such users.  Now you seem to be saying that we
shouldn't cater to them?  How to reconcile these two?  Or am I missing
something?

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

[martin rudalics]

 > I'm sorry, I'm confused.  Earlier you explained that we do that
 > because users want the ability of placing frames outside of the
 > visible area, so I concluded that the fact we allow that is because we
 > want to cater to such users.  Now you seem to be saying that we
 > shouldn't cater to them?  How to reconcile these two?  Or am I missing
 > something?

It's not that we "shouldn't".  IMO we "can't" (contrary to Windows).
Maybe before

commit 3e5fc571bd5a9bdbed786b43a7971c41f87c6ad8
Author: Chong Yidong <cyd@stupidchicken.com>
Date:   Mon Oct 6 16:17:14 2008 +0000

     (x_wm_set_size_hint): Return immediately if called during
     initialization.

we were able to do so but I have no proof.  If someone has a GTK build
older than that, please try whether something like

(make-frame
  '((user-position . t)
    (left . (+ -100))
    (top . (+ -100))))

worked.  Nowadays it can't IMO because gtk_window_parse_geometry has

   /* we don't let you put a window offscreen; maybe some people would
    * prefer to be able to, but it's kind of a bogus thing to do.
    */
   if (y < 0)
     y = 0;

   if (x < 0)
     x = 0;

Obviously, the window manager might also insist on putting the frame
on-screen (it does so here).  But while I cannot put a GTK
override-redirect window off-screen initially, I can easily do that for
a Lucid override-redirect window.

Also

(let ((frame (make-frame)))
   (set-frame-parameter frame 'left '(+ -100))
   (set-frame-parameter frame 'top '(+ -100)))

works as intended here.  But that's of little use when parsing default
geometry specifications.  Well, we could synthesize that ...

So maybe we should do away with the gtk_window_parse_geometry call, wait
for people to holler and try to fix problems with gtk_window_move calls
followed by something like x_wm_set_size_hint (f, 0, true) if needed.

But I'm not overly optimistic and would like to hear the opinion of at
least one person with GTK skills first.  Maybe everything I said here is
just silly.

martin

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

[Eli Zaretskii]

> Date: Thu, 02 Mar 2017 18:57:30 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
> So maybe we should do away with the gtk_window_parse_geometry call, wait
> for people to holler and try to fix problems with gtk_window_move calls
> followed by something like x_wm_set_size_hint (f, 0, true) if needed.

Alternatively, make the current code which allows putting windows
off-screen be conditioned by a user option, by default off.  Then
those who want that will have to deal with the GTK warnings.

> But I'm not overly optimistic and would like to hear the opinion of at
> least one person with GTK skills first.

Me too.

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

[martin rudalics]

 > Alternatively, make the current code which allows putting windows
 > off-screen be conditioned by a user option, by default off.  Then
 > those who want that will have to deal with the GTK warnings.

‘x-gtk-parse-geometry’?

martin

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

[Eli Zaretskii]

> Date: Fri, 03 Mar 2017 09:13:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: nljlistbox2@gmail.com, 25851@debbugs.gnu.org
> 
>  > Alternatively, make the current code which allows putting windows
>  > off-screen be conditioned by a user option, by default off.  Then
>  > those who want that will have to deal with the GTK warnings.
> 
> ‘x-gtk-parse-geometry’?

Probably.

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

[N. Jackson]

At 20:36 +0100 on Wednesday 2017-03-01, martin rudalics wrote:

>> If that's the reason, and we think doing that is legitimate, is
>> there any other solution but to shut up the warning?
>
> I think that warning is legitimate. And even if I thought that
> what we are doing is legitimate - xfwm would still refuse to put
> the top-left corner of my new frame off-screen.

I'm not quite following this discussion. [Of course, it isn't
important that I follow it; however if you have time to elucidate,
I would much appreciate it.]

If we removed the arguably illegitimate chicanery, what
functionality, specifically, would be lost? Might it be achieved
in a more straightforward way?

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

[martin rudalics]

 > If we removed the arguably illegitimate chicanery, what
 > functionality, specifically, would be lost? Might it be achieved
 > in a more straightforward way?

That's a good summary of the problem.  Try to use the following
definition of xg_set_geometry:

static void
xg_set_geometry (struct frame *f)
{
   gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
		   f->left_pos, f->top_pos);
}

I suppose it might break things like starting with a specified geometry
and a maximized frame and trying to demaximize the frame afterwards.  It
might as well work.

The greatest problem in this area is always to find a solution that fits
(almost) all window managers and user preferences.

martin

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

[N. Jackson]

At 09:13 +0100 on Friday 2017-03-03, martin rudalics wrote:

> Try to use the following definition of xg_set_geometry:
>
> static void
> xg_set_geometry (struct frame *f)
> {
>   gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
> 		   f->left_pos, f->top_pos);
> }

I have replaced the xg_set_geometry() in my Emacs with the one
above.

So far so good. (I haven't noticed any difference. (Aside from the
welcome elimination of the GTK warning message.)

> I suppose it might break things like starting with a specified
> geometry and a maximized frame and trying to demaximize the
> frame afterwards. It might as well work.

I've tried closing and restarting Emacs with various frame /
window configurations (including "full screen" frames with the
title bar hidden), and the desktops restore just fine [1]. And
restoring / maximizing frames using the window decorations works
fine too.

[1] As has been happening for a while, buffers seem to be assigned
randomly (it seems) to the windows restored from the desktop file;
I'm still convinced that in the past on starting Emacs the windows
restored from the desktop file used to come up with the same
buffer in them as they had when the desktop file was saved.

N.

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

[martin rudalics]

 > I've tried closing and restarting Emacs with various frame /
 > window configurations (including "full screen" frames with the
 > title bar hidden), and the desktops restore just fine [1]. And
 > restoring / maximizing frames using the window decorations works
 > fine too.

Same here.  One thing that doesn't work are negative offsets like in
emacs -Q -g 80x40-20-20.  That's easy to fix elsewhere.  If you don't
mind, continue using it for a while; maybe you detect something strange.

 > [1] As has been happening for a while, buffers seem to be assigned
 > randomly (it seems) to the windows restored from the desktop file;
 > I'm still convinced that in the past on starting Emacs the windows
 > restored from the desktop file used to come up with the same
 > buffer in them as they had when the desktop file was saved.

It would be nice if you were able to bisect that "while".  The idea is
obviously that windows come up with their original buffers restored.

martin

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

[N. Jackson]

Hello Martin,

At 15:24 +0100 on Friday 2017-03-03, martin rudalics wrote:

> One thing that doesn't work are negative offsets like in emacs
> -Q -g 80x40-20-20.

Here I can successfully position frames partially off the display
(using the mouse) but when they are restored from a desktop file,
they are moved slightly so that are fully on the display. (Perhaps
this is what you mean?) I don't see that this is necessarily bad
behaviour. (Others might (probably will!) disagree of course...)

> If you don't mind, continue using it for a while; maybe you
> detect something strange.

Yes, I am using (and I will continue to use) your proposed
definition of `xg_set_geometry' from Message #122
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25851#122).

I will keep my eye out for any oddities. So far, so good.
(Although, I should note that my usage of frames is very
tame/conservative; I tend to keep the same configuration of three
(sometimes four) full screen frames at all times.)

>> [1] As has been happening for a while, buffers seem to be
>> assigned randomly (it seems) to the windows restored from the
>> desktop file
>
> It would be nice if you were able to bisect that "while". The
> idea is obviously that windows come up with their original
> buffers restored.

I considered reporting this bug a few months ago, but I couldn't
make enough sense of the behaviour I was seeing to write a
coherent report.

I tried again today, and I can no longer reproduce the problem!
Yet I saw it as recently as last week while I was preparing the
bug report for the current bug (bug#25851). Perhaps deleting old
desktop files has made the problem go away? I don't know.

But yes, if I start seeing the problem again, and if I have a
desktop file that I can use for testing, I will try to bisect
revisions to see when the behaviour was introduced.

Regards,
N.

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

[martin rudalics]

 >> One thing that doesn't work are negative offsets like in emacs
 >> -Q -g 80x40-20-20.
 >
 > Here I can successfully position frames partially off the display
 > (using the mouse) but when they are restored from a desktop file,
 > they are moved slightly so that are fully on the display. (Perhaps
 > this is what you mean?) I don't see that this is necessarily bad
 > behaviour. (Others might (probably will!) disagree of course...)

The -20-20 are supposed to put the frame's right and lower edge at a
distance of 20 pixels from the right and bottom edge of the display.
This doesn't work any more because the corresponding calculations in
xg_set_geometry are not done any more.  I moved them to x_set_offset
here.

martin

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

[martin rudalics]

The only way to investigate this is by examining the parameters passed
by ‘frameset--restore-frame’ to ‘make-frame-on-display’.  One of these
parameters causes the problem at hand.

martin

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

[N. Jackson]

At 09:21 +0100 on Saturday 2017-02-25, Martin Rudalics wrote:
>
> The only way to investigate this is by examining the parameters
> passed by ‘frameset--restore-frame’ to ‘make-frame-on-display’.
> One of these parameters causes the problem at hand.

Hi Martin,

Is there anything in particular you'd like me to report, or do you
want to see everything passed to `make-frame-on-display' by
`frameset--restore-frame'?

Thanks,
N.

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

[N. Jackson]

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

At 17:47 -0500 on Sunday 2017-02-26, N. Jackson wrote:

> At 09:21 +0100 on Saturday 2017-02-25, Martin Rudalics wrote:
>>
>> The only way to investigate this is by examining the parameters
>> passed by ‘frameset--restore-frame’ to ‘make-frame-on-display’.
>> One of these parameters causes the problem at hand.
>
> Hi Martin,
>
> Is there anything in particular you'd like me to report, or do
> you want to see everything passed to `make-frame-on-display' by
> `frameset--restore-frame'?

Hi Martin,

I might have the information you were asking for. (Please let me
know if this is not the necessary information, or if you need more
details.)

With a desktop file specifying three frames, there seem to be two
calls to `make-frame-on-display' (when the second and third frames
are created). Each call ultimately results in one of the reported
GTK warning messages.

Detailed backtraces at these two calls to `make-frame-on-display'
are attached.


[-- Attachment #2: Detailed backtrace prior to first GTK warning --]
[-- Type: text/plain, Size: 9137 bytes --]

Debugger entered: nil
  make-frame-on-display(":0" ((visibility) (left . 0) (top . 0) (border-width . 0) (minibuffer . t)))
  frameset--restore-frame(((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "8B00-9439-83D1-B48B") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) (((min-height . 4) (min-width . 21) (min-height-ignore . 2) (min-width-ignore . 21) (min-height-safe . 1) (min-width-safe . 4) (min-pixel-height . 52) (min-pixel-width . 147) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 147) (min-pixel-height-safe . 13) (min-pixel-width-safe . 28)) hc (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 686) (pixel-height . 755) (total-width . 98) (total-height . 58) (normal-height . 1.0) (normal-width . 0.5034246575342466) (buffer "gtkutil.c" (selected . t) (hscroll . 0) (fringes 8 0 nil) (margins 4) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 25202) (start . 23482))) (leaf (last . t) (pixel-width . 680) (pixel-height . 755) (total-width . 97) (total-height . 58) (normal-height . 1.0) (normal-width . 0.4965753424657534) (buffer "gtkwindow.c" (selected) (hscroll . 0) (fringes 8 0 nil) (margins 5) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 346800) (start . 346686)))) ((background-color . frameset-filter-sanitize-color) (buffer-list . :never) (buffer-predicate . :never) (buried-buffer-list . :never) (font . frameset-filter-shelve-param) (foreground-color . frameset-filter-sanitize-color) (fullscreen . frameset-filter-shelve-param) (GUI:font . frameset-filter-unshelve-param) (GUI:fullscreen . frameset-filter-unshelve-param) (GUI:height . frameset-filter-unshelve-param) (GUI:width . frameset-filter-unshelve-param) (height . frameset-filter-shelve-param) (outer-window-id . :never) (parent-id . :never) (tty . frameset-filter-tty-to-GUI) (tty-type . frameset-filter-tty-to-GUI) (width . frameset-filter-shelve-param) (window-id . :never) (window-system . :never) (name . :never) (left . frameset-filter-iconified) (minibuffer . frameset-filter-minibuffer) (top . frameset-filter-iconified)) t)
  frameset-restore([frameset 1 (22707 34328 391371 390000) (desktop . "208") "nlj@moondust.localdomain" nil nil ((((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "8B00-9439-83D1-B48B") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) ((min-height . 4) (min-width . 21) (min-height-ignore . 2) (min-width-ignore . 21) (min-height-safe . 1) (min-width-safe . 4) (min-pixel-height . 52) (min-pixel-width . 147) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 147) (min-pixel-height-safe . 13) (min-pixel-width-safe . 28)) hc (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 686) (pixel-height . 755) (total-width . 98) (total-height . 58) (normal-height . 1.0) (normal-width . 0.5034246575342466) (buffer "gtkutil.c" (selected . t) (hscroll . 0) (fringes 8 0 nil) (margins 4) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 25202) (start . 23482))) (leaf (last . t) (pixel-width . 680) (pixel-height . 755) (total-width . 97) (total-height . 58) (normal-height . 1.0) (normal-width . 0.4965753424657534) (buffer "gtkwindow.c" (selected) (hscroll . 0) (fringes 8 0 nil) (margins 5) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 346800) (start . 346686)))) (((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "2A59-81FB-8BFF-3685") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 52) (min-pixel-width . 70) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 42) (min-pixel-height-safe . 13) (min-pixel-width-safe . 14)) leaf (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (buffer "*Messages*" (selected) (hscroll . 0) (fringes 8 0 nil) (margins nil) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 5) (start . 1))) (((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (sticky) (environment) (frameset--id . "DC57-2577-7FAB-434C") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (visibility . t) (height . 59) (width . 191) (left . 0) ...) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 52) (min-pixel-width . 70) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 42) (min-pixel-height-safe . 13) (min-pixel-width-safe . 14)) leaf (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (buffer "*eww*" (selected) (hscroll . 0) (fringes 8 0 nil) (margins nil) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 1) (start . 1))))] :reuse-frames t :cleanup-frames t :force-display t :force-onscreen t)
  desktop-restore-frameset()
  desktop-read()
  #[0 "\303\211\b\235\203\x10\0\304\x01\b\"\x10\301\305!\210\210	\205^[\0\306 \210\307\211\x12\207" [command-line-args desktop-save-mode inhibit-startup-screen "--no-desktop" delete 0 desktop-read t] 4]()
  run-hooks(after-init-hook delayed-warnings-hook)
  command-line()
  normal-top-level()

[-- Attachment #3: Detailed backtrace prior to second GTK warning --]
[-- Type: text/plain, Size: 8638 bytes --]

Debugger entered: nil
  make-frame-on-display(":0" ((visibility) (left . 0) (top . 0) (border-width . 0) (minibuffer . t)))
  frameset--restore-frame(((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "2A59-81FB-8BFF-3685") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) (((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 52) (min-pixel-width . 70) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 42) (min-pixel-height-safe . 13) (min-pixel-width-safe . 14)) leaf (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (buffer "*Messages*" (selected) (hscroll . 0) (fringes 8 0 nil) (margins nil) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 5) (start . 1))) ((background-color . frameset-filter-sanitize-color) (buffer-list . :never) (buffer-predicate . :never) (buried-buffer-list . :never) (font . frameset-filter-shelve-param) (foreground-color . frameset-filter-sanitize-color) (fullscreen . frameset-filter-shelve-param) (GUI:font . frameset-filter-unshelve-param) (GUI:fullscreen . frameset-filter-unshelve-param) (GUI:height . frameset-filter-unshelve-param) (GUI:width . frameset-filter-unshelve-param) (height . frameset-filter-shelve-param) (outer-window-id . :never) (parent-id . :never) (tty . frameset-filter-tty-to-GUI) (tty-type . frameset-filter-tty-to-GUI) (width . frameset-filter-shelve-param) (window-id . :never) (window-system . :never) (name . :never) (left . frameset-filter-iconified) (minibuffer . frameset-filter-minibuffer) (top . frameset-filter-iconified)) t)
  frameset-restore([frameset 1 (22707 34328 391371 390000) (desktop . "208") "nlj@moondust.localdomain" nil nil ((((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "8B00-9439-83D1-B48B") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) ((min-height . 4) (min-width . 21) (min-height-ignore . 2) (min-width-ignore . 21) (min-height-safe . 1) (min-width-safe . 4) (min-pixel-height . 52) (min-pixel-width . 147) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 147) (min-pixel-height-safe . 13) (min-pixel-width-safe . 28)) hc (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 686) (pixel-height . 755) (total-width . 98) (total-height . 58) (normal-height . 1.0) (normal-width . 0.5034246575342466) (buffer "gtkutil.c" (selected . t) (hscroll . 0) (fringes 8 0 nil) (margins 4) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 25202) (start . 23482))) (leaf (last . t) (pixel-width . 680) (pixel-height . 755) (total-width . 97) (total-height . 58) (normal-height . 1.0) (normal-width . 0.4965753424657534) (buffer "gtkwindow.c" (selected) (hscroll . 0) (fringes 8 0 nil) (margins 5) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 346800) (start . 346686)))) (((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (visibility . t) (sticky) (frameset--id . "2A59-81FB-8BFF-3685") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (height . 59) (width . 191) (left . 0) (top . 0)) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 52) (min-pixel-width . 70) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 42) (min-pixel-height-safe . 13) (min-pixel-width-safe . 14)) leaf (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (buffer "*Messages*" (selected) (hscroll . 0) (fringes 8 0 nil) (margins nil) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 5) (start . 1))) (((font-backend xft x) (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1") (font-parameter) (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (horizontal-scroll-bars) (foreground-color . "wheat") (background-color . "black") (mouse-color . "black") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 0) (scroll-bar-foreground) (scroll-bar-background) (menu-bar-lines . 0) (tool-bar-lines . 0) (title) (wait-for-wm . t) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (scroll-bar-height . 0) (alpha) (fullscreen . fullboth) (display-type . color) (background-mode . dark) (cursor-color . "thistle") (sticky) (environment) (frameset--id . "DC57-2577-7FAB-434C") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (fullscreen-restore . maximized) (visibility . t) (height . 59) (width . 191) (left . 0) ...) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 52) (min-pixel-width . 70) (min-pixel-height-ignore . 26) (min-pixel-width-ignore . 42) (min-pixel-height-safe . 13) (min-pixel-width-safe . 14)) leaf (pixel-width . 1366) (pixel-height . 755) (total-width . 195) (total-height . 58) (normal-height . 1.0) (normal-width . 1.0) (buffer "*eww*" (selected) (hscroll . 0) (fringes 8 0 nil) (margins nil) (scroll-bars nil 3 t nil 0 t) (vscroll . 0) (dedicated) (point . 1) (start . 1))))] :reuse-frames t :cleanup-frames t :force-display t :force-onscreen t)
  desktop-restore-frameset()
  desktop-read()
  #[0 "\303\211\b\235\203\x10\0\304\x01\b\"\x10\301\305!\210\210	\205^[\0\306 \210\307\211\x12\207" [command-line-args desktop-save-mode inhibit-startup-screen "--no-desktop" delete 0 desktop-read t] 4]()
  run-hooks(after-init-hook delayed-warnings-hook)
  command-line()
  normal-top-level()

[-- Attachment #4: Type: text/plain, Size: 5 bytes --]


N.

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

[martin rudalics]

 > With a desktop file specifying three frames, there seem to be two
 > calls to `make-frame-on-display' (when the second and third frames
 > are created). Each call ultimately results in one of the reported
 > GTK warning messages.
 >
 > Detailed backtraces at these two calls to `make-frame-on-display'
 > are attached.

Thanks.  Please try now with a small init file containing a ‘make-frame’
call with the parameters from these attachments.  For your first entry
I'd suggest to start with bisecting the parameter list in calls like

(make-frame
  '((font-backend xft x)
    (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1")
    (font-parameter)
    (border-width . 0)
    (internal-border-width . 0)
    (right-divider-width . 0)
    (bottom-divider-width . 0)
    (vertical-scroll-bars . right)
    (horizontal-scroll-bars)
    (foreground-color . "wheat")
    (background-color . "black")
    (mouse-color . "black")
    (border-color . "black")
    (screen-gamma)
    (line-spacing)
    (left-fringe . 8)
    (right-fringe . 0)
    (scroll-bar-foreground)
    (scroll-bar-background)
    (menu-bar-lines . 0)
    (tool-bar-lines . 0)
    (title)
    (wait-for-wm . t)
    (tool-bar-position . top)
    (icon-type . t)
    (auto-raise)
    (auto-lower)
    (cursor-type . box)
    (scroll-bar-width . 16)
    (scroll-bar-height . 0)
    (alpha)
    (fullscreen . fullboth)
    (display-type . color)
    (background-mode . dark)
    (cursor-color . "thistle")
    (visibility . t)
    (sticky)
    (frameset--id . "8B00-9439-83D1-B48B")
    (frameset--mini t)
    (modeline . t)
    (minibuffer . t)
    (unsplittable)
    (icon-name)
    (display . ":0")
    (explicit-name)
    (fullscreen-restore . maximized)
    (height . 59)
    (width . 191)
    (left . 0)
    (top . 0)))

Everything contained in these

  (((min-height . 4)
    (min-width . 21)
    (min-height-ignore . 2)
    (min-width-ignore . 21)
    (min-height-safe . 1)
    (min-width-safe . 4)
    (min-pixel-height . 52)
    (min-pixel-width . 147)
    (min-pixel-height-ignore . 26)
    (min-pixel-width-ignore . 147)
    (min-pixel-height-safe . 13)
    (min-pixel-width-safe . 28))
   hc
   (pixel-width . 1366)
   (pixel-height . 755)
   (total-width . 195)
   (total-height . 58)
   (normal-height . 1.0)
   (normal-width . 1.0)
   (combination-limit)
   (leaf
    (pixel-width . 686)
    (pixel-height . 755)
    (total-width . 98)
    (total-height . 58)
    (normal-height . 1.0)
    (normal-width . 0.5034246575342466)
    (buffer "gtkutil.c"
	   (selected . t)
	   (hscroll . 0)
	   (fringes 8 0 nil)
	   (margins 4)
	   (scroll-bars nil 3 t nil 0 t)
	   (vscroll . 0)
	   (dedicated)
	   (point . 25202)
	   (start . 23482)))
   (leaf
    (last . t)
    (pixel-width . 680)
    (pixel-height . 755)
    (total-width . 97)
    (total-height . 58)
    (normal-height . 1.0)
    (normal-width . 0.4965753424657534)
    (buffer "gtkwindow.c"
	   (selected)
	   (hscroll . 0)
	   (fringes 8 0 nil)
	   (margins 5)
	   (scroll-bars nil 3 t nil 0 t)
	   (vscroll . 0)
	   (dedicated)
	   (point . 346800)
	   (start . 346686))))

that is stuff prefixed by min-, hc, vc and leaf is hopefully irrelevant.
The following

  ((background-color . frameset-filter-sanitize-color)
   (buffer-list . :never)
   (buffer-predicate . :never)
   (buried-buffer-list . :never)
   (font . frameset-filter-shelve-param)
   (foreground-color . frameset-filter-sanitize-color)
   (fullscreen . frameset-filter-shelve-param)
   (GUI:font . frameset-filter-unshelve-param)
   (GUI:fullscreen . frameset-filter-unshelve-param)
   (GUI:height . frameset-filter-unshelve-param)
   (GUI:width . frameset-filter-unshelve-param)
   (height . frameset-filter-shelve-param)
   (outer-window-id . :never)
   (parent-id . :never)
   (tty . frameset-filter-tty-to-GUI)
   (tty-type . frameset-filter-tty-to-GUI)
   (width . frameset-filter-shelve-param)
   (window-id . :never)
   (window-system . :never)
   (name . :never)
   (left . frameset-filter-iconified)
   (minibuffer . frameset-filter-minibuffer)
   (top . frameset-filter-iconified))

might be relevant but if so we have to consult Juanma how to extract
useful information from it.

IIUC you saved two frames.  Please try whether you can reproduce the
problem with one frame only.  If not, you need two ‘make-frame’ calls.

Thanks again, martin

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

[N. Jackson]

At 09:04 +0100 on Monday 2017-02-27, martin rudalics wrote:
>
> Thanks. Please try now with a small init file containing a
> ‘make-frame’ call with the parameters from these attachments.
> For your first entry I'd suggest to start with bisecting the
> parameter list in calls like
>
> (make-frame
>  '((font-backend xft x)
>    (font . "-Bits-Bitstream Vera Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1")
>    (font-parameter)
>    (border-width . 0)
>    (internal-border-width . 0)
>    (right-divider-width . 0)
>    (bottom-divider-width . 0)
>    (vertical-scroll-bars . right)
>    (horizontal-scroll-bars)
>    (foreground-color . "wheat")
>    (background-color . "black")
>    (mouse-color . "black")
>    (border-color . "black")
>    (screen-gamma)
>    (line-spacing)
>    (left-fringe . 8)
>    (right-fringe . 0)
>    (scroll-bar-foreground)
>    (scroll-bar-background)
>    (menu-bar-lines . 0)
>    (tool-bar-lines . 0)
>    (title)
>    (wait-for-wm . t)
>    (tool-bar-position . top)
>    (icon-type . t)
>    (auto-raise)
>    (auto-lower)
>    (cursor-type . box)
>    (scroll-bar-width . 16)
>    (scroll-bar-height . 0)
>    (alpha)
>    (fullscreen . fullboth)
>    (display-type . color)
>    (background-mode . dark)
>    (cursor-color . "thistle")
>    (visibility . t)
>    (sticky)
>    (frameset--id . "8B00-9439-83D1-B48B")
>    (frameset--mini t)
>    (modeline . t)
>    (minibuffer . t)
>    (unsplittable)
>    (icon-name)
>    (display . ":0")
>    (explicit-name)
>    (fullscreen-restore . maximized)
>    (height . 59)
>    (width . 191)
>    (left . 0)
>    (top . 0)))
>

From `emacs -Q' the above call to `make-frame' causes the GTK
warning message.

After bisecting, I find that if I omit the last two lines, the GTK
warning is not emitted. Either or both of these two lines is
sufficient to produce the warning message:

  $ src/emacs -Q --eval "(make-frame '((left . 0)))"

  (emacs:13000): 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.

  $ src/emacs -Q --eval "(make-frame '((top . 0)))"    

  (emacs:13008): 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.

  $ src/emacs -Q --eval "(make-frame '((left . 0)(top . 0)))"

  (emacs:13020): 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.

And finally,

  $ src/emacs -Q --eval "(make-frame)"

produces no warning.


> IIUC you saved two frames.  Please try whether you can reproduce the
> problem with one frame only.  If not, you need two ‘make-frame’ calls.

There is no warning message issued for the first/main Emacs frame.
So there is one less warning message than there are frames
restored from the desktop file. So in my previous examples I had
three frames and two warning messages. I hope that helps clarify
things.

N.

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

[martin rudalics]

 > After bisecting, I find that if I omit the last two lines, the GTK
 > warning is not emitted. Either or both of these two lines is
 > sufficient to produce the warning message:
 >
 >    $ src/emacs -Q --eval "(make-frame '((left . 0)))"
 >
 >    (emacs:13000): 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.
 >
 >    $ src/emacs -Q --eval "(make-frame '((top . 0)))"
 >
 >    (emacs:13008): 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.
 >
 >    $ src/emacs -Q --eval "(make-frame '((left . 0)(top . 0)))"
 >
 >    (emacs:13020): 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.

Thanks, I see now.  For some reason I was convinced that the visibility
settings in frameset were involved.

martin

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 11:09:22 -0500
> 
> This is my interaction with GDB after `C-x 5 2':
> 
>   Thread 1 "emacs" hit Breakpoint 3, xg_set_geometry (f=0x386d000) at gtkutil.c:778
>   778       if (f->size_hint_flags & (USPosition | PPosition))
>   (gdb) print f->size_hint_flags 
>   $3 = 0

If the value of the hint flags is zero, none of the individual hints
will match, obviously.

>   (gdb) print USPosition
>   No symbol "USPosition" in current context.
>   (gdb) print PPosition
>   No symbol "PPosition" in current context.
>   (gdb) print (USPosition | PPosition)
>   No symbol "USPosition" in current context.
>   (gdb) print (f->size_hint_flags & (USPosition | PPosition))
>   No symbol "USPosition" in current context.
>   (gdb) n
>   808     }
>   (gdb)
> 
> Is my syntax wrong when I try to get the values?

It sometimes happens with preprocessor macros.  The trick I use in
those cases is this:

  (gdb) print USPosition+0

If even this doesn't help, it most probably means Emacs wasn't
compiled with the -g3 flag.

In any case, googling finds this:

  https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html

which shows the values of the flags.

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

[N. Jackson]

At 09:55 +0200 on Saturday 2017-02-25, Eli Zaretskii wrote:
>
> It sometimes happens with preprocessor macros.  The trick I use in
> those cases is this:
>
>   (gdb) print USPosition+0
>
> If even this doesn't help, it most probably means Emacs wasn't
> compiled with the -g3 flag.

I did have the `-g3' flag set. However as part of the historical baggage
in my build script I also had `-ggdb'. Removing the `-ggdb' flag fixed
this particular problem. Now I can get GDB to show me the values of
preprocessor "constants". Thanks.

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

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

[Drew Adams]

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

I have not been following this thread, so apologies if what
I say here does not seem to help.

I don't see (here) you give a reason (beyond the statement that
you have thought about it twice) why a desktop file should not
restore frame positions by default.  (Maybe you gave a reason
prior to this post?)

As one user of multiple frames (and multiple desktops) I would
(naively perhaps) expect a desktop state to restore frames as
they were when they were saved, modulo anything that might be
strictly impossible or unfeasible to do.

If frame positions are not restored in general (again, modulo
any necessary exceptions that might exist) that would suggest
that there is little point in saving and restoring frames.

Size and position are among the most important attributes of a
frame, and if a user bothers to use multiple frames then it is
almost certainly the case that their sizes and positions are
important.

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

[N. Jackson]

At 06:47 -0700 on Thursday 2017-03-23, Drew Adams wrote:
>
> As one user of multiple frames (and multiple desktops) I would
> (naively perhaps) expect a desktop state to restore frames as
> they were when they were saved, modulo anything that might be
> strictly impossible or unfeasible to do.

I agree with Drew here. a user would reasonably expect that part
of the job of the desktop feature is restoring frames to their
former positions.

> If frame positions are not restored in general (again, modulo
> any necessary exceptions that might exist) that would suggest
> that there is little point in saving and restoring frames.

There is also, of course, the re-creation of all the buffers and
the re-assignment of the right buffers to the right windows on the
right frames. This is at least as important IMO.

> Size and position are among the most important attributes of a
> frame, and if a user bothers to use multiple frames then it is
> almost certainly the case that their sizes and positions are
> important.

Well, in my case, my display is small and all frames are
maximized, so the position of the frames is not important. So I
disagree with the "almost certainly", but otherwise I agree
completely.

N.

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

[martin rudalics]

 > If frame positions are not restored in general (again, modulo
 > any necessary exceptions that might exist) that would suggest
 > that there is little point in saving and restoring frames.
 >
 > Size and position are among the most important attributes of a
 > frame, and if a user bothers to use multiple frames then it is
 > almost certainly the case that their sizes and positions are
 > important.

Jan who was responsible for the implementation of this in the past
advocated the use of Extended Window Manager Hints where you can read
(in the section about _NET_WM_FULL_PLACEMENT) that

   Clients, when they detect that this hint is supported, SHOULD NOT
   abuse or often even use PPosition and USPosition hints for requesting
   placement.

   Rationale: Window managers can often perform better placement (that
   may be even configurable) for windows than the application. However at
   the time of writing this it is problematic for Window managers to
   decide when to use them because many applications abuse positioning
   flags and/or provide unnecessary default positions.

So it's up to us to either go this direction or do our own placement.  I
neither use desktop saving nor explicit window positioning so I have no
preference.  But as this bug demonstrates, it seems that we may have to
choose one or the other eventually.  Otherwise, we will sooner or later
end up in situations that are more troublesome than the present one.

martin

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

[N. Jackson]

At 10:01 +0100 on Friday 2017-03-24, martin rudalics wrote:
>
>   Rationale: Window managers can often perform better placement (that
>   may be even configurable) for windows than the application. However at
>   the time of writing this it is problematic for Window managers to
>   decide when to use them because many applications abuse positioning
>   flags and/or provide unnecessary default positions.

My reading of this text is that it says that applications should not
micromanage the positioning of windows. That makes sense. But placement
of restored windows at startup is not micromanagement in my opinion.
After all, it is putting windows back in the position that the Window
Manager placed them in the first place, or back in the position that the
user moved them to.

N.

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

[martin rudalics]

 > My reading of this text is that it says that applications should not
 > micromanage the positioning of windows. That makes sense. But placement
 > of restored windows at startup is not micromanagement in my opinion.
 > After all, it is putting windows back in the position that the Window
 > Manager placed them in the first place, or back in the position that the
 > user moved them to.

Right from our POV.  But the window manager wouldn't know that these
frames are just "put back".

Note also that I do not necessarily agree with that text - it just might
explain the rationale of the windowing systems or window managers we use.

martin

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

[Eli Zaretskii]

> Date: Thu, 23 Mar 2017 08:59:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 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.

ISTR that there was a long discussion about this when Juanma
implemented these features, so the current behavior is not just a
random choice on his part.

FWIW, I'm rather fond of the current behavior, since whenever I need
to restart Emacs, it recreates the precise frame arrangement I had
when I shut it down.

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

[martin rudalics]

 > ISTR that there was a long discussion about this when Juanma
 > implemented these features, so the current behavior is not just a
 > random choice on his part.
 >
 > FWIW, I'm rather fond of the current behavior, since whenever I need
 > to restart Emacs, it recreates the precise frame arrangement I had
 > when I shut it down.

According to a comment in gtkwindow.c:

  * If you are saving and restoring your application's window
  * positions, you should know that it's impossible for applications to
  * do this without getting it somewhat wrong because applications do
  * not have sufficient knowledge of window manager state. The Correct
  * Mechanism is to support the session management protocol (see the
  * "GnomeClient" object in the GNOME libraries for example) and allow
  * the window manager to save your window sizes and positions.

Just to explain where my doubts come from.

martin

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

[N. Jackson]

At 10:08 -0500 on Thursday 2017-02-23, N. Jackson wrote:

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

This bug persists in the released version of Emacs 25.2 (built
from the tarball).

On the other hand, Master, checked out on 2017-04-27
(79c5ea9911a9aba7db0ba0e367e06507cee2fc02), does not exhibit the
bug.

I was unable to test the emacs-25 branch checked out on 2017-04-27
(784602b10506c50075aa9463891a47380ebea55f) because I haven't been
able to build it so far, however, since the log doesn't indicate
any substantive commits since the release of 25.2, it probably
still has the bug.

(I am unable to build the emacs-25 branch because of the following
messages form autogen.sh. The indicated files do not exist in
emacs/m4/ but, for example count-trailing-zeros.m4, does exist.

  $ ./autogen.sh
  Checking whether you have the necessary tools...
  (Read INSTALL.REPO for more details on building Emacs)

  Checking for autoconf (need at least version 2.65)...
  ok
  Checking for automake (need at least version 1.11)...
  ok
  Your system has the required tools.
  Running 'autoreconf -fi -I m4' ...
  /usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:27: cannot open `m4/flexmember.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:43: cannot open `m4/limits-h.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:73: cannot open `m4/std-gnu11.m4': No such file or directory
  autom4te: /usr/bin/m4 failed with exit status: 1
  /usr/bin/m4:aclocal.m4:9: cannot open `m4/count-leading-zeros.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:27: cannot open `m4/flexmember.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:43: cannot open `m4/limits-h.m4': No such file or directory
  /usr/bin/m4:aclocal.m4:73: cannot open `m4/std-gnu11.m4': No such file or directory
  autom4te: /usr/bin/m4 failed with exit status: 1
  autoreconf: /usr/bin/autoconf failed with exit status: 1
)

N.

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

[Noam Postavsky]

On Thu, Apr 27, 2017 at 3:45 PM, N. Jackson <nljlistbox2@gmail.com> wrote:
>
> (I am unable to build the emacs-25 branch because of the following
> messages form autogen.sh. The indicated files do not exist in
> emacs/m4/ but, for example count-trailing-zeros.m4, does exist.

Try deleting aclocal.m4 first (there's no difference between the 25.2
tarball and emacs-25 though).

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

[N. Jackson]

At 15:52 -0400 on Thursday 2017-04-27, Noam Postavsky wrote:

> On Thu, Apr 27, 2017 at 3:45 PM, N. Jackson <nljlistbox2@gmail.com> wrote:
>>
>> (I am unable to build the emacs-25 branch because of the
>> following messages form autogen.sh. The indicated files do not
>> exist in emacs/m4/ but, for example count-trailing-zeros.m4,
>> does exist.
>
> Try deleting aclocal.m4 first (there's no difference between the
> 25.2 tarball and emacs-25 though).

Thanks Noam. This sorted itself with:

  git clean -x --force
  git reset --hard

Bit of a sledge hammer maybe; perhaps your surgical deletion of
emacs/aclocal.m4 would have worked too. Anyway, not sure what I'd
done wrong but everything is working again now.

N.

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

[N. Jackson]

At 15:45 -0400 on Thursday 2017-04-27, N. Jackson wrote:

> This bug persists in the released version of Emacs 25.2 (built
> from the tarball).
>
> On the other hand, Master, checked out on 2017-04-27
> (79c5ea9911a9aba7db0ba0e367e06507cee2fc02), does not exhibit the
> bug.
>
> I was unable to test the emacs-25 branch

No doubt obvious, but for completeness I wanted to report that the bug
is still present in current emacs-25 branch
(784602b10506c50075aa9463891a47380ebea55f ).

Thanks.

N.

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

[N. Jackson]

At 11:08 -0500 on Thursday 2017-02-23, N. Jackson wrote:
>
> 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.

This bug is fixed in the emacs-26 branch so I am closing it. Thank
you.

(Of course, if you think there is some subtlety in the bug that
has not been fully addressed (I don't think there is), please
reopen it.)

Regards,
N.