emacs, GSettings, and gtk3

[Ken Brown]

I am now able to build emacs-X11 with GSettings support, using either 
gtk2 or gtk3; the problems discussed in 
http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html have disappeared.


Unfortunately, the resulting build produces some annoying Gtk warnings. 
 I'm trying to decide whether the benefits of GSettings and gtk3 
outweigh the annoyances.  I'd like the opinions of emacs users and GNOME 
experts on this.  Here are the details:


1. If emacs is built using gtk3 and the window geometry is specified on 
the command line or in ~/.Xdefaults, the following warning appears in 
the terminal from which emacs was started:


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 warning can safely be ignored but is annoying.  See

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11177

I don't know any good workaround, except perhaps to wrap emacs in a 
script, or use an alias, that redirects stderr to a file.  (This would 
be similar to the Linux behavior, where I think stderr for programs 
started under X11 is typically redirected to ~/.xsession-errors.)


2. If emacs is built with GSettings support and is started without a 
D-Bus daemon running, the following warning is issued:


GLib-WARNING **: In call to g_spawn_sync(), exit status of a child 
process was requested but SIGCHLD action was set to SIG_IGN and ECHILD 
was received by waitpid(), so exit status can't be returned. This is a 
bug in the program calling g_spawn_sync(); either don't request the exit 
status, or don't set the SIGCHLD action.


The warning can usually, but not always, be ignored.  See

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8855

In this case there is a simple workaround: Ensure, by a suitable line in 
~/.startxwinrc or ~/.bashrc, that a D-Bus daemon is always running 
before emacs is started.


Thanks in advance for any opinions/advice on how I should deal with 
these issues in the next emacs release.  The simplest solution would be 
to continue to use gtk2 and to disable GSettings support, but I'm open 
to other suggestions.


Ken Brown
Cygwin's Emacs maintainer

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: emacs, GSettings, and gtk3

[Yaakov (Cygwin/X)]

On Mon, 2012-11-26 at 07:56 -0500, Ken Brown wrote:
 I'm trying to decide whether the benefits of GSettings and gtk3 
 outweigh the annoyances.  I'd like the opinions of emacs users and GNOME 
 experts on this.  Here are the details:
 
 1. If emacs is built using gtk3 and the window geometry is specified on 
 the command line or in ~/.Xdefaults, the following warning appears in 
 the terminal from which emacs was started:
 
 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 warning can safely be ignored but is annoying.

GTK+ warnings aren't uncommon, as GTK+ behaviour gradually changes over
time and programs don't always keep up.  If the program operates
correctly, and upstream says they can be ignored, then I wouldn't worry
about them.

As for choosing between GTK+ 2 vs 3, I would go with the upstream
default.

 2. If emacs is built with GSettings support and is started without a 
 D-Bus daemon running, the following warning is issued:
 
 GLib-WARNING **: In call to g_spawn_sync(), exit status of a child 
 process was requested but SIGCHLD action was set to SIG_IGN and ECHILD 
 was received by waitpid(), so exit status can't be returned. This is a 
 bug in the program calling g_spawn_sync(); either don't request the exit 
 status, or don't set the SIGCHLD action.
 
 In this case there is a simple workaround: Ensure, by a suitable line in 
 ~/.startxwinrc or ~/.bashrc, that a D-Bus daemon is always running 
 before emacs is started.

A D-Bus session daemon is required for most modern desktop software
nowadays, so I wouldn't consider this a setback.

HTH,


Yaakov



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/