From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Gtk tabs in emacs, new branch. Date: Tue, 13 Apr 2010 09:15:45 -0700 Message-ID: <130DBB4176F64517BC3B37A475FD979B@us.oracle.com> References: <30298845.656931270806476838.JavaMail.www@wwinf4631><4BBF0C6C.7000909@swipnet.se><4BC011F5.9010505@swipnet.se><87tyri429l.fsf@uwakimon.sk.tsukuba.ac.jp><203268BCBA374E2CA3097FC84362424A@us.oracle.com><87wrwcfadg.fsf@mail.jurta.org> <87633w3sbh.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1271175699 8531 80.91.229.12 (13 Apr 2010 16:21:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 16:21:39 +0000 (UTC) Cc: 'Juri Linkov' , =?iso-8859-1?Q?'Jan_Dj=E4rv'?= , 'Stefan Monnier' , "'Emacs Dev \[emacs-devel\]'" To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 18:21:37 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 1O1irm-0001qb-7M for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 18:21:35 +0200 Original-Received: from localhost ([127.0.0.1]:33424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1irl-0005yp-BG for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 12:21:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1in2-0003B1-Po for emacs-devel@gnu.org; Tue, 13 Apr 2010 12:16:41 -0400 Original-Received: from [140.186.70.92] (port=43829 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1imw-0002zA-NH for emacs-devel@gnu.org; Tue, 13 Apr 2010 12:16:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1imZ-000074-Tz for emacs-devel@gnu.org; Tue, 13 Apr 2010 12:16:17 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:59189) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1imZ-00006Y-Mf for emacs-devel@gnu.org; Tue, 13 Apr 2010 12:16:11 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3DGG8gc005163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Apr 2010 16:16:09 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CNoARG012539; Tue, 13 Apr 2010 16:16:06 GMT Original-Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 157036451271175346; Tue, 13 Apr 2010 09:15:46 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Apr 2010 09:15:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87633w3sbh.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: Acrav5P+B7ivpdrWT72jdg9BWhCYdAAUe3Bw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BC498C7.0193:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:123580 Archived-At: > > I want a tab to be able to invoke any function whatever. > > While perhaps sufficient generality may require that ability, remember > that tabs as a metaphor are *not* just a contiguous row of buttons. > They are ordered, Yes. > and they "do the same thing" (but to different objects). How so? > So I would refine "any function whatever" so that each tab control > should have a *single* callback function, which takes maybe three > arguments: the individual tab object itself (perhaps represented as an > integer but better a symbol, I think, because then you could put > properties on it), a per-tab user-defined datum (any Lisp object the > application wants to hang on the individual tab), and perhaps another > user-defined datum for the whole tab control. (If you do need the > generality of function-per-tab, you could always have the tab-control- > wide function dispatch to per-tab functions stored in the per-tab user > datum. This would *remind* you that all tabs in a group "should" do > the same thing, but it wouldn't *enforce* it.) > > Either the per-tab datum or the whole-tab datum or both could be > subsumed by properties on the tab object, I guess. > > WDYT? I'm not sure I understand all you wrote. I'm quite ignorant about much of this, especially the how-to. My only ideas about this so far pertain to what tabs might do and what kind of info might therefore be associated with them. It's not clear to me, for example, what you mean by tabs (necessarily) doing the same thing to different objects. It's also not clear why there should be a single callback function, or what you mean by "the individual tab object" (what is it for?) or "the whole tab control". What's the difference between the tab and the whole tab? Perhaps an example to illustrate, or define the terms a bit? You click a given tab, and something happens. The tab has a name. The GUI/tab control looks up the name to find the corresponding something-to-happen and then effects it. Perhaps this is what you mean by "dispatch to per-tab functions stored in the per-tab user datum" - dunno. Yes, there is then some question about where to display things, if something gets displayed as part of the something-to-happen. For example, if the action involves visiting a buffer then you'd probably want that buffer to appear in a window associated with the tab. I've said nothing about this display part of things. It is questions about display that distinguish tabs from tool-bar buttons, no doubt. Yes, there is a natural association between a tab and a window. That doesn't mean that every tab need display exactly one window. But yes, clicking a tab typically results in the window below it showing something that is associated with the tab. Apart from the GUI aspects (including the display question), I see a tab bar as an ordered sequence of named (Lisp) thingies that you can select (e.g. by clicking). I therefore think of an alist, where the keys are the tab names and the values are arbitrary Lisp objects. That brings to mind an Emacs menu, where menu items are essentially alist entries (item-name/key and command/value). Perhaps that's what Stefan had in mind when he spoke of keymaps - dunno. To me, it also brings to mind Emacs bookmarks, which is one reason I mentioned them. A bookmark is just a cons (NAME . VALUE), where NAME is a string. It's true that VALUE has an expected form to some extent for bookmarks, but really it can be quite general. Predefined bookmark entries (in VALUE) such as `filename' and `position' need not be mandatory. One important thing that VALUE can include is a handler, which determines what happens when the bookmark is invoked. Unlike the case for menus, the structure of the VALUE part of a bookmark is quite flexible and open (e.g. to user definition), and the associated action (handler) need not be an Emacs command (`interactive'). A default handler applies, if none is present explicitly. To me, the bookmark model is quite general and corresponds conceptually to a tab: a named Lisp value that can represent some action to be performed when the tab is selected. How a tab gets selected and what gets displayed (and how) are questions that I haven't tried to address. I mentioned that I would also like to be able to perform certain operations on the tabs of a given tab bar that are similar to operations that I perform on a list of bookmarks: (1) sort the tabs in various ways, based on both NAME and VALUE, (2) mark the tabs and then perform operations on the marked tabs, (3) hide certain tabs (e.g. those marked), (4) show a set of tabs that might not already have been shown and then hidden (e.g. to "open" a project that involves multiple tabs). And so on. And I mentioned that (bookmark+) bookmarks can be tagged (del.icio.us-style), which would mean that tabs would be tagged, so you could easily manipulate sets of tabs - e.g. all the tabs that correspond to a particular project or query. IOW, individual tabs can be selected, yes, but code (hence users) should also be able to act on sets of tabs in various ways. I'm thinking about tabs from a user point of view. Not just a user who clicks a tab but also a user who might write some Lisp code to associate with a given tab, to affect what happens when it is clicked. Suppose, for illustration, that it would be sufficient to associate a given existing bookmark with a given tab. The displayed tab name would be the bookmark name. When you click the tab, the bookmark handler would be invoked, and whatever destination is involved (if any) would be displayed (e.g. in the tab's window). When you invoke a bookmark normally (e.g. with `bookmark-jump') the handler is invoked, and the handler typically includes a display function (e.g. `pop-to-buffer'). What I envision for tabs is using the handler without its display part. That is, suppress the display part of the bookmark handler and substitute for it whatever display behavior we will define for tabs. The bookmark handler would need to still visit the proper buffer (if it visits a buffer), but not display that buffer. It is the tab code that would be in charge of display, perhaps basing its behavior on the particular display function defined for the handler. I haven't addressed the tab-display question, and I probably don't have much to say about it. What I'm concerned about is having the generality of associating an arbitrary handler with each tab. And it would be very nice if we could leverage the existing format of bookmarks in this regard - that is, be able to handle existing bookmarks out of the box.