On Mon, 26 May 2014 01:56:30 +0200
Josip Deanovic <djosip+n...@linuxpages.net> wrote:
> Quoting message written on Monday 2014-05-26 01:01:03 by Amadeusz:
> > Hey,
> >
> > so I've taken a look at this, seems like it just needs additional
> > checks if windows are shaded. I've done some testing and it seems
> > to work ok, both with and without switchpanel.
> >
> > Amadeusz
>
> I have just tested it and I can confirm that it works in both cases,
> including workspace change.
>
>
>
> If nobody has anything to add I consider this issue closed and I would
> like add yet another observation related to alt+tab (window cycling).
>
> It seems that along with the support for switchpanel came another
> change that negatively affected setup without switchpanel and it is
> related to window cycling (specifically alt+tab).
>
> I'll try to describe it.
> When using switchpanel and alt+tab (window cycling), by holding the
> ALT key and pressing the TAB key, we would get windows cycling
> through the window list.
> But if we stop using pressing TAB key while still holding the ALT key,
> by pressing LEFT or RIGHT key we would continue cycling trough the
> list of windows.
>
> This might even look logical when switchpanel is used because LEFT or
> RIGHT keys would chose left or right icons that represent their
> windows on the switchpanel.
>
> However, when the switchpanel is disabled the described behavior stays
> and often doesn't allow to simply reuse ALT key with some other key
> combination explicitly specified in the configuration that includes
> LEFT or RIGHT key without first releasing the ALT key.
>
> In short, ALT+LEFT and ALT+RIGHT key combination is blocked right
> after ALT+TAB is used unless the ALT key is released and pressed
> again.
>
> Could we please try to remove such behavior for the case where
> switchpanel is disabled since there is no use of such behavior
> when switchpanel is not visible and it's different when compared to
> windowmaker 0.80.x.
> I am using 0.95.5 for over a year now and I still can't get used to
> it. When switchpanel is not used the old behavior is much better
> especially if you are using ALT+LEFT and ALT+RIGHT for some specific
> actions.
>
Well something along those lines seems to work, but it seems
'workaroundish', problem is that those (and few more like esc and
return) are hardcoded. But if Carlos has nothing against such approach
I will write a full patch.
diff --git a/src/cycling.c b/src/cycling.c
index 9331739..35d62d1 100644
--- a/src/cycling.c
+++ b/src/cycling.c
@@ -153,7 +153,7 @@ void StartWindozeCycle(WWindow *wwin, XEvent
*event, Bool next, Bool class_only) &&
wKeyBindings[WKBD_FOCUSNEXT].modifier == modifiers) ||
(wKeyBindings[WKBD_GROUPNEXT].keycode == ev.xkey.keycode &&
wKeyBindings[WKBD_GROUPNEXT].modifier == modifiers)
- || ev.xkey.keycode == rightKey) {
+ || (wPreferences.swtileImage &&
ev.xkey.keycode == rightKey)) {
newFocused =
wSwitchPanelSelectNext(swpanel, False, ev.xkey.keycode != rightKey,
(!class_only && wKeyBindings[WKBD_GROUPNEXT].keycode == ev.xkey.keycode
&& wKeyBindings[WKBD_GROUPNEXT].modifier == modifiers)); oldFocused =
change_focus_and_raise(newFocused, oldFocused, swpanel, scr, False); @@
-162,7 +162,7 @@ void StartWindozeCycle(WWindow *wwin, XEvent *event,
Bool next, Bool class_only) && wKeyBindings[WKBD_FOCUSPREV].modifier ==
modifiers) || (wKeyBindings[WKBD_GROUPPREV].keycode == ev.xkey.keycode
&& wKeyBindings[WKBD_GROUPPREV].modifier == modifiers)
- || ev.xkey.keycode == leftKey) {
+ || (wPreferences.swtileImage &&
ev.xkey.keycode == leftKey)) {
newFocused =
wSwitchPanelSelectNext(swpanel, True, ev.xkey.keycode != leftKey,
(!class_only && wKeyBindings[WKBD_GROUPPREV].keycode == ev.xkey.keycode
&& wKeyBindings[WKBD_GROUPPREV].modifier == modifiers)); oldFocused =
change_focus_and_raise(newFocused, oldFocused, swpanel, scr, False);
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
