I found this proposal in Ubuntu's launchpad. This change also bothers me a lot: As of openbox version 3.4.7, _NET_ACTIVE_WINDOW messages do not change the current desktop, but bring the window to the current desktop instead. This is the industry standard policy, whatever that means. This for instance happens if Openbox is used in KDE 4 instead of Kwin4. The link on launchpad has a patch that works fine. Could it be applied to Gentoo ? Reproducible: Always Steps to Reproduce: 1. Run an openbox-kde-session 2. open a window, 3. switch to another desktop 4. klick on the pager icon to bring the window to the front Actual Results: Window appears on the current desktop Expected Results: Pager should switch to the Desktop where the window was and the open it.
Something that may or may not be related: I'm using rox and openbox. In firefox I'm using Session Manager with a large, 2 window session. After first window opens, there's a long enough delay for me to send it to the other desktop, before second window opens. But, for awhile, I thought something got broken between ff2 and 3, cause the moment second window opened, first window was moved to the desktop, the second window appeared. But looking at this bug, I think this may be related. Not sure if, in that case, I would call it a problem with openbox or with rox.
16:09 < omp> http://bugs.gentoo.org/show_bug.cgi?id=247037 16:09 < omp> hrm, comments? 16:11 < Mikachu> omp: just wait until 3.4.8 16:11 < omp> alright Should be coming soon... I'll leave the bug open as a reminder. =]
Fixed with 3.4.8_rc1 now in the tree.
Sorry, but this does not change anything here. Reopening as /etc/xdg/openboxrc.xml has no change relevant to this and using the option <obeyNetActiveWindow>no</obeyNetActiveWindow> does not change anything.
I just tested the behaviour of openbox-3.4.8_rc1-r1 with the steps similar to those given in the Description. gnome-light + openbox 1. start firefox on the 1 virtual desktop 2. open a terminal so firefox is now in the back and terminal is in the front 3. change to desktop 2 which holds a term with an irssi session 4. click a link in the irssi session result: gnome panel shows an entry for firefox that is pulsing to indicate its state 5. clicking on desk 1 of the pager or clicking on the pulsing taskbar entry takes you from desk 2 to desk 1 and firefox is moved from the back to the front so that it isn't covered by the terminal anylonger. I'd say this bug is fixed.
> I'd say this bug is fixed. I'd say its not :) I just reproduced it. Lets clarify the issue. Try the following: (Sorry for fuzzyness) 1) Open a kde-openbox session 'with a panel' (e.g. standard stable kde 4 with clean config) 2) open a 'konsole'-terminal 3) switch to another desktop 4) click on the word 'konsole' which displays in the middle of the taskbar. (This is not about clicking on the miniature desktops in the pager!) Now, if <obeyNetActiveWindow>yes</obeyNetActiveWindow> is in the openbox config, the Konsole window should move to the new desktop. If it is set to 'no' openbox should switch to the old desktop and open the console there. Should be the same in gnome, mutatis mutandis. Can you try to reproduce this?
> Now, if <obeyNetActiveWindow>yes</obeyNetActiveWindow> is in the openbox config The only place you find this config option is the ubuntu launchpad. In the latest version of openbox this behaviour has changed like i described above but it isn't configurable. I asked in #openbox and it will probably be configurable in the future. Before i switched to 3.4.8 i used the patch for 3.4.7.2 which can be found in the openbox bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=3659 . Maybe you should follow that bug and see how this problem is handled upstream. I'll attach my 3.4.7.2-r1.ebuild which uses the patch so you can throw it in your local overlay. It makes the behaviour configurable via <gotoOnActivate>yes</gotoOnActivate> in rc.xml. Hope that helps you until the behaviour is configurable in openbox 3.4.8, too.
Created attachment 211748 [details, diff] Goto on activate patch
Created attachment 211750 [details] updated ebuild that uses the patch
(In reply to comment #7) > > Now, if <obeyNetActiveWindow>yes</obeyNetActiveWindow> is in the openbox > config > > The only place you find this config option is the ubuntu launchpad. > In the latest version of openbox this behaviour has changed like i described > above but it isn't configurable. I asked in #openbox and it will probably be > configurable in the future. True. Originally I mirrored this bug from the corresponding launchpad bug. Then somebody closed it as fixed which made me assume that the launchpad patch was applied, which is not the case. > Before i switched to 3.4.8 i used the patch for 3.4.7.2 which can be found in > the openbox bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=3659 . Maybe > you should follow that bug and see how this problem is handled upstream. > I'll attach my 3.4.7.2-r1.ebuild which uses the patch so you can throw it in > your local overlay. It makes the behaviour configurable via > <gotoOnActivate>yes</gotoOnActivate> in rc.xml. Hope that helps you until the > behaviour is configurable in openbox 3.4.8, too. I am actually not using a panel anymore, just plain openbox window navigation and currently there are no problems. In any case, thanks for looking into this, maybe the backported patch could be applied to the ebuild by some gentoo dev...?
This is supposedly fixed upstream. If you still have an issue with the latest version (currently 3.4.10) then feel free to reopen.
