RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> 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).

That tabs can be naturally used for managing stacked panes of content does not
mean that they should only be used for that. I see no contradiction between tabs
as "buttons" and tabs as selectors for stacked panes.

The former is more general, that's all. However, I would not like to see the
current Emacs tool-bar and its buttons as the model for Emacs tabs. We can do a
lot better. (See my other mail on this today.)

I agree with what Stefan said:

SM> Indeed.  The current tool-bar has some serious limitations
SM> for tabs:
SM> - the appearance isn't right.
SM> - no text.
SM> - can't have two "tool bars".
SM> 
SM> If we could have more flexible tool-bars (more control over the
SM> appearance and content, more control over the possible key-bindings,
SM> ...) and if we could have more of them and placed differently
SM> (e.g. anywhere in the window tree), then that would subsume 
SM> the need for tabs and the neds for extra header-lines.

> And emacs has panes of content - windows...

Well, "pane" kinda implies "window", so it's hard to argue with that. But Emacs
has lots of _sets_ of content (visible or not), and letting a tab select for
such a set of content is part of what I would like to see. I do not want to see
Emacs tabs being only about window selection (whether individual windows or
window configs).