From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stephen J. Turnbull'" <stephen@xemacs.org>
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: Tue, 13 Apr 2010 09:15:45 -0700 [thread overview]
Message-ID: <130DBB4176F64517BC3B37A475FD979B@us.oracle.com> (raw)
In-Reply-To: <87633w3sbh.fsf@uwakimon.sk.tsukuba.ac.jp>
> > 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.
next prev parent reply other threads:[~2010-04-13 16:15 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 [this message]
2010-04-14 10:30 ` Stephen J. Turnbull
-- 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=130DBB4176F64517BC3B37A475FD979B@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=jan.h.d@swipnet.se \
--cc=juri@jurta.org \
--cc=monnier@iro.umontreal.ca \
--cc=stephen@xemacs.org \
/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.