Re: Tabs

[Teika Kazura <teika lavabit com>]

Hi, dear tab developers.

On Tue, 3 Mar 2009 22:13:48 +0100, GSR - FR wrote:
> ramestica nrao edu (2009-03-03 at 1517.14 -0500):
> > GSR - FR wrote:
> >>
> >> And with stand alone windows? Never pick them if using it? Or taken as
> >> tab group with single member?
> > I am of the opinion that stand alone windows are not part of a tab group. 
> > This is my conceptual understanding/preference. What sense makes to let a 
> > theme to draw a tab above the title of the window standing alone? It 
> > looks odd.
> 
> I think we are having a communication issue. I read cycle-tabgroups
> (notice the s) as jump from one top level window to another, not
> inside a given tabgroup (which would be cycle-tabs or maybe
> cycle-tabgroup, without s). So I asked if the jumps should avoid those
> windows that are stand alone, as they are their own tabgroup, so to
> speak, of only one (non existant?) "tab".
> 
> OTOH, yes, stand alone windows should not show tabs. But if that is
> left to the themes, we do not have to pick a position. ;]

As for cycling and theme issue, GSR states correctly.  On the other
hand, on Tue, 03 Mar 2009 15:17:14 -0500, Rodrigo Amestica wrote:

> Tab groups should always be created on user demand and never by
> default, like single window tab groups would imply.

To be more precise, we should have, say 
(tab-groups-list &optional exclude-single-window-tab)
which returns the list of tab-groups. If 'exclude-single-window-tab'
is non-nil, then it excludes what Rodrigo shuns away. Sometimes a
single window should be considered as a tab-group, and sometimes not.
In fact, it depends on the circumstance, and we need both.

And cycling functions. I believe that it's better to merge
cycle-tabgroups to cycle-windows, and behavior is controlled by
(defvar cycle-inside-tabgroup nil)
This can be overrided temporarily with `let', so it is more flexible.

On Wed, 4 Mar 2009 12:52:46 +0100, Fernando wrote:
> Anyway, in my opinion the current tab implementation should be
> rewritten. Because the code is quite hacky and it's not well
> integrated with the rest of sawfish functionalities (for example, you
> can't use outlines other than "solid" when moving a tabgroup).
> 
> But before that, I believe that the code should be refactorized a bit.
> ...
Your analysis is superb. Please continue it.

On Tue, 3 Mar 2009 02:43:33 +0100, Fernando wrote:
> I've created right now a custom cycle-command for the "cycle-groups".
> It seems to work fine ^^

Yours is 'cycle-among-groups' so to say (don't have to change the
name). Do we also need 'cycle-inside-group'? It's easy to create
pieces of furniture, but I don't know like what the entire house
should be.

Regards,
Teika (Teika kazura)