Tabs (Re: [IMPORTANT] Proposed Goals for next release - 1.3.6 or 1.5.0?)
- From: GSR - FR <famrom infernal-iceberg com>
- To: sawfish-list gnome org
- Subject: Tabs (Re: [IMPORTANT] Proposed Goals for next release - 1.3.6 or 1.5.0?)
- Date: Fri, 19 Dec 2008 19:14:28 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]