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 21:07:58 +0200 Message-ID: <4BC0CC8E.9080608@swipnet.se> References: <30298845.656931270806476838.JavaMail.www@wwinf4631> <4BBF0C6C.7000909@swipnet.se> <4BC011F5.9010505@swipnet.se> <4BC0A2EC.3060807@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 1270926686 392 80.91.229.12 (10 Apr 2010 19:11:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Apr 2010 19:11:26 +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 21:11:24 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 1O0g5T-0006Pr-L2 for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 21:11:23 +0200 Original-Received: from localhost ([127.0.0.1]:56132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0g5S-0004se-RU for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 15:11:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0g2G-0002sQ-K0 for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:08:04 -0400 Original-Received: from [140.186.70.92] (port=55125 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0g2F-0002rL-5k for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:08:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0g2D-0004jM-Je for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:08:03 -0400 Original-Received: from smtprelay-h11.telenor.se ([62.127.194.4]:45552) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0g2D-0004ir-70 for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:08:01 -0400 Original-Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h11.telenor.se (Postfix) with ESMTP id 8389BDC80 for ; Sat, 10 Apr 2010 21:08:00 +0200 (CEST) X-SENDER-IP: [85.225.45.110] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq06ADNpwEtV4S1uPGdsb2JhbACHZJNhDAEBAQE1Lbk7hQwE X-IronPort-AV: E=Sophos;i="4.52,182,1270418400"; d="scan'208";a="61965593" 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 21:07:59 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id 2B0DD7FA01A; Sat, 10 Apr 2010 21:07:58 +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:123455 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. > > Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h, > then resize some windows, then select the "toto.c" tab and it will > switch the buffer to toto.c without reverting the window sizes. > Ok, that might be useful. >>> 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. > > It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the > Music Player Daemon. So think of it as switch between different > selections in Rhythmbox's browser. Well, I don't use Rhythmbox either, so ... :-) > >>>> 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. > > I think we need to define "tab" here. For me a "tab" is a little > rectangle on the screen with a label. The actions on this tab are > usually linked to switching the content of an X window that's > drawn underneath. >>>From what you write I get the impression that your notion of a "tab" > includes not just the tab itself but also the window underneath. It is not my notion, it is Gtk+. > >> Depending on what was drawn in that widget previously, something else >> is shown than what was shown in the old wiindows before. > > If I understand correctly, that means that Gtk tabs have a built-in > semantics of "switch the window underneath the tabbar". > That's obviously too restrictive for the kinds of use cases I suggest, > so we'd have to hack around it, e.g. by creating a dummy 0-pixel high > X-window where Gtk can "switch tabs" at its heart content without > bothering us. I'm looking into that now. There is that damned border though... Jan D.