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: Sat, 10 Apr 2010 18:10:20 +0200 Message-ID: <4BC0A2EC.3060807@swipnet.se> References: <30298845.656931270806476838.JavaMail.www@wwinf4631> <4BBF0C6C.7000909@swipnet.se> <4BC011F5.9010505@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: 7bit X-Trace: dough.gmane.org 1270916156 31697 80.91.229.12 (10 Apr 2010 16:15:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Apr 2010 16:15:56 +0000 (UTC) Cc: "Emacs Dev \[emacs-devel\]" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 10 18:15:55 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 1O0dLd-0003q5-BQ for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 18:15:53 +0200 Original-Received: from localhost ([127.0.0.1]:41670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0dLc-0006hN-Ix for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 12:15:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0dLY-0006h5-3C for emacs-devel@gnu.org; Sat, 10 Apr 2010 12:15:48 -0400 Original-Received: from [140.186.70.92] (port=40432 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0dIR-0005dA-7N for emacs-devel@gnu.org; Sat, 10 Apr 2010 12:12:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0dGJ-0005Sa-Vd for emacs-devel@gnu.org; Sat, 10 Apr 2010 12:10:25 -0400 Original-Received: from smtprelay-b12.telenor.se ([62.127.194.21]:39855) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0dGJ-0005SM-Hy for emacs-devel@gnu.org; Sat, 10 Apr 2010 12:10:23 -0400 Original-Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id E1CCFD614 for ; Sat, 10 Apr 2010 18:10:21 +0200 (CEST) X-SENDER-IP: [85.225.45.110] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuJDAC5AwEtV4S1uPGdsb2JhbACHZJNgDAEBAQE1LboKhQwE X-IronPort-AV: E=Sophos;i="4.52,182,1270418400"; d="scan'208";a="61941960" Original-Received: from c-6e2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.110]) by ipb2.telenor.se with ESMTP; 10 Apr 2010 18:10:21 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id A2D7E7FA01A; Sat, 10 Apr 2010 18:10:20 +0200 (CEST) User-Agent: Thunderbird 2.0.0.24 (X11/20100317) 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:123442 Archived-At: Stefan Monnier skrev: > >> Are there any concrete examples of other uses? > > I can imagine switching the buffer of one of the windows (in an ECB-style > frame, for example). Isn't that a window configuration? I don't get it. > In mpc.el I could imagine using it to switch > between various selections. I don't know what mpc.el is, so the statements has no meaning. > >> But implementation for the primary use case (window configurations) >> should not have to suffer because of other uses. > > I still don't understand what kind of suffering you're referring to. > If you could describe more concretely (e.g. what kind of undesirable > user-behavior could happen in which case and why). The most obvious thing is flickering. When the user clicks on the tab Gtk+ switches tab, there is nothing you can do about that. Depending on what was drawn in that widget previously, something else is shown than what was shown in the old wiindows before. Then a callback is made. From here we can generate a Lisp event. Then the event goes to some elisp defun Then the window confiuration is extracted and applied. Then redisplay happens. This takes time and looks bad, unless you have a fast machine. You guys seem to think that tabs are just extra buttons to be pressed. In Gtk+ they are not. When you press on a tab an whole new Gtk widget (with associated X window) covering the whole frame is switched in. So the old contents is not shown. Doing window configuration switch as fast as we can helps, but it still isn't good. Workable, but not good. Add saving of the old configuration to this and more time passes before a redsplay. Then there is the race condition. Say we restore window configurations in elisp. But from the time Gtk+ does the switch until the new window configuration is in place, the old one is in Emacs idea of what is on the screen, but as I said earlier, it isn't what is really on screen. So redisplay may happen, based on the old configuration, making the flicker even more annoying. Jan D.