[RESOLVED] window stacking: new window not focused

johnraff · 2018-05-17 10:30:26

This was raised here: https://forums.bunsenlabs.org/viewtopic … 801#p71801
but I've also noticed it. Sometimes new windows open behind the current window. It has been suggested that it might be a panel issue, but I wonder if it might be openbox, or related to the individual apps concerned.

Has anyone else seen this?

doxanthropos · 2018-05-17 14:14:24

Yes, but until now only with Terminator started via standard keybinding (Super+t), but there it seems to be the usual behavior. Other apps appear on top.

johnraff · 2018-05-21 06:56:41

@doxanthropos Have you got
dbus = False
under [global_config] in ~/.config/terminator/config?
That was supposed to fix the specific issue with Terminator, and is in the default BL settings.
https://forums.bunsenlabs.org/viewtopic … 701#p59701
https://bugs.launchpad.net/terminator/+bug/1508531

doxanthropos · 2018-05-21 10:28:05

Now I have.
But I had done no changes to the config before that.
The only change I made to Terminator was to start it as a login-shell so rvm works like it should.
Addition: Maybe this config line got lost in the update to Helium?

Last edited by doxanthropos (2018-05-21 10:30:17)

johnraff · 2018-05-22 06:42:29

doxanthropos wrote:

Maybe this config line got lost in the update to Helium?

Check /usr/share/bunsen/skel/.config/terminator/config to see what is shipped with Helium. Did you import an old $HOME into your new install perhaps? Or did you upgrade instead of doing a fresh install?

doxanthropos · 2018-05-22 21:08:55

Yes, I did an in place upgrade instead of a clean install.
/usr/share/bunsen/skel/.config/terminator/config already has the dbus = False.
Maybe I should have a look into the other config files from there.

hhh · 2018-06-15 00:51:34

Booyah! A little research went a long way.

Steps to reproduce... W-t, W-w, now a terminal and Firefox are open. Your next terminal will open behind Firefox. Or...

W-f, W-w, W-f, your next FF window will open behind Thunar.

Arch Community to the rescue!

https://bbs.archlinux.org/viewtopic.php?id=159688

Awesome, they used the #! and ArchBang configs to debug it.

And, indeed, the Wiki has it...

https://wiki.archlinux.org/index.php/op … ive_window

So, the bottom of your rc.xml should look like this...

<applications>
  <application class="*">
    <focus>yes</focus>
  </application>
</applications>

</openbox_config>

Now run Openbox>Reconfigure.

@johnraff, I added to the subject title and marked it solved. I suggest we add this to our default rc.xml.

If this doesn't work for anybody, please post here and we'll re-edit the subject, and weep quietly.

PS: I posted about the same issue quite a while back. How did we all miss the Arch Wiki?
https://forums.bunsenlabs.org/viewtopic.php?id=526

johnraff · 2018-06-17 05:22:52

^rc.xml fix applied, and no buried windows so far. Looking good...

If there are no other implications, yes let's add it to our default user config. Thanks!

There was another item in the Arch Wiki, just above that: https://wiki.archlinux.org/index.php/op … transition
Implemented that just now, and we'll see if it improves the LightDm>Openbox background transition.

ohnonot · 2018-06-17 06:13:08

is this an openbox bug? if so, i can post to the mailing list and tell them about it. what version is BL on?

i must say i never experienced this on archlinux (version 3.6.1).

also, being the nitpicker i am, i am not happy with calling this fix a solution, it really is the very definition of a workaround.

johnraff · 2018-06-17 06:25:46

Arch Wiki seem to regard it as an openbox bug, but it could be something about firefox, thunar, urxvt etc and the way they interact with it. Debian Stretch currently ships OpenBox 3.6.1-4

ohnonot · 2018-06-17 09:37:33

guess what, it just happened to me too!
there was an app involved that already has some <application> rules, but it hasn't happened before.
weird coincidence.

johnraff wrote:

Debian Stretch currently ships OpenBox 3.6.1-4

is that the output you get with

openbox --version

???

hhh · 2018-06-17 14:43:33

I love that wallpaper fix! I know it only saves a half-second, but my perception is that the desktop is loading much faster, probably because I'm not seeing that jarring, hideous flicker. Nice catch, johnraff!

