Tabs bug: inactive tabs being overlapped

[Fernando-49]

On Wed, Aug 6, 2008 at 11:04 AM, Fernando <ferkiwi@...> wrote:

But that, I think, it's rather a bug, since inactive tabs should be in the same layer as the active. There are also other cases that make the inactive tabs be overlapped by other windows, all those things should be fixed somehow, and make all the tabs be drawn at the same time.
 

--
Fernando

This is what i mean: http://img398.imageshack.us/my.php?image=tabsbuguz0.png

The 2 windows at the top (absolute-darkness theme that I modified to have both tabs and title) show that when the window has both tab and title, the title of the focused tab overlaps the inactive tabs.

This maybe we can be seen as an intended behavior, but if inactive tabs were drawn to overlap the main window, then this will solve the problem of non-tabbed themes not showing any title when the tab feature is disabled (the themes could have both tabs and title).

In the 2 windows of the bottom of the screenshot (using Toyberg theme) another bug is shown that could maybe also be solved along with the previous one if the inactive tabs were drawn, somehow, right after the focused tab is drawn.

--
Fernando

[Fernando-49]

I had an idea regarding this problem..

Maybe it could be easier to handle if, instead of having "tab" "tab-l" and "tab-r" as a class inside the kind of frame...

 (frame
             ;;; borders, buttons, etc

               ;; tab left
               ((background . ,top-lefthollow-images)
            (top-edge . -19)
            (class . tab-l))

[Fernando-49]

Agh... sorry... the previous message was sent by error. I hit some wrong key.

This was what I was trying to say:


Maybe it could be easier to handle if, instead of having "tab" "tab-l" and "tab-r" as a class inside the kind of frame...

 (frame
             ;;; borders, buttons, etc

               ;; tab left
               ((background . ,top-lefthollow-images)
             (top-edge . -19)
            (class . tab-l))

[Fernando-49]

Agh... sorry... the previous message was sent by error. I hit some wrong key.

This was what I was trying to say:

Maybe it could be easier to handle if, instead of having "tab" "tab-l" and "tab-r" as a class inside the kind of frame...

"""""
 (frame
             ;;; borders, buttons, etc
               ;; tab-l
               ;; tab
               ;; tab-r
        )
(shaped-fame
               ;;;;
     )
(transient-frame
            ;;;;
  )
;;; etc
"""""

Instead of that, have a new object called "(tab-frame" or something like that

""""
(frame
    ;;;;)
(transient-frame
  ;;;;)
(tab-frame
  ;;;;)

Since it is a different frame it could be handled to be on top of the parent window (just like transient frames already do).. make it's dimensions and placing be related to the parent window... and skip pager/taskbar/cycling.
Also, this will improve extensibility and will allow each of the tabs to have their own close button.

Well.. I'm not really sure how good this idea is, but I want to share it to see the opinions.

[Scott Scriven]

* Fernando <ferkiwi@...> wrote:
> This is what i mean:
> http://img398.imageshack.us/my.php?image=tabsbuguz0.png

The lower-right windows show something which is very unlikely to
get fixed.  It's also not unique to sawfish.  Last time I tried
fluxbox, for example, it had the exact same issue.  The problem
(if it's a problem) is that windows in a tab group are not
necessarily contiguous in the stacking list.  Or, other windows
can be stacked between members of a tab group.

It generally causes no problems, other than looking a bit odd.

I suppose it's fixable, but would require one of two
things...

  - Put window group logic inside a lot of core functions, to
    make sure nothing can ever get stacked in the middle of a
    group.
  - Make large changes to how windows are drawn, so that the
    top-most window also draws the tabs for its siblings.

The top-left windows just show that you can't currently have both
a "title" area and a "tab" area in the same place.

I've been thinking about how to merge the tab area and title
area, but haven't found any solutions yet.  I think this is
something which needs to be fixed.


-- Scott

[Fernando-49]

On Wed, Aug 6, 2008 at 12:13 PM, Fernando wrote:

Since it is a different frame it could be handled to be on top of the parent window

Well.. not really a different frame since it's intended to display only a tab-bar.
But maybe then it would require building a whole new behaviour.
Urhhh.. maybe not a good idea after all.. I'm so sorry for the 4 useless mails...

--
Fernando

[Janek Kozicki]

Fernando said:     (by the date of Wed, 6 Aug 2008 12:35:48 +0200)

> But maybe then it would require building a whole new behaviour.
> Urhhh.. maybe not a good idea after all.. I'm so sorry for the 4 useless
> mails...

I think that we are much more happy by the fact that you are trying
tabs and thinking how to fix those issues, than unhappy about 4
emails ;-) If you have more ideas, don't hesitate to discuss them here!

And your ideas may give some inspiration to others about how to solve
the problem. So your emails were not useless at all :)

--
Janek Kozicki                                                         |

[Janek Kozicki]

Scott Scriven said:     (by the date of Wed, 6 Aug 2008 04:33:37 -0600)

> * Fernando <ferkiwi@...> wrote:
> > This is what i mean:
> > http://img398.imageshack.us/my.php?image=tabsbuguz0.png
>
> The problem (if it's a problem) is that windows in a tab group are not
> necessarily contiguous in the stacking list.  Or, other windows
> can be stacked between members of a tab group.

We need a single function which goes through all windows and sorts
them according to tab groups. This function can be bound to some
hotkey combination. And we could simply invoke it by keypress to
clear the odd looking view.

 
> It generally causes no problems, other than looking a bit odd.
>
> I suppose it's fixable, but would require one of two
> things...
>
>   - Put window group logic inside a lot of core functions, to
>     make sure nothing can ever get stacked in the middle of a
>     group.

afterwards, we will gradually add calls to this function from
different parts of sawfish code. (provided that it is fast enough...)


>   - Make large changes to how windows are drawn, so that the
>     top-most window also draws the tabs for its siblings.

sounds too difficult for me :)

--
Janek Kozicki                                                         |

[GSR - FR]

Hi,
janek_listy@... (2008-08-06 at 1808.46 +0200):
[...]
> We need a single function which goes through all windows and sorts
> them according to tab groups. This function can be bound to some
> hotkey combination. And we could simply invoke it by keypress to
> clear the odd looking view.

Better find a way that requires no resorting, specially manual
kind. ;]

[...]
> >   - Make large changes to how windows are drawn, so that the
> >     top-most window also draws the tabs for its siblings.
>
> sounds too difficult for me :)

I thought it was done in a way like that, at least that is how I would
implement tabs, hide all windows except front one, and make sure it
knows which tabgroup it belongs to (like workspaces, but only one
group allowed per window), so it can draw all subtitles. And a
tabgroup (what is the name for that? tabset?) would override all per
window things like size, position, depth in stack, shade, etc. Maybe I
should look what you are doing currently. :]

GSR
 

[Janek Kozicki]

Scott Scriven said: (by the date of Tue, 5 Aug 2008 21:18:09 -0600)

> How about just putting "-tabbed" on the end of each compatible
> theme name?  The get-S-tabbed theme is already this way, and I
> was thinking Toyberg should be Elberg-tabbed...

Scott, that's very reasonable, do that.


GSR - FR said:     (by the date of Wed, 6 Aug 2008 20:01:34 +0200)

> [...]
> > >   - Make large changes to how windows are drawn, so that the
> > >     top-most window also draws the tabs for its siblings.
> >
> > sounds too difficult for me :)
>
> I thought it was done in a way like that, at least that is how I would
> implement tabs, hide all windows except front one, and make sure it
> knows which tabgroup it belongs to (like workspaces, but only one
> group allowed per window), so it can draw all subtitles. And a
> tabgroup (what is the name for that? tabset?) would override all per
> window things like size, position, depth in stack, shade, etc.
>
> Maybe I should look what you are doing currently. :]

of course you should! :-D

Scott is currently trying to do the first commit of tabbed code. The
problem IIUC is that he needs to separate whole custom configuration
from what belongs to sawfish trunk.

--
Janek Kozicki                                                         |

[Fernando-49]

On Wed, Aug 6, 2008 at 12:33 PM, Scott Scriven <sawfish-list@...> wrote:

* Fernando <ferkiwi@...> wrote:

> This is what i mean:
> http://img398.imageshack.us/my.php?image=tabsbuguz0.png

I suppose it's fixable, but would require one of two
things...

 - Put window group logic inside a lot of core functions, to
   make sure nothing can ever get stacked in the middle of a
   group.
 - Make large changes to how windows are drawn, so that the
   top-most window also draws the tabs for its siblings.

I think I've fixed this issue.
But I'm unsure if it is a clean way. When one of the tabs get focused, the list of tabs will get raised, being the last one raised the one that got focused in the first place.
This way won't be windows getting in the middle of the tabs.
I'm not sure about it being clean because... maybe it is possible for the user to not want the window raised after getting focus (although I'm not so sure if this is really an option in sawfish..).

I've attached here my version of the tab script.
I've also modified some things.. I want to know your opinions:

I've changed "tabgroup.jl" to use the already existing "window groups" in sawfish. I renamed it to "grouplock.jl" since I think this could be an option independent of the displaying of tabs. In my opinion I think it's a good thing to merge both methods (sawfish window groups and tabs) because this way we can benefit of the already existent infrastructure of groups, reusing code and making it more maintainable.

I can't see how someone would ever want to use groups and tabs simultaneously and independently (since groups are just like tabs that are not attached to each other).  Also, there are some features of the groups that can be useful. Like being able to cycle them with a "cycle group" binding (this could make the feature usable even for non compatible themes, maybe just concat the titlebar with a string showing the number or title of the other tabs) ..or making a window match (e.g. making all terminals be tabbed/grouped right when they are created, just like fluxbox).

All of this can be able to work already in the version attached. However.. in the conversion to sawfish groups, I've failed to achieve one of the frame refresh during the transportation of tabs from one multitabbed window to another (you can check the problem in tab.jl line 147).

--
Fernando

[Fernando-49]

On Wed, Aug 6, 2008 at 10:39 PM, Fernando <ferkiwi@...> wrote:

 maybe it is possible for the user to not want the window raised after getting focus (although I'm not so sure if this is really an option in sawfish..).

Is there a after-raise-hook?
I was not able to find it.

[Janek Kozicki]

Fernando said:     (by the date of Wed, 6 Aug 2008 22:52:59 +0200)

>  maybe it is possible for the user to not want the window raised after
> getting focus (although I'm not so sure if this is really an option in
> sawfish..).

Actually this is how I'm using sawfish. I tend to type stuff in
unraised (partially obscured) windows, while looking at something
relevant which is on the top.

But, perhaps instead of raising to the top - all windows from tab
group could be raised to the level of currently focused window? That
way they won't get to the top, but only 'just below' that focused
window.

--
Janek Kozicki                                                         |

[Fernando-49]

On Wed, Aug 6, 2008 at 11:32 PM, Janek Kozicki  wrote:

Fernando said:     (by the date of Wed, 6 Aug 2008 22:52:59 +0200)

>  maybe it is possible for the user to not want the window raised after
> getting focus (although I'm not so sure if this is really an option in
> sawfish..).

Actually this is how I'm using sawfish. I tend to type stuff in
unraised (partially obscured) windows, while looking at something
relevant which is on the top.

But, perhaps instead of raising to the top - all windows from tab
group could be raised to the level of currently focused window? That
way they won't get to the top, but only 'just below' that focused
window.

--
Janek Kozicki                                                         |

I did some "grepping" and found out that there's in fact a function that already does exactly that! nice nice.

However.. I don't seem to make it work ..I'm not very sure why
Here is the script in case anyone wan't to check  out.
I added also a checkbox to activate/deactivate the tabs from showing... but in fact it wlould still require the script to be load. The only thing it does is set a fixed position for the tab like if there's always 1 tab.

http://www.uco.es/~q22cavaf/dev/tabgroups.tgz

[Scott Scriven]

* Fernando <ferkiwi@...> wrote:
> I think I've fixed this issue.

Nifty.

> maybe it is possible for the user to not want the window raised
> after getting focus (although I'm not so sure if this is really
> an option in sawfish..).

Yes, I use sawfish this way.  I don't want windows raised or
lowered unless I hit a raise/lower button.

However, I don't think I have any reason not to keep each group
stacked together.  If I raise one window in the group, I don't
mind the rest getting raised (so long as their relative order is
preserved).

The same might go for lowering, but it would remove one useful
side effect.  If I lower a window, the next most-recently-used
window in the group will become visible.  But if they're lowered
together, the entire group may disappear beneath some other
window.  This is a really minor thing, though.

> I've attached here my version of the tab script.

I'll start testing the changes shortly.

> I've changed "tabgroup.jl" to use the already existing "window
> groups" in sawfish.

Awesome.  I've been meaning to do the exact same thing.  I always
wondered why the original author didn't use sawfish's existing
window groups, but ... I've never really known what those window
groups were for.

> I can't see how someone would ever want to use groups and tabs
> simultaneously and independently (since groups are just like
> tabs that are not attached to each other).

What do groups actually do?  Who uses them?

> ..or making a window match (e.g.  making all terminals be
> tabbed/grouped right when they are created, just like fluxbox).

Interesting.  I can see a few useful things to do with that...

It would be very handy to make new windows go into the
currently-focused group if the title (or part of the title)
matches.  I have to manually group Dillo windows.

Anyway, this is good progress.  :)


-- Scott

[GSR - FR]

Hi,
sawfish-list@... (2008-08-06 at 1748.23 -0600):
[...]
> > I can't see how someone would ever want to use groups and tabs
> > simultaneously and independently (since groups are just like
> > tabs that are not attached to each other).
>
> What do groups actually do?  Who uses them?

There are special commands and settings that work with them (,apropos
"group" as start). I would make tabs separate instead of overloading
groups to avoid things going nuts (imagine you want to group GIMP
windows, but not all in same tabset, but a couple of them).

> > ..or making a window match (e.g.  making all terminals be
> > tabbed/grouped right when they are created, just like fluxbox).
> Interesting.  I can see a few useful things to do with that...
> It would be very handy to make new windows go into the
> currently-focused group if the title (or part of the title)
> matches.  I have to manually group Dillo windows.

That sounds like a new matcher option... IE, named tabs.

GSR
 

[Pat Regan]

GSR - FR wrote:

> Hi,
> janek_listy@... (2008-08-06 at 1808.46 +0200):
> [...]
>> We need a single function which goes through all windows and sorts
>> them according to tab groups. This function can be bound to some
>> hotkey combination. And we could simply invoke it by keypress to
>> clear the odd looking view.
>
> Better find a way that requires no resorting, specially manual
> kind. ;]
>

How slow could resorting be?  I would agree that manual intervention
would be a Bad Thing(tm).  We could probably hook a sort routing onto
the move/resize window-hooks.

It seems smart at this point to make what we have work instead of trying
to push deeper into the core to make it work.

Pat

[Fernando-49]

On Thu, Aug 7, 2008 at 2:41 AM, GSR - FR <famrom@...> wrote:

Hi,
sawfish-list@... (2008-08-06 at 1748.23 -0600):
[...]

> > I can't see how someone would ever want to use groups and tabs
> > simultaneously and independently (since groups are just like
> > tabs that are not attached to each other).
>
> What do groups actually do?  Who uses them?

There are special commands and settings that work with them (,apropos
"group" as start). I would make tabs separate instead of overloading
groups to avoid things going nuts (imagine you want to group GIMP
windows, but not all in same tabset, but a couple of them).

Hmm.. I think you are maybe right. I didn't realized that there was a "when raise a window also raise its group"... this makes the whole group idea be worthy when you want to keep the stacking of groups of windows closely related, like Gimp, without sticking them together.

Abut the stacking thing of tabs... I think that using the focus hook is a dirty thing anyway. No need to update the stacking if it was not modified, it would be just a waste of resources.

That's why I've written a patch with raise/lower hooks: http://sawfish.wikia.com/wiki/After_raise/lower-window_hooks

The group raising functionality is "hard coded". well, I mean... it's checking with a (cond) what's the value of the stacking mode the user wants each time it makes a raise/lower. So I think the best option is to have the hook. Unless we wanna make the tabs a unseparable part of sawfish instead of a module.

--
Fernando

[Fernando-49]

On Thu, Aug 7, 2008 at 9:21 AM, Fernando <ferkiwi@...> wrote:

On Thu, Aug 7, 2008 at 2:41 AM, GSR - FR <