From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Gtk tabs in emacs, new branch. Date: Sun, 11 Apr 2010 16:28:50 +0100 Message-ID: <4BC1EAB2.6080900@harpegolden.net> References: <30298845.656931270806476838.JavaMail.www@wwinf4631> <4BBF0C6C.7000909@swipnet.se> <87ljcwaxfv.fsf@mail.jurta.org> <4BC016DA.60400@swipnet.se> <87d3y63gzt.fsf@mail.jurta.org> 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 1270999854 32253 80.91.229.12 (11 Apr 2010 15:30:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 15:30:54 +0000 (UTC) Cc: =?ISO-8859-1?Q?Jan_Dj=E4rv?= , "Emacs Dev \[emacs-devel\]" To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 11 17:30:53 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 1O0z7c-0002Xf-K5 for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 17:30:52 +0200 Original-Received: from localhost ([127.0.0.1]:49149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0z7b-0008GP-Rw for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 11:30:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0z5n-0007hN-PP for emacs-devel@gnu.org; Sun, 11 Apr 2010 11:28:59 -0400 Original-Received: from [140.186.70.92] (port=49153 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0z5m-0007gx-2j for emacs-devel@gnu.org; Sun, 11 Apr 2010 11:28:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0z5h-0001lV-Nl for emacs-devel@gnu.org; Sun, 11 Apr 2010 11:28:56 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:60426) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0z5h-0001lK-J0 for emacs-devel@gnu.org; Sun, 11 Apr 2010 11:28:53 -0400 Original-Received: from [87.198.54.140] (87-198-54-140.ptr.magnet.ie [87.198.54.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 68E449582; Sun, 11 Apr 2010 16:28:52 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) In-Reply-To: <87d3y63gzt.fsf@mail.jurta.org> 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:123478 Archived-At: Juri Linkov wrote: >>> I think the `gtk-tabs' branch should do something like that. >> Something like what? Switching window configurations or used for anything? > > I see two separate tasks here: > > 1. Using Gtk-tabs at the top the the frame to switch window configurations. > This is like tabs in web browsers and "perspectives" in Eclipse. > > 2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs. > This is like tabs above a subwindow in Eclipse that would allow > Emacs packages to create tabs above the window along with the header line. > Mode specific actions to tabs? I do get a certain impression that people who propose non-switch-pane-of-content uses for tabs are really looking for just more toolbars - rows of buttons. NOT tabs, which have specific ui affordances towards being "for" managing stacked panes of content, and often the same panes that may also be tiled (like emacs). And emacs has panes of content - windows... Cnsider the GIMP's tab docks - You can have a layers window, channels window and paths window (not the gimp terminology, they actually call each window a "tab") docked into a tab group or a brushes window, layers window and palette window. Or whatever. And rearrange them as you see fit. [What's more, in contrast to ancient and quirky motif notebooks which used tabs like the index cards in a rolodex, not necessarily attached to every pane of content in the stack, in a splendid example of overly literal real-world analogy, modern guis have pretty much settled on that being 1:1] Having said that, it would be possible to have both - my interwindow tabs as an interface for managing the window split 3rd axis, and further intrawindow tabs associated with a single window like a modeline, that could either be mode-specific and presumably handled with callbacks to the mode code, or for what I strongly suspect people given such a callback api would end up wheel-reinventing repeatedly: a kind of narrowing the mode could initiate, with sections of the whole buffer narrowed to the different tabs.