GNU bug report logs - #4134
23.1; Problems with gtk+ >= 2.7.19

Previous Next

Full log

Message #43 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: [Fwd: [Bug 593249] emacs and acroread don't work properly after
 upgrading to 2.17.9]
Date: Thu, 27 Aug 2009 11:58:02 -0400

[Message part 1 (text/plain, inline)]

Turns out the problem is in gtk+.  I've filed a bug report and this is
the last (relevant) comment on the bug.

David

[Message part 2 (message/rfc822, inline)]

From: gtk+ (bugzilla.gnome.org) <bugzilla <at> gnome.org>
To: david.ronis <at> mcgill.ca
Subject: [Bug 593249] emacs and acroread don't work properly after
 upgrading to 2.17.9
Date: Thu, 27 Aug 2009 11:34:17 +0000 (UTC)

http://bugzilla.gnome.org/show_bug.cgi?id=593249



--- Comment #3 from Alexander Larsson <alexl <at> redhat.com> 2009-08-27 11:34:14 UTC ---
For the emacs thing, I can reproduce this here, but emacs does some pretty
weird things in its Gtk+ integration that can conflict quite a lot with the new
client-side window stuff in the later Gtk+.

Running with GDK_NATIVE_WINDOWS=1 in gtk+ >= 2.17.9 fixes this issue, although
setting that in emacs may not be a good idea as it will propagate to apps
launched by emacs. Instead I would recommend adding some code to emacs that
calls gdk_x11_drawable_get_xid() on all "toplevel" Gtk+ widgets they put in the
buffer window. This will ensure these windows get their own X window and should
be totally backwards compat and safe on older versions of Gtk+.

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.