On Fri, 2006-08-11 at 10:26 +0200, Anselm R. Garbe wrote:
> On Thu, Aug 10, 2006 at 11:28:31PM -0400, Ross Mohn wrote:
> > * Clicks on the status bar to the right of the tab boxes now change the
> > client
> > focus. A left-click (Button1) calls focusnext and any other button calls
> > focusprev.
>
> I thought about this (I also implemented that in the train this
> morning), but I realized that this is pretty useless. How often
> do you click on the statusbar to focus the next/prev client? I
> do that with moving the pointer to the specific client or using
> M-{j,k,Return} resp.
Agreed. It really only makes sense in my max mode where the client
windows stay maxed in the tag view, thus you can't see the other clients
to click on. That's the only reason I implemented it in my patch.
> Instead of aiming the behavior you described, I added
> view-selection with Button1 (leftwards outside the tag buttons)
> and Button3 (rightwards outside the tag buttons) beside
> keeping Button4/Button5 scrolling. Depending on the mouse in use
> this is a combination of both 'worlds'.
>
> First, diff -u would be more clear and easier to read btw.
Yup, changed for next run.
> > + if(!c->isfloat)
> > + for(f = clients; f; f = f->next)
> > + if(f->isfloat)
> > + higher(f);
>
> That is an expensive operation. I recommend you to have a look
> into restack() of wmii or into XRestackWindows(3).
Agreed, will investigate those.
> Another thing is, if you'd rename dolayout into arrange you
> would save a bunch of lines to be patched.
Nice! Applied.
-RPM
Received on Fri Aug 11 2006 - 13:59:11 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 14:30:05 UTC