From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25851: 25.2; GTK warning when starting Emacs when desktop file has more than one frame Date: Sat, 25 Feb 2017 10:17:28 +0200 Message-ID: <83fuj2smzr.fsf@gnu.org> References: <87a89c51qb.fsf@moondust.localdomain> <831suoub86.fsf@gnu.org> <87lgswmi6a.fsf@moondust.localdomain> <83vas0rozb.fsf@gnu.org> <87k28fso3o.fsf@moondust.localdomain> <83o9xrsmrd.fsf@gnu.org> <874lzjsh8t.fsf@moondust.localdomain> <87y3wvqqos.fsf@moondust.localdomain> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1488010764 12819 195.159.176.226 (25 Feb 2017 08:19:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2017 08:19:24 +0000 (UTC) Cc: 25851@debbugs.gnu.org To: nljlistbox2@gmail.com (N. Jackson) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 25 09:19:19 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chXZQ-00029N-2G for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Feb 2017 09:19:12 +0100 Original-Received: from localhost ([::1]:41719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chXZU-0001Mu-FK for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Feb 2017 03:19:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chXZL-0001Mo-Kf for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2017 03:19:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chXZG-0008Ez-NE for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2017 03:19:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56926) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1chXZG-0008Eu-Ji for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2017 03:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1chXZG-0004DA-Dm for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2017 03:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2017 08:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25851 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25851-submit@debbugs.gnu.org id=B25851.148801068816130 (code B ref 25851); Sat, 25 Feb 2017 08:19:02 +0000 Original-Received: (at 25851) by debbugs.gnu.org; 25 Feb 2017 08:18:08 +0000 Original-Received: from localhost ([127.0.0.1]:55125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chXYO-0004C6-8A for submit@debbugs.gnu.org; Sat, 25 Feb 2017 03:18:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59917) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chXYM-0004BZ-HZ for 25851@debbugs.gnu.org; Sat, 25 Feb 2017 03:18:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chXY9-0007xG-FD for 25851@debbugs.gnu.org; Sat, 25 Feb 2017 03:17:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chXY9-0007x9-BT; Sat, 25 Feb 2017 03:17:53 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2881 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1chXY8-0004Gg-Ee; Sat, 25 Feb 2017 03:17:52 -0500 In-reply-to: <87y3wvqqos.fsf@moondust.localdomain> (nljlistbox2@gmail.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:129763 Archived-At: > 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.