From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Whats the right way to add gtk components to Emacs? Date: Sun, 03 Jul 2011 20:04:56 +0200 Message-ID: References: <4E103190.7000301@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1309716342 1089 80.91.229.12 (3 Jul 2011 18:05:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 3 Jul 2011 18:05:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jan =?iso-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 03 20:05:35 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 1QdR31-00050y-0u for ged-emacs-devel@m.gmane.org; Sun, 03 Jul 2011 20:05:35 +0200 Original-Received: from localhost ([::1]:54133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdR30-0005t9-3u for ged-emacs-devel@m.gmane.org; Sun, 03 Jul 2011 14:05:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdR2c-0005pm-Ce for emacs-devel@gnu.org; Sun, 03 Jul 2011 14:05:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QdR2a-0002y2-BM for emacs-devel@gnu.org; Sun, 03 Jul 2011 14:05:10 -0400 Original-Received: from m1.alltele.net ([85.30.0.4]:60986 helo=smtp.alltele.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QdR2Z-0002tl-RV for emacs-devel@gnu.org; Sun, 03 Jul 2011 14:05:08 -0400 Original-Received: from chopper ([87.96.210.139]) by smtp.alltele.net (IceWarp 10.3.1 RC1) with ESMTP (SSL) id MZH89256; Sun, 03 Jul 2011 20:04:56 +0200 In-Reply-To: <4E103190.7000301@swipnet.se> ("Jan \=\?iso-8859-1\?Q\?Dj\=E4rv\=22\?\= \=\?iso-8859-1\?Q\?'s\?\= message of "Sun, 03 Jul 2011 11:08:32 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-CTCH: RefID="str=0001.0A0B0201.4E10AF4A.00B4,ss=1,re=0.000,fgs=0"; Spam="Unknown"; VOD="Unknown" X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-Received-From: 85.30.0.4 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:141501 Archived-At: Jan Dj=E4rv writes: > 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 fra= mes. > Tooltips are a special case. Sorry, this turned out to be brain damage on my side. > >> - 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[] =3D "GDK_CORE_DEVICE_EVENTS=3D1"; > 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. Thanks for all this information! I've implemented event forwarding now in the xwidget branch to an offscreen webkit instance. It works supiciously well so far. I can split a webkit view in several emacs windows, forward mouseclicks and motion events, and damage events are received to the onscreen webkit views. So far so good... > Jan D. --=20 Joakim Verona