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: Gtk tabs in emacs, new branch. Date: Tue, 13 Apr 2010 08:29:43 +0200 Message-ID: <4BC40F57.1000106@swipnet.se> References: <30298845.656931270806476838.JavaMail.www@wwinf4631> <4BBF0C6C.7000909@swipnet.se> <87ljcwaxfv.fsf@mail.jurta.org> <4BC016DA.60400@swipnet.se> <87d3y63gzt.fsf@mail.jurta.org> <4BC1EAB2.6080900@harpegolden.net> <87zl18fadw.fsf@mail.jurta.org> <87d3y43wg7.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1271146696 23978 80.91.229.12 (13 Apr 2010 08:18:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 08:18:16 +0000 (UTC) Cc: Juri Linkov , "Emacs Dev \[emacs-devel\]" , David De La Harpe Golden To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 10:18:15 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 1O1bJu-0003e5-6g for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 10:18:15 +0200 Original-Received: from localhost ([127.0.0.1]:44162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1bJl-0008Sl-Mw for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 04:17:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1bDu-0004Rd-4i for emacs-devel@gnu.org; Tue, 13 Apr 2010 04:11:54 -0400 Original-Received: from [140.186.70.92] (port=46437 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1bDo-0004Q1-JF for emacs-devel@gnu.org; Tue, 13 Apr 2010 04:11:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1bDm-0001vx-MD for emacs-devel@gnu.org; Tue, 13 Apr 2010 04:11:48 -0400 Original-Received: from smtprelay-h22.telenor.se ([195.54.99.197]:57277) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1ZdC-0000yb-Dm for emacs-devel@gnu.org; Tue, 13 Apr 2010 02:29:56 -0400 Original-Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id B8325EB53B for ; Tue, 13 Apr 2010 08:29:52 +0200 (CEST) X-SENDER-IP: [85.225.45.110] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au5CAEesw0tV4S1uPGdsb2JhbACHZZNhDAEBAQE1Lbo1hQwE X-IronPort-AV: E=Sophos;i="4.52,195,1270418400"; d="scan'208";a="506982964" Original-Received: from c-6e2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.110]) by ipb3.telenor.se with ESMTP; 13 Apr 2010 08:29:44 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id E484E7FA01A; Tue, 13 Apr 2010 08:29:43 +0200 (CEST) User-Agent: Thunderbird 2.0.0.24 (X11/20100411) In-Reply-To: <87d3y43wg7.fsf@uwakimon.sk.tsukuba.ac.jp> 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:123562 Archived-At: Stephen J. Turnbull skrev: > So far the only interesting argument I've seen against a general > callback implementation supporting any and all of the above, as well > as others my marginal imagination is insufficient to contain, is Jan's > claim that it results in flashing and a race condition. > There is flashing just by restoring window configurations as well, we really should have double buffering here. I've introduced the purposed zero sized subwidgets to tabs so the tabs don't switch content at once. This reduces flashing, but just to the same level as restoring window configurations. > In the ten years that we've had the tab control, I can't recall a bug > that was diagnosed as a race condition in the tab control. So maybe > that's a problem for GTK builds, but GTK getting in the way of the > app's design is nothing new. The race condition has more to do with Emacs event design (i.e. content change => Gtk callback => elisp event => elisp function => switch windows => redisplay). I removed that by saving and restoring window configurations in the Gtk callback and cut out the whole elisp part. The zero sized subwidgets will fix that also, as content change no longer happens. Jan D.