From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Whats the right way to add gtk components to Emacs? Date: Sun, 03 Jul 2011 11:08:32 +0200 Message-ID: <4E103190.7000301@swipnet.se> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1309684149 10527 80.91.229.12 (3 Jul 2011 09:09:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 3 Jul 2011 09:09:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 03 11:09:05 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QdIfm-0008Lu-VY for ged-emacs-devel@m.gmane.org; Sun, 03 Jul 2011 11:09:03 +0200 Original-Received: from localhost ([::1]:40736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdIfl-0002as-SV for ged-emacs-devel@m.gmane.org; Sun, 03 Jul 2011 05:09:02 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdIfS-0002aH-PJ for emacs-devel@gnu.org; Sun, 03 Jul 2011 05:08:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QdIfQ-0006hW-3c for emacs-devel@gnu.org; Sun, 03 Jul 2011 05:08:42 -0400 Original-Received: from smtprelay-b22.telenor.se ([195.54.99.213]:44774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdIfP-0006hP-CO for emacs-devel@gnu.org; Sun, 03 Jul 2011 05:08:39 -0400 Original-Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 16DE1EA18D for ; Sun, 3 Jul 2011 11:08:34 +0200 (CEST) X-SENDER-IP: [85.225.45.100] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoB5ANUwEE5V4S1kPGdsb2JhbABSiQqQAI5yCwEBAQEeGQ0liHzAW4Y2BJcui0A X-IronPort-AV: E=Sophos;i="4.65,467,1304287200"; d="scan'208";a="1745056672" Original-Received: from c-642de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.100]) by ipb4.telenor.se with ESMTP; 03 Jul 2011 11:08:33 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 256EC7FA05A; Sun, 3 Jul 2011 11:08:33 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.54.99.213 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141488 Archived-At: joakim@verona.se skrev 2011-07-02 17.53: > I the Xwidget branch I add gtk components to the buffer. It works mostly > well. Some cases dont work too well: > > - If I create a new toplevel window and add a component to it, Emacs > crashes. Interesting. I guess the assumtion is that Gtk top level windows are frames. Tooltips are a special case. > - If I make an offscreen buffer and try to catch damage events, many > events seemingly get lost. > > Emacs does some kind of trickery with X events which I suspect is the > root cause. How does this work? How do I make my more complicated > components work in this scheme? Hard to tell, since "this scheme" is not very detailed. But here is the big picture. In x_term_init, we first make sure no extended input events are used: /* Emacs can only handle core input events, so make sure Gtk doesn't use Xinput or Xinput2 extensions. */ { static char fix_events[] = "GDK_CORE_DEVICE_EVENTS=1"; putenv (fix_events); } Then we install an event filter: /* NULL window -> events for all windows go to our function */ gdk_window_add_filter (NULL, event_handler_gdk, NULL); All events go to that function. It in turn calls handle_one_xevent which is the big event switch. handle_one_xevent may deside that it is inappropriate to forward some events to Gtk+, so it sets flags that event_handler_gdk inspects. Some events go to Gtk+, some are dropped. The reason for dropping events is that they conflict with what Emacs does (i.e. clears/redraws windows, takes actions on property notify, and more). All this complication is because it was desided that the big event switch should be used for Gtk+ also, i.e. keep code duplication to a minimum. Jan D.