From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: "'Juri Linkov'" <juri@jurta.org>,
"Jan Djärv" <jan.h.d@swipnet.se>,
"'Stefan Monnier'" <monnier@iro.umontreal.ca>,
"'Emacs Dev [emacs-devel]'" <emacs-devel@gnu.org>
Subject: RE: Gtk tabs in emacs, new branch.
Date: Wed, 14 Apr 2010 19:30:48 +0900 [thread overview]
Message-ID: <87wrwa2unb.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <130DBB4176F64517BC3B37A475FD979B@us.oracle.com>
Drew Adams writes:
> > > 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?
>
> It's not clear to me, for example, what you mean by tabs
> (necessarily) doing the same thing to different objects.
Those are scare quotes. I wouldn't have quoted if I was able to
*define* "do the same thing"!
Let me start with some definitions: A *tab bar* (what in my previous
post I called a "tab control") is a widget which contains several
*tabs*, and (usually) a *pane* in which some kind of content is
displayed. (In the implementation discussed below I assume the pane
is an Emacs window, but that need not be true.) *Tabs* are clickable
buttons, but they only appear as part of a tab bar. Within a tab bar,
there is a distinguished *top tab*. In cases where the tabs control a
specific pane in the display, the top tab is the one associated with
the currently visible content. Tabs may also be ordered from left to
right (assuming a horizontal orientation to avoid overloading the word
"top"). The top tab need not be leftmost, but is always visible and
visually distinguishable (unless the user has selected a weird face).
Clicking on an individual tab will cause some action to occur, usually
reflected by a change in the appearance of the content. It always
causes the clicked tab to become the top 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's very adequately represented visually by a toolbar. Why do you
want to duplicate the functionality of toolbars in tab bars?
> 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.
"All hope abandon ye who enter here." That's a toolbar. (But I
repeat myself. "What I say three times is true." Wait for it!) If
toolbars have the restrictions that menus do (which are hardly
restrictive, actually; anything that can take a function symbol as a
value can implement arbitrary behavior), you can bet that tabs will
suffer the same restrictions.
> 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.
Sure. A tab bar will surely be visible to Lisp as a sequence of some
kind, and accessed by a variable. I don't see why any of the things
you describe above will be prevented by any particular implementation
of the action invoked by a tab.
> What I'm concerned about is having the generality of associating an
> arbitrary handler with each tab.
That's a toolbar. Q.E.D.
If you really really need both the visual cues provided by a tab bar,
and an arbitrary handler for each tab, then (using your alist
representation, which is probably as good as any other) you could have
(defun my-tab-handler (tab ignored-datum) ; all tab handlers take 2 args
(let ((name (nth 0 tab))
(handler (nth 1 tab))
(tab-data (nthcdr 2 tab)))
(message "handling tab '%s'" name)
(apply handler tab-data)))
as the handler, and the tab bar would be represented in Lisp as
something like
("This establishment serves only 17-year-old Scottish tabs." ; name/doc
my-tab-handler
(random) ; random tab-bar-wide datum, not used by my-tab-handler
("One name" handler-1 various data)
("Another name" handler-2 some information)
;; etc etc
)
But in most cases, having tab-specific handlers is probably a bad fit
for the tab metaphor. Use a toolbar. If your problem with that is
that Emacs toolbars are too restrictive, then fix the restrictions.
OTOH, a typical over-simplified buffer tab bar would be handled by
(defun buffer-tab-handler (tab tab-controlled-window)
(with-selected-window tab-controlled-window
(switch-to-buffer (second tab))))
(defun make-buffer-tabs (how-many controlled-window)
(let ((buffers (buffer-list))
(tabs '(controlled-window buffer-tab-handler "buffer tab")))
(while (and buffers (> how-many 0))
(setq tabs (cons (list (buffer-name (car buffers)) (car buffers))
tabs))
(setq how-many (1- how-many))
(setq buffers (cdr buffers)))
(reverse tabs)))
next prev parent reply other threads:[~2010-04-14 10:30 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 9:47 Gtk tabs in emacs, new branch A. Soare
2010-04-09 11:15 ` Jan D.
2010-04-10 1:22 ` Stefan Monnier
2010-04-10 1:36 ` Juri Linkov
2010-04-10 6:12 ` Jan Djärv
2010-04-11 1:16 ` Juri Linkov
2010-04-11 12:50 ` Tobias C. Rittweiler
2010-04-11 15:40 ` David De La Harpe Golden
2010-04-11 15:28 ` David De La Harpe Golden
2010-04-11 16:05 ` Stefan Monnier
2010-04-11 18:32 ` Jan Djärv
2010-04-12 23:47 ` Juri Linkov
2010-04-13 3:50 ` Stefan Monnier
2010-04-13 5:29 ` Juri Linkov
2010-04-13 13:05 ` Stefan Monnier
2010-04-13 23:34 ` Header windows (was: Gtk tabs in emacs, new branch.) Juri Linkov
2010-04-14 5:03 ` Gtk tabs in emacs, new branch Richard Stallman
2010-04-14 14:30 ` Stefan Monnier
2010-04-13 6:53 ` Stephen J. Turnbull
2010-04-13 12:28 ` Stefan Monnier
2010-04-13 5:53 ` Jan Djärv
2010-04-13 12:30 ` Stefan Monnier
2010-04-13 20:54 ` Jan Djärv
2010-04-21 16:58 ` Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.) Jan Djärv
2010-04-23 8:35 ` Juri Linkov
2010-04-23 9:33 ` Jan D.
2010-04-23 16:46 ` Juri Linkov
2010-04-23 17:47 ` Jan Djärv
2010-04-11 18:09 ` Gtk tabs in emacs, new branch Drew Adams
2010-04-12 23:45 ` Juri Linkov
2010-04-13 2:42 ` Stephen J. Turnbull
2010-04-13 6:29 ` Jan Djärv
2010-04-13 17:59 ` Eli Zaretskii
2010-04-13 18:15 ` Jan Djärv
2010-04-13 18:44 ` Eli Zaretskii
2010-04-10 1:47 ` Lennart Borgman
2010-04-10 2:19 ` Juri Linkov
2010-04-10 6:15 ` Jan Djärv
2010-04-10 9:14 ` Lennart Borgman
2010-04-10 9:46 ` joakim
2010-04-10 10:18 ` Lennart Borgman
2010-04-10 11:01 ` joakim
2010-04-10 12:38 ` Štěpán Němec
2010-04-10 14:58 ` Stefan Monnier
2010-04-10 10:58 ` Jan Djärv
2010-04-10 12:09 ` joakim
2010-04-11 1:18 ` Juri Linkov
2010-04-10 10:52 ` Jan Djärv
2010-04-10 5:51 ` Jan Djärv
2010-04-10 15:19 ` Stefan Monnier
2010-04-10 15:33 ` Chong Yidong
2010-04-10 18:51 ` Stefan Monnier
2010-04-10 16:10 ` Jan Djärv
2010-04-10 16:40 ` David De La Harpe Golden
2010-04-10 17:06 ` Jan Djärv
2010-04-10 16:42 ` Davis Herring
2010-04-10 17:11 ` Jan Djärv
2010-04-10 17:16 ` Davis Herring
2010-04-10 17:54 ` Jan Djärv
2010-04-10 18:44 ` David De La Harpe Golden
2010-04-10 19:14 ` Jan Djärv
2010-04-10 19:51 ` David De La Harpe Golden
2010-04-10 21:12 ` Stefan Monnier
2010-04-11 10:56 ` Jan Djärv
2010-04-11 15:09 ` Stefan Monnier
2010-04-10 19:00 ` Stefan Monnier
2010-04-10 19:07 ` Jan Djärv
2010-04-10 19:56 ` David De La Harpe Golden
2010-04-12 16:14 ` Jan Djärv
2010-04-12 19:18 ` Stefan Monnier
2010-04-12 20:22 ` Jan Djärv
2010-04-12 21:02 ` Stefan Monnier
2010-04-13 15:08 ` René Kyllingstad
2010-04-10 16:06 ` David De La Harpe Golden
2010-04-11 12:11 ` Stephen J. Turnbull
2010-04-11 18:09 ` Drew Adams
2010-04-12 23:49 ` Juri Linkov
2010-04-13 2:58 ` Drew Adams
2010-04-13 4:11 ` Stephen J. Turnbull
2010-04-13 16:15 ` Drew Adams
2010-04-14 10:30 ` Stephen J. Turnbull [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-04-13 19:53 grischka
2010-04-10 17:33 A. Soare
2010-04-09 13:33 A. Soare
2010-04-01 16:52 Angelo Graziosi
2010-04-01 17:45 ` Jan Djärv
2010-04-01 18:03 ` Juri Linkov
2010-04-01 20:18 ` Jan Djärv
2010-04-02 7:10 ` Jan Djärv
2010-04-01 20:51 ` Angelo Graziosi
2010-04-02 6:49 ` Jan Djärv
2010-04-02 9:21 ` Angelo Graziosi
2010-04-02 2:06 ` Stephen J. Turnbull
2010-04-02 7:00 ` Jan Djärv
2010-04-02 6:53 ` Jan Djärv
2010-04-02 9:59 ` Angelo Graziosi
2010-04-02 15:10 ` Jan Djärv
2010-04-02 16:55 ` Angelo Graziosi
2010-04-05 8:50 ` Angelo Graziosi
2010-04-10 12:44 ` Jan Djärv
2010-04-10 17:34 ` Angelo Graziosi
2010-04-10 18:03 ` Jan Djärv
2010-04-10 22:09 ` Angelo Graziosi
2010-04-11 5:45 ` Jan Djärv
2010-04-11 8:16 ` Angelo Graziosi
2010-04-11 10:52 ` Jan Djärv
2010-04-11 17:28 ` Angelo Graziosi
2010-04-11 18:33 ` Jan Djärv
2010-04-21 8:55 ` Juri Linkov
2010-04-21 9:46 ` David Kastrup
2010-04-21 15:43 ` Juri Linkov
[not found] ` <jwv633k4rn2.fsf-monnier+emacs@gnu.org>
2010-04-22 8:16 ` Juri Linkov
2010-04-22 15:08 ` Jan Djärv
2010-04-23 8:33 ` Juri Linkov
2010-04-21 13:54 ` Angelo Graziosi
2010-04-21 15:45 ` Juri Linkov
2010-04-21 16:04 ` Jan Djärv
2010-04-22 8:14 ` Juri Linkov
2010-04-22 16:20 ` Juanma Barranquero
2010-04-24 18:45 ` Juri Linkov
2010-04-23 16:53 ` Drew Adams
2010-04-23 18:02 ` Juri Linkov
2010-04-23 18:28 ` Drew Adams
2010-04-24 9:17 ` Juri Linkov
2010-04-24 14:41 ` Drew Adams
2010-04-24 18:49 ` Juri Linkov
2010-04-24 19:24 ` Drew Adams
2010-04-25 5:36 ` Juri Linkov
2010-04-25 9:15 ` martin rudalics
2010-04-10 19:19 ` Stefan Monnier
2010-04-02 16:19 ` Uwe Siart
2010-04-02 18:31 ` Daniel Colascione
2010-04-02 20:38 ` Stefan Monnier
2010-04-03 6:29 ` Uwe Siart
2010-04-03 9:07 ` Uwe Siart
2010-04-02 6:53 ` Uwe Siart
2010-04-02 7:25 ` Jan Djärv
2010-04-04 11:01 ` Juri Linkov
2010-04-02 12:19 ` Stephen J. Turnbull
2010-04-01 13:07 Jan Djärv
2010-04-01 13:24 ` Leo
2010-04-01 18:02 ` Juri Linkov
2010-04-01 20:13 ` Jan Djärv
2010-04-09 23:27 ` Juri Linkov
2010-04-09 23:54 ` Drew Adams
2010-04-10 0:17 ` Juri Linkov
2010-04-10 2:56 ` YAMAMOTO Mitsuharu
2010-04-11 1:06 ` Juri Linkov
2010-04-01 18:50 ` Chong Yidong
2010-04-01 20:08 ` Jan Djärv
2010-04-01 20:09 ` Jan Djärv
2010-04-01 21:53 ` Stefan Monnier
2010-04-09 7:23 ` alin.s
2010-04-09 9:34 ` Jan D.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wrwa2unb.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=jan.h.d@swipnet.se \
--cc=juri@jurta.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.