User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061025 Firefox/2.0 Build Identifier: When I switch to an empty workspace, windows loose focus in other workspaces Reproducible: Always Steps to Reproduce: 1. open one window in a workspace, make sure it has focus 2. switch to an empty workspace 3. switch back to the previous workspace, the window lost focus
I cannot reproduce that issue. Can you post the result of "xfwm4 --version", xlsclients and give some hints on the focus model you use?
jf@fawkes ~ $ xfwm4 --version DBG[main.c:536] main(): xfwm4 starting This is xfwm4 version 4.3.99.2 (revision 23940) for Xfce 4.3.99.2 Released under the terms of the GNU General Public License. Compiled against GTK+-2.10.6, using GTK+-2.10.6. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Embedded compositor: Yes - KDE systray proxy (deprecated): No jf@fawkes ~ $ xlsclients fawkes xterm -bg black -fg white fawkes xfce4-session fawkes xfce-mcs-manager fawkes xfdesktop fawkes xfce4-panel fawkes gkrellm2 fawkes xfce4-weather-plugin fawkes Terminal fawkes firefox-bin fawkes evolution-2.8 fawkes evolution-alarm-notify fawkes gaim fawkes thunar fawkes xfwm4 i'm using 'click to focus' focus model, new window get focus and raise on click
and i'm using latest svn (rev 23940)
Ok, my guess is that the focus is sent to a window that is sticky (only one, beside the desktop, eligible for focus if no other window is present). One the sticky window is focused, it remains focuses since it's present on all workspaces, ie focus is not lost, just sent to a window that you don't see it's focused. GKrellm is usually sticky and undecorated, so it sounds like a good candidate. Is gkrellm sticky?
yes it is
Then, can you kill gkrellm and see if the problem remains?
no it's gone when i kill gkrellm
Well, so I see no bug there. It's all normal.
i understand the logic but why didn't xfwm4 behave like that before ?
and may be you could skip undecorated windows when restoring focus on the new workspace
(In reply to comment #10) > and may be you could skip undecorated windows when restoring focus on the new > workspace Humm, ugly hack. You'll always have ppl with undecorated terminals that will complain that their terminal looses focus on ws switch. But as far I can tell, xfwm4 has always behaved like that. I *think* you can tell gkrellm to identify itself as a dock, which *should* prevent that behavior.
(In reply to comment #11) > > But as far I can tell, xfwm4 has always behaved like that. actually i had to update my local version to reproduce it (i found out the bug at work) > I *think* you can tell gkrellm to identify itself as a dock, which *should* > prevent that behavior. > I can but i don't want it to show on top and reserve some space on the workspace
(In reply to comment #12) > > But as far I can tell, xfwm4 has always behaved like that. > actually i had to update my local version to reproduce it (i found out the bug > at work) I see no bug there. > > I *think* you can tell gkrellm to identify itself as a dock, which *should* > > prevent that behavior. > > > > I can but i don't want it to show on top and reserve some space on the > workspace I'm not sure how to fix what doesn't seem to be broken.
> I'm not sure how to fix what doesn't seem to be broken. > Bah I can live with that :) (but i'm pretty sure this one will be marked duplicated in the future ;))
Well, it has not changed, so I don't see anything new here. BTW, I've changed the behavior so that it doesn't restore focus for windows that have the skip pager/taskbar property - gkrellm has this option.
(In reply to comment #15) > BTW, I've changed > the behavior so that it doesn't restore focus for windows that have the skip > pager/taskbar property - gkrellm has this option. > oh, thanks that'll do definitely it
Closing.