1
0
mirror of https://github.com/gryf/wmaker.git synced 2025-12-20 21:08:08 +01:00

wmaker: reset "ignore workspace change" flag in all cases

When an application steals focus and switches workspaces autonomously,
"ignore workspace change" does not get reset. Since I didn't want to
track down the exact case I thought it best to reset the flag in all
cases, as it probably should be.

> How did you discover this? What was the behavior you saw?

After saving files in avidemux, the "Done" dialog pops up, and with it the
entire application is moved to the current workspace. After this, using the
mousewheel on the root window or using the appropriate key combination does
not change the workspace anymore, only using the arrows on the clip works.

And, as mentioned on the mailing list, just starting emacs (22.3.1) also
provokes this bug. Using a Debian/Sid system btw.
This commit is contained in:
Thomas Otto
2013-08-18 10:20:33 +02:00
committed by Carlos R. Mafra
parent ca9c57f695
commit a268327a48

View File

@@ -1211,8 +1211,10 @@ void wDeiconifyWindow(WWindow *wwin)
if (!netwm_hidden)
wWindowChangeWorkspace(wwin, wwin->screen_ptr->current_workspace);
if (!wwin->flags.miniaturized)
if (!wwin->flags.miniaturized) {
ignore_wks_change = 0;
return;
}
if (wwin->transient_for != None && wwin->transient_for != wwin->screen_ptr->root_win) {
WWindow *owner = recursiveTransientFor(wwin);
@@ -1221,6 +1223,7 @@ void wDeiconifyWindow(WWindow *wwin)
wDeiconifyWindow(owner);
wSetFocusTo(wwin->screen_ptr, wwin);
wRaiseFrame(wwin->frame->core);
ignore_wks_change = 0;
return;
}
}
@@ -1308,8 +1311,10 @@ void wDeiconifyWindow(WWindow *wwin)
ProcessPendingEvents();
/* the window can disappear while ProcessPendingEvents() runs */
if (!wWindowFor(clientwin))
if (!wWindowFor(clientwin)) {
ignore_wks_change = 0;
return;
}
}
#endif
}