Hi, dear tab developers. On Tue, 3 Mar 2009 22:13:48 +0100, GSR - FR wrote: > [email protected] (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)
