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: xwidget branch Date: Fri, 02 Jul 2010 10:40:58 +0200 Message-ID: <4C2DA61A.3030808@swipnet.se> References: <4C2B309B.8000402@swipnet.se> <4C2CB9BE.8000204@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1278060082 19199 80.91.229.12 (2 Jul 2010 08:41:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2010 08:41:22 +0000 (UTC) Cc: Emacs development discussions To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 02 10:41:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OUboB-0002qi-O3 for ged-emacs-devel@m.gmane.org; Fri, 02 Jul 2010 10:41:16 +0200 Original-Received: from localhost ([127.0.0.1]:35006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUboA-0005dK-QK for ged-emacs-devel@m.gmane.org; Fri, 02 Jul 2010 04:41:14 -0400 Original-Received: from [140.186.70.92] (port=60827 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUbnz-0005bb-D2 for emacs-devel@gnu.org; Fri, 02 Jul 2010 04:41:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUbny-0002Xy-0d for emacs-devel@gnu.org; Fri, 02 Jul 2010 04:41:03 -0400 Original-Received: from smtprelay-h21.telenor.se ([195.54.99.196]:50831) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUbnx-0002Xf-Ny for emacs-devel@gnu.org; Fri, 02 Jul 2010 04:41:01 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 162F0C3BA for ; Fri, 2 Jul 2010 10:41:00 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Akg/AMhCLUxV4S0jPGdsb2JhbACHbpd8DAEBAQE1Lb1lhSUE X-IronPort-AV: E=Sophos;i="4.53,525,1272837600"; d="scan'208";a="98304440" Original-Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 02 Jul 2010 10:40:59 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 28C7D7FA05A; Fri, 2 Jul 2010 10:40:59 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126681 Archived-At: joakim@verona.se skrev 2010-07-01 21.28: > Jan Dj=E4rv writes: > >> joakim@verona.se skrev 2010-06-30 15.09: >>> Jan Dj=E4rv writes: >>> >>>> This sounds like fun. How do you handle multiple windows, that is t= he >>>> same buffer with widgets displayed in different frames/windows? >>> >>> There are some notes in the readme. I paste it below so we can discus= s it >>> and improve it. This is as you might imagine the really tricky part. >>> >>> >> >> I guess it takes some kind of proxy object that keeps track of >> creating the real widget for each window. GtkAction:s can help here. >> You can have a GtkAction instead of the real widget. When redisplay >> is done, check all proxy widgets for the GtkAction, and if no one is >> present for the window, create one. The window can be saved in the >> real widget as widget data. > > Ill have to look into that idea. Would it really work for all sorts of > widgets, like sliders? Maybe you can elaborate a bit more, it sounds > interesting. No, unfortunately GtkAction only works with widgets that implement the=20 interface GtkActivatable. A custom Emacs proxy would be needed. I was just thinking of a list that stores pairs and adds= to=20 it if the current window isn't there. Of course removing from this list=20 becomes a problem. Keeping thinks like sliders in sync is also an issue. > >> I think the "don't display cursor over widget"-problem should have >> some precedence, it really looks awful :-). > > Its not spectacularily beautiful no. But doesnt images have the same > issues? Maybe images have some cursor handling code that can be reused? It can be tricky to do exactly the same. Images just alter the backgroun= d=20 when the cursor is over them. But Gtk+ widgets can repaint the backgroun= d=20 when they feel like it. I suggest trying to alter the widget state, for=20 example to PRELIGHT. Then again, not all widgets differ between normal a= nd=20 prelight state. > >> I see lots of redisplay-problems with widgets, but that is to expected >> as Emacs doesn't use the Gtk+ event loop. It took a while before Gtk+ >> scrollbars displayed nicely, and even now bugs show up. You have to >> request redraw on widgets and flush the Gdk event queue manually at >> appropriate places. > > Do you have any example pointers in the Emacs source handy? > x_clear_frame and x_clear_frame_area in xterm.c, xg_update_scrollbar_pos = in=20 gtkutil.c forces redraw. Jan D.