[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Gtk tabs in emacs, new branch.
From: |
Stephen J. Turnbull |
Subject: |
RE: Gtk tabs in emacs, new branch. |
Date: |
Wed, 14 Apr 2010 19:30:48 +0900 |
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)))
- Re: Gtk tabs in emacs, new branch., (continued)
- Re: Gtk tabs in emacs, new branch., René Kyllingstad, 2010/04/13
- Re: Gtk tabs in emacs, new branch., David De La Harpe Golden, 2010/04/10
- Re: Gtk tabs in emacs, new branch., Stephen J. Turnbull, 2010/04/11
- RE: Gtk tabs in emacs, new branch., Drew Adams, 2010/04/11
- Re: Gtk tabs in emacs, new branch., Juri Linkov, 2010/04/12
- RE: Gtk tabs in emacs, new branch., Drew Adams, 2010/04/12
- RE: Gtk tabs in emacs, new branch., Stephen J. Turnbull, 2010/04/13
- RE: Gtk tabs in emacs, new branch., Drew Adams, 2010/04/13
- RE: Gtk tabs in emacs, new branch.,
Stephen J. Turnbull <=
Re: Gtk tabs in emacs, new branch., A. Soare, 2010/04/09
Re: Gtk tabs in emacs, new branch., A. Soare, 2010/04/10
RE: Gtk tabs in emacs, new branch., grischka, 2010/04/13
- Side windows (was: Gtk tabs in emacs, new branch.), Juri Linkov, 2010/04/13
- Re: Side windows (was: Gtk tabs in emacs, new branch.), Eli Zaretskii, 2010/04/13
- Re: Side windows, Jason Rumney, 2010/04/14
- Re: Side windows, Juri Linkov, 2010/04/14
- Re: Side windows, Eli Zaretskii, 2010/04/14
- Re: Side windows, Juri Linkov, 2010/04/14
- Re: Side windows, Eli Zaretskii, 2010/04/14