@ohnonot...

rachel@TyrellCorp:~$ openbox --version
Openbox 3.6.1
Copyright (c) 2004   Mikael Magnusson
Copyright (c) 2002   Dana Jansens

This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

rachel@TyrellCorp:~$

https://packages.debian.org/stretch/openbox

I'll mark this [RESOLVED], to save your sensibilities.

DeepDayze · 2018-06-18 02:21:56

johnraff wrote:

^rc.xml fix applied, and no buried windows so far. Looking good...
If there are no other implications, yes let's add it to our default user config. Thanks!
There was another item in the Arch Wiki, just above that: https://wiki.archlinux.org/index.php/op … transition
Implemented that just now, and we'll see if it improves the LightDm>Openbox background transition.

Which file needs that change as I don't see /usr/lib/openbox/openbox-autostart on debian. Also that rc.xml fix makes the window behavior more natural and WFM.

Last edited by DeepDayze (2018-06-18 02:23:08)

PackRat · 2018-06-18 17:44:10

Do you know if the "Focus new windows when they appear" was checked:

Yes. I haven't tested unchecking and rechecking the input box, I was just going by the relative setting in rc.xml

PackRat · 2018-06-18 20:02:25

Looks like my previous post got mangled -

If there are no other implications, yes let's add it to our default user config. Thanks!

I haven't tested it, but I think that fix will override any [application settings] settings to have an application start iconified or in the system tray by default.

@hhh, johnraff -

do you have this stanza near the beginning of your rc.xml file (lines 9-26 of mine)

 <focus>
    <focusNew>yes</focusNew>
    <!-- always try to focus new windows when they appear. other rules do
       apply -->
    <followMouse>no</followMouse>
    <!-- move focus to a window when you move the mouse into it -->
    <focusLast>yes</focusLast>
    <!-- focus the last used window when changing desktops, instead of the one
       under the mouse pointer. when followMouse is enabled -->
    <underMouse>no</underMouse>
    <!-- move focus under the mouse, even when the mouse is not moving -->
    <focusDelay>200</focusDelay>
    <!-- when followMouse is enabled, the mouse must be inside the window for
       this many milliseconds (1000 = 1 sec) before moving focus to it -->
    <raiseOnFocus>no</raiseOnFocus>
    <!-- when followMouse is enabled, and a window is given focus by moving the
       mouse into it, also raise the window -->
  </focus>

The focusNew would be the lines of interest.

Last edited by PackRat (2018-06-18 20:05:41)

hhh · 2018-06-19 04:45:44

At PackRat, that's what we have as the default, and it wasn't enough to always focus a new window...

<?xml version="1.0" encoding="UTF-8"?>
<openbox_config xmlns="http://openbox.org/3.4/rc" xmlns:xi="http://www.w3.org/2001/XInclude">
  <resistance>
    <strength>10</strength>
    <screen_edge_strength>20</screen_edge_strength>
  </resistance>
  <focus>
    <focusNew>yes</focusNew>
    <!-- always try to focus new windows when they appear. other rules do
       apply -->
    <followMouse>no</followMouse>
    <!-- move focus to a window when you move the mouse into it -->
    <focusLast>yes</focusLast>
    <!-- focus the last used window when changing desktops, instead of the one
       under the mouse pointer. when followMouse is enabled -->
    <underMouse>no</underMouse>
    <!-- move focus under the mouse, even when the mouse is not moving -->
    <focusDelay>200</focusDelay>
    <!-- when followMouse is enabled, the mouse must be inside the window for
       this many milliseconds (1000 = 1 sec) before moving focus to it -->
    <raiseOnFocus>no</raiseOnFocus>
    <!-- when followMouse is enabled, and a window is given focus by moving the
       mouse into it, also raise the window -->
  </focus>
  <placement>
    <policy>Smart</policy>
    <!-- 'Smart' or 'UnderMouse' -->
    <center>no</center>
    <!-- whether to place windows in the center of the free area found or
       the top left corner -->
    <monitor>Any</monitor>
    <!-- with Smart placement on a multi-monitor system, try to place new windows
         on: 'Any' - any monitor, 'Mouse' - where the mouse is, 'Active' - where
         the active window is, 'Primary' - only on the primary monitor -->
    <primaryMonitor>1</primaryMonitor>
    <!-- The monitor where Openbox should place popup dialogs such as the
         focus cycling popup, or the desktop switch popup.  It can be an index
         from 1, specifying a particular monitor.  Or it can be one of the
         following: 'Mouse' - where the mouse is, or
                    'Active' - where the active window is -->
  </placement>

