Hi, [email protected] (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
