On Sat, 20 Sep 2014 17:04:02 +0800
David Maciejak <[email protected]> wrote:
> That is the behaviour i have without the patch (and that's why i
> called it mixed up windows list):
>
> 1 has focus
> alt-tab (next window) show
> 1 [2] 3
> 2 has focus
> alt-tab show
> 2 [1] 3
> 1 has focus
> alt-tab show
> 1 [2] 3
> press another alt-tab, select 3
> 1 2 [3]
> 3 has focus
> alt-tab show
> 3 [1] 2
> another alt-tab to 2, show
> 3 1 [2]
> 2 has focus
> alt-tab show
> 2 [3] 1
>
> To do that i just configured the "Focus next window" in WPrefs to
> alt-tab. But as said that behaviour is sounding more like move focus
> back to previous focused window.
>
> > A, B, [C], D
> > now I alt-tab again and with this patch it goes to D
> > A, B, C, [D]
>
> yes that was what i was expecting from "Focus next window"
>
> > [A], B, C, D
> > I 'alt-tab' and while keeping alt down, I 'tab' more and end up on
> > let's say C
> > A, B, [C], D
> > with old behaviour I am back on A
> > [A], B, C, D
>
> That's focus on previous focused window.
> I can understand that feature is useful but not really expected.
I've checked some other operating systems and OS X and Windows XP (both
using switchpanels) bring application you change to, to the front of the
window list. I would say it makes a lot of sense in keyboard driven
windows management. People usually work with few applications and want
to change between them instantly, without going through a whole list
(especially if they have a lot of windows open), so it makes a lot of
sense to keep recently used ones closer on list.
Imagine for example:
webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm
with task being: copying stuff from webbrowser to mailapp.
With your patch you would need each time focus on where your browser and
mailapp are and go through all those xterms when changing windows,
instead of instantly changing between them.
But yes, I've checked and I confirm that it doesn't work too well with
mouse bindings ("Next Window" keeps changing just between two windows,
instead of going through list) which, as I understand is the way you
want to use it.
>
>
> On Fri, Sep 19, 2014 at 7:39 PM, David Maciejak
> <[email protected]> wrote:
> > On Fri, Sep 19, 2014 at 5:24 PM, Carlos R. Mafra
> > <[email protected]> wrote:
> >>> On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra
> >>> <[email protected]> wrote:
> >>> > On Wed, 17 Sep 2014 at 12:29:57 +0200, Amadeusz Sławiński wrote:
> >>> >> On Thu, 11 Sep 2014 17:50:40 +0800
> >>> >> David Maciejak <[email protected]> wrote:
> >>> >>
> >>> >> > This patch is fixing the focused next window list order.
> >>> >> > As now, the switching was only working for 2 windows.
> >>> >> > For example, taking 3 windows called A,B,C.
> >>> >> > If the windows list is A,B,C where A is the current focused
> >>> >> > window. Focusing on B will result on switching position A
> >>> >> > and B, thus C will never be the next window.
> >>> >> > For this example the patch is updating the linked list as
> >>> >> > B,C,A.
> >>> >>
> >>> >>
> >>> >> Hey,
> >>> >>
> >>> >> I think this patch breaks behaviour of Window Maker.
> >>> >>
> >>> >> One thing is that when I change between workspaces it keeps
> >>> >> focusing last created window instead of last used one.
> >>> >>
> >>> >> Other is that it changes focus behaviour, ie, I can't alt-tab
> >>> >> between two windows, now I have to go through whole list to
> >>> >> change between two recently used ones.
> >>> >> For example with windows A, B, C, D (with [A] marking A as
> >>> >> focused) [A], B, C, D
> >>> >> I 'alt-tab' once
> >>> >> A, [B], C, D
> >>> >> I 'alt-tab' once more
> >>> >> A, B, [C], D
> >>> >> where old behaviour would go to:
> >>> >> [A], B, C, D
> >>> >>
> >>> >> I could also choose other window instead of B and I could go
> >>> >> back to A instantly like so
> >>> >> [A], B, C, D
> >>> >> I 'alt-tab' and while keeping alt down, I 'tab' more and end
> >>> >> up on let's say C
> >>> >> A, B, [C], D
> >>> >> now I alt-tab again and with this patch it goes to D
> >>> >> A, B, C, [D]
> >>> >> with old behaviour I am back on A
> >>> >> [A], B, C, D
> >>> >>
> >>> >> I think the old behaviour is more usable.
> >>> >> So I would like to propose reverting this patch
> >>> >
> >>> > Thanks for the detailed description. I also caught
> >>> > myself doing extra Alt+TABs recently because of this.
> >>> >
> >>> > At first I thought it was a good idea when I saw the
> >>> > patch, but the old behaviour is somehow imprinted
> >>> > on my mind.
> >>> >
> >>> > Reverting.
> >>
> >> On Fri, 19 Sep 2014 at 16:57:08 +0800, David Maciejak wrote:
> >>> Reverting the patch will kill the mouse action of switching on
> >>> next window.
> >>
> >> Then that should be fixed as well. Why should the mouse action
> >> depend on the window list order? Why can't it use the same
> >> mapping as the Alt+TAB shortcut?
> >>
> >> By the way, was the "mouse action" patch the motivation for this
> >> "window list order" patch?
> >>
> >>
> >
> > From my point of view, the switchpanel should be fixed instead.
> > As now there is a linked list of windows which is mixed every time a
> > alt-tab is done. That means there is no way to know the next window
> > and do cycling windows. If you check the switchpanel you will see
> > that each time it's called the icons are in a different order. It
> > should be better to save the previous focus window in a different
> > dedicated variable. I can look at that later.
>
>
--
To unsubscribe, send mail to [email protected].
