Re: Tabs, the notes


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

GSR - FR wrote:

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

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.


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]