From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Gtk tabs in emacs, new branch. Date: Sat, 10 Apr 2010 15:00:05 -0400 Message-ID: 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=us-ascii X-Trace: dough.gmane.org 1270926562 32455 80.91.229.12 (10 Apr 2010 19:09:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Apr 2010 19:09:22 +0000 (UTC) Cc: "Emacs Dev \[emacs-devel\]" To: Jan =?iso-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 10 21:09:20 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 1O0g3T-0005ei-Iy for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 21:09:19 +0200 Original-Received: from localhost ([127.0.0.1]:54939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0g3S-0003aw-TE for ged-emacs-devel@m.gmane.org; Sat, 10 Apr 2010 15:09:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0g17-00028Y-4F for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:06:53 -0400 Original-Received: from [140.186.70.92] (port=54740 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0g12-0001yk-7Z for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:06:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0fuX-000385-RB for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:00:11 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:50340 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0fuX-000381-P2 for emacs-devel@gnu.org; Sat, 10 Apr 2010 15:00:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZowEtMCqWu/2dsb2JhbACbRXK5SoUMBItG X-IronPort-AV: E=Sophos;i="4.52,182,1270440000"; d="scan'208";a="60599075" Original-Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 10 Apr 2010 15:00:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0B62E7F1B; Sat, 10 Apr 2010 15:00:05 -0400 (EDT) In-Reply-To: <4BC0A2EC.3060807@swipnet.se> ("Jan =?iso-8859-1?Q?Dj=E4rv=22?= =?iso-8859-1?Q?'s?= message of "Sat, 10 Apr 2010 18:10:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) 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:123453 Archived-At: >>> 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. >> 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. >>> 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. > 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. Stefan