Re: Tabs, the notes

[Rodrigo Amestica <ramestica nrao edu>]

Hi GSR,

many thanks for collecting these ideas and information. Nothing better than 
having a big picture for starting a discussion.

GSR - FR wrote:
> Hi:
>
> The notes I have been collecting about tabs for the past months, what
> is needed and how it can be done.
>
> - Objective:
>
> Group multiple windows into something that looks like a single window
> (a binder window, to keep with the mental image of papers, tabs, etc),
> and make it behave as such single window as much as possible. Make
> some things optional, but do not force users to have to change
> commands so this new binder behaves as normal window.
>
> - Details:
>
> Windows tabbed into a group must share position, depth, size, state,
> workspaces, and respond to normal commands like raise, lower, move,
> etc. Or simpler words, become the same window from user point of view.

Are standalone windows members of a single window tab group? I still think that 
a tab should exist only when 2 or more windows are tabbed together. My 
impression is that this would alleviate the logic in the windows manager itself 
and themes.

In any case, at the moment 2 windows are tabbed together one should act as the 
target in the sense that are its current properties (position, depth, size, 
etc.) the ones that will prevail after the tabbing is completed and both windows 
looks now like one single window. This sounds like common sense but I suppose 
that is better to well define it before extra behavior starts to develop. 
Tabbing has a direction.

> Remember some settings beforing tabbing could be desireable. Previous
> theme, frame type, maybe more, but size, etc do not make much sense.
>
> It should allow matching windows at some point, so they can start
> grouped, thus binders must have some ID, like a number. Current system
> has no IDs, groups can provide hints about how to do it.
>
> Reduce events on other tabs... thus hide their windows, like with
> shaded windows. Only active window will be shown, and be in charge of
> painting the representation for the rest of its group by mean of extra
> parts with special keymaps that focus other windows when clicked.

My impression is that the current implementation suffers of some display 
artifacts. For example, when you move a tabbed group you get the impression that 
indeed you are moving a very heavy thing, like if the position of every window 
in the group is updated one after the other. It should  not be like that. It is 
only the top window the one that is displayed together with the tab's 
decoration, the other windows should remain effectively dormant/hidden.

> Position, depth, etc can be propagated from the visible to the rest
> after each command (this can be queued with a timer to avoid constant
> useless updates like changing 2 workspaces in 0.5 sec) or only to a
> different tab when it is focused (maybe trickier, maybe visual
> artifacts).

My naive understanding is that propagating shared attributes to hidden windows 
is just a matter of coping their values to lisp variables, without real display 
updates. Those windows are effectively hidden. Therefore, I do not see a cause 
of concern for useless updates. Perhaps, there is something of sawfish I'm not 
understanding here.

> Add extra commands to select prev and next tabs, as well as swap with
> prev and next for reorganizing. Probably also binder cycle mode.
> Option to remove hidden members of a binder from other cycle commands.
>
> Focus other windows when tab parts are clicked, and on mouse hover tab
> as option. Current system would require constant monitoring of motion
> events while in "tab zone" to compute when a "button" is entered for
> the hover. Using separate parts should solve that by using the same
> hooks used for tooltips.
>
> Freedom to represent the system (drop down button for menu, tab row,
> tab column, multiple tab rows, etc). So put theme in charge like with
> shaded windows or even title bars, thus provide new parts to
> standarize the basics for all themes that want to comply.
>
> Ship one theme that can be used as fallback and example for other
> themes that want support tabs in advanced way ("lots of buttons").
>
> Drag and drop would be nice at some point... but no idea, sorry (no
> support at all in Sawfish, probably some kind of keymap event(s) will
> be needed). It would be nice for reorgs, tab migration from one binder
> to another and even creation.
>
> Use marks.jl to create binders for now.
>
> - Side projects:
>
> Nicks, so tabs can use nickname instead of title (theme will decide
> what to show in the part). There are different scripts that would also
> benefit, like those that focus window based in names.

What do you mean by a side project? For me is a very intrinsic feature of 
tabbing the ability to name them as I please while keeping their titles 
untouched. Leaving this feature open to be implemented by themes as they please 
will translate into different behavior at the moment one changes across 
different themes. Not very desirable from my point of view. I do not see a big 
issue on adding the nick name variable and setter and getter functions at the 
base implementation of the tabs.

Rodrigo

> I hope I did not forget to note down anything, they have been multiple
> non continous threads about the topic. Time to review so we can
> proceed.
>
> GSR
>