The workaround is working perfectly, though.

johnraff · 2018-06-19 07:21:46

@hhh I think we need to check if PackRat's caveat about apps set to open iconified applies or not, before giving that focus fix the final stamp of approval. However, this gives grounds for optimism:

rc.xml wrote:

# when multiple rules match a window, they will all be applied, in the
# order that they appear in this list

So as long as the general rule appears first, it should be possible for something more specific to override it.

Last edited by johnraff (2018-06-21 04:55:40)

hhh · 2018-06-19 07:41:35

johnraff wrote:

@hhh I think we need to check if PackRat's caveat about apps set to open iconified applies or not, before giving that focus fix the final stamp of approval. However, this gives grounds for optimism:
rc.xml wrote:
# when multiple rules match a window, they will all be applied, in the
# order that they appear in this list
So as long as the general rule appears first, it should be possible for something more specific to override it.

Agreed.

---
Mod. note: this refers to a separate issue, now here: https://forums.bunsenlabs.org/viewtopic.php?id=4966

About the background login transfer fix: it's working nicely for me too. I only commented out the single line
#test -z $BG || $BG -solid "#303030"
The previous "if" section should go very quickly anyway - say 4~5ms.

Yes, and it looks like that line is already commented out with a buster upgrade.

Last edited by johnraff (2018-06-21 04:57:55)

johnraff · 2018-06-19 08:47:04

About the focus issue, I added this bit of code below the focus fix code:

    <application name="bl-text-editor">
      <iconic>yes</iconic>
    </application>

And sure enough geany (if called as bl-text-editor) opens iconified, regardless, so it looks as if this fix/hack/workaround might be safe to apply:

    <application class="*">
      <focus>yes</focus>
    </application>

hhh · 2018-06-19 08:51:55

Cool. It's a good workaround, let's add it.

#1 2018-05-17 10:30:26

[RESOLVED] window stacking: new window not focused

#2 2018-05-17 14:14:24

Re: [RESOLVED] window stacking: new window not focused

#3 2018-05-21 06:56:41

Re: [RESOLVED] window stacking: new window not focused

#4 2018-05-21 10:28:05

Re: [RESOLVED] window stacking: new window not focused

#5 2018-05-22 06:42:29

Re: [RESOLVED] window stacking: new window not focused

#6 2018-05-22 21:08:55

Re: [RESOLVED] window stacking: new window not focused

#7 2018-06-15 00:51:34

Re: [RESOLVED] window stacking: new window not focused

#8 2018-06-17 05:22:52

Re: [RESOLVED] window stacking: new window not focused

#9 2018-06-17 06:13:08

Re: [RESOLVED] window stacking: new window not focused

#10 2018-06-17 06:25:46

Re: [RESOLVED] window stacking: new window not focused

#11 2018-06-17 09:37:33

Re: [RESOLVED] window stacking: new window not focused

#12 2018-06-17 14:43:33

Re: [RESOLVED] window stacking: new window not focused

#13 2018-06-18 02:21:56

Re: [RESOLVED] window stacking: new window not focused

#14 2018-06-18 17:44:10

Re: [RESOLVED] window stacking: new window not focused

#15 2018-06-18 20:02:25

Re: [RESOLVED] window stacking: new window not focused

#16 2018-06-19 04:45:44

Re: [RESOLVED] window stacking: new window not focused

#17 2018-06-19 07:21:46

Re: [RESOLVED] window stacking: new window not focused

#18 2018-06-19 07:41:35

Re: [RESOLVED] window stacking: new window not focused

#19 2018-06-19 08:47:04

Re: [RESOLVED] window stacking: new window not focused

#20 2018-06-19 08:51:55

Re: [RESOLVED] window stacking: new window not focused

Board footer