| commit | a268327a483206affaff74edb077a2a65e97e5bd | |
| author | Thomas Otto <totto@zbh.uni-hamburg.de> | |
| Sun, 18 Aug 2013 08:20:33 +0000 (18 10:20 +0200) | ||
| committer | Carlos R. Mafra <crmafra@gmail.com> | |
| Mon, 19 Aug 2013 18:11:09 +0000 (19 19:11 +0100) | ||
| tree | 90b8df0a3f6d46c4061d53ba630f15ae86dcfcba | treesnapshot (tar.gz zip) |
| parent | ca9c57f695059b96626330a4e48df2f703cd7a3c | commitdiff |
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.
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.
| src/actions.c | diffblobblamehistory |