Tabs (Re: [IMPORTANT] Proposed Goals for next release - 1.3.6 or 1.5.0?)

[GSR - FR <famrom infernal-iceberg com>]

Hi,
janek_listy wp pl (2008-12-17 at 2138.40 +0100):
> Christopher Bratusek said:     (by the date of Wed, 17 Dec 2008 22:07:46 +0100)
> 
> 
> > And your vote for the next version? 1.3.6 or 1.5.0?
> 
> For me, tabbed windowing is a feature which makes it worthy to
> increment version into 1.5.0

I agree it makes a worthy point, but it seems a bit stalled and the
current way looks a bit forced. I have been thinking about the issue a
bit since last time, looked some time ago at the current tab jl files.
This are my current notes:

Lets assumes tabs are:

- they form groups of windows, from (multiple / different) X clients.

- each tab group shares position, size, depth, theme, etc while being
  part of a group.

- user will be able to add or release from a tab group.

- functions will allow extra actions not aplicable to stand alone
  windows, like add, release, tab group cycle...

- theme will be in charge of displaying all required controls, so look
  matches.

Then:

- tab groups are stored as a list of lists, with some helper functions
  to quickly locate other members, add, remove, etc. Or some other
  struct that is fast and allows single grouping (no window into
  multiple groups).

- one window is visible using plain frame, the rest are hidden in
  similar fashion to how shaded works using frame "none" instead of
  "title".

- themes provide one of "nothing" (so all work... just all via bind
  keys), tab button for menu (as shade button example in texinfo, but
  this one would be used to get a menu of members) or tab buttons as
  multiple elements. This way each theme can do whatever it wants in
  visual style (the tabs.jl I got used fixed area), different size for
  buttons, vertical position. Title button can appear (and thus work)
  as a focused tab button.

  Clicked tab button has text string, which can be used to locate the
  window to show. Maybe extra property is needed just for this task (I
  have doubts as this could be tricky with multiple windows using
  exact same name) or lots of keymaps that just have "focus this other
  window" cmd (I hope that does not polute keymaps and they can be
  created in place for each part). Someone posted about focus changing
  requiring a timer based approach, tho.

  Another option is the unfocused tabs appears as a big part, and
  querying the pointer is used for choosing which window to focus, but
  that sounds less flexible (each theme has to provide a function to
  figure the zones and it would mean single part or get even more
  complex).

- changing focused window updates the position, etc for new so it
  matches the old and shows it, hidding the previous. Depth could be
  handle via stack-window-above so it is just placed on top of the
  prev and soon to be hidden one.

And now I see that note about generic window groups with a single
frame (ide-style? macosx "top glued" save dialogs? macosx side panes?
all?), so the questions are: Is the above text a good approach for
tabs per se? Would a more generic one be better (so ide-style and tabs
become submodes)? The bu report comments suggest it can be tricky,
while tabs alone are just a game of hiding and showing if implemented
as above.

GSR