Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014, BALATON Zoltan wrote: I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. Looks like the setting is still there in WindowMaker.h, struct Wpreferences as member named windows_cycling but reading it from config was removed from defaults.c. I could not find it actually used as far back as 0.91.0 so it may have been removed before that. This setting was exactly for changing the behaviour of Mod-Tab switching between cycling through windows vs. bringing the last focused window to the top of the list. You may want to look at reviving this. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com 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 david.macie...@gmail.com wrote: On Fri, Sep 19, 2014 at 5:24 PM, Carlos R. Mafra crma...@gmail.com wrote: On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra crma...@gmail.com 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 david.macie...@gmail.com 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
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote: On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com 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. Precisely! What David wants to fix is actually more of a semantic problem. In practice, the current behaviour is much more desirable for the reason you pointed out. And quite frankly, we cannot change such a behaviour right now. Long-time wmaker users will just be annoyed, and they are wmaker's biggest asset. 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. I think the way out is to introduce an option to select between David's and the current behaviour. Something along the lines of Strict focus next behaviour with default off and many comments about it being useful for the mouse bindings (perhaps in balloon texts). -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote: On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com 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. Precisely! What David wants to fix is actually more of a semantic problem. In practice, the current behaviour is much more desirable for the reason you pointed out. And quite frankly, we cannot change such a behaviour right now. Long-time wmaker users will just be annoyed, and they are wmaker's biggest asset. 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. I think the way out is to introduce an option to select between David's and the current behaviour. Something along the lines of Strict focus next behaviour with default off and many comments about it being useful for the mouse bindings (perhaps in balloon texts). I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. Regards, BALATON Zoltan
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 18:02:36 +0200, BALATON Zoltan wrote: On Sat, 20 Sep 2014, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote: On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com 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. Precisely! What David wants to fix is actually more of a semantic problem. In practice, the current behaviour is much more desirable for the reason you pointed out. And quite frankly, we cannot change such a behaviour right now. Long-time wmaker users will just be annoyed, and they are wmaker's biggest asset. 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. I think the way out is to introduce an option to select between David's and the current behaviour. Something along the lines of Strict focus next behaviour with default off and many comments about it being useful for the mouse bindings (perhaps in balloon texts). I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. I'm not sure what's the WindozeCycling option would imply the behaviour that David wants though. But apparently it's long gone from WPrefs, since git log -SWindozeCycling -p WPrefs.app/ returns the following patch from 2004: commit 6cd91272a692f235aa6c8e5e7c57900a603fc963 Author: kojima kojima Date: Tue Oct 19 02:37:58 2004 + fixed a bug with workspace switching diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c index 3458513..b84fbf1 100644 --- a/WPrefs.app/Expert.c +++ b/WPrefs.app/Expert.c @@ -51,11 +51,10 @@ showData(_Panel *panel) WMSetButtonSelected(panel-swi[1], WMGetUDBoolForKey(udb, NoXSetStuff)); WMSetButtonSelected(panel-swi[2], GetBoolForKey(SaveSessionOnExit)); WMSetButtonSelected(panel-swi[3], GetBoolForKey(UseSaveUnders)); -WMSetButtonSelected(panel-swi[4], GetBoolForKey(WindozeCycling)); -WMSetButtonSelected(panel-swi[5], GetBoolForKey(DontConfirmKill)); -WMSetButtonSelected(panel-swi[6], GetBoolForKey(DisableBlinking)); +WMSetButtonSelected(panel-swi[4], GetBoolForKey(DontConfirmKill)); +WMSetButtonSelected(panel-swi[5], GetBoolForKey(DisableBlinking)); -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 18:07:34 +0100 Carlos R. Mafra crma...@gmail.com wrote: On Sat, 20 Sep 2014 at 18:02:36 +0200, BALATON Zoltan wrote: On Sat, 20 Sep 2014, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote: On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com 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. Precisely! What David wants to fix is actually more of a semantic problem. In practice, the current behaviour is much more desirable for the reason you pointed out. And quite frankly, we cannot change such a behaviour right now. Long-time wmaker users will just be annoyed, and they are wmaker's biggest asset. 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. I think the way out is to introduce an option to select between David's and the current behaviour. Something along the lines of Strict focus next behaviour with default off and many comments about it being useful for the mouse bindings (perhaps in balloon texts). I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. I'm not sure what's the WindozeCycling option would imply the behaviour that David wants though. But apparently it's long gone from WPrefs, since git log -SWindozeCycling -p WPrefs.app/ returns the following patch from 2004: commit 6cd91272a692f235aa6c8e5e7c57900a603fc963 Author: kojima kojima Date: Tue Oct 19 02:37:58 2004 + fixed a bug with workspace switching I knew this talk seemed bit familiar, there was report of wanting behaviour implemented by David a while back: http://lists.windowmaker.org/user/msg00377.html -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yes, the patch was already reverted. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yes, the patch was already reverted. ...which was the only reasonable way out, after all. Thanks! Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 21:35:29 +0300, Yury Tarasievich wrote: On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yes, the patch was already reverted. ...which was the only reasonable way out, after all. Thanks! It is not the only way out, though. We can make the behaviour follow a config option. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra crma...@gmail.com 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 david.macie...@gmail.com 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? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Fri, Sep 19, 2014 at 5:24 PM, Carlos R. Mafra crma...@gmail.com wrote: On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra crma...@gmail.com 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 david.macie...@gmail.com 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 wmaker-dev-unsubscr...@lists.windowmaker.org.
