[fixed] Openbox sets temporary grey background during startup

johnraff · 2018-06-18 03:29:21

When first started up, Openbox sets a default grey background colour which is then overwritten by nitrogen, or any other wallpaper setting app. What this means for BL is a nasty glitch between the LightDm login and the BL desktop wallpaper, when a grey background is briefly shown.

EDIT: The package bunsen-openbox now in the "helium" repository will fix this issue if installed.

It was reported as a Debian bug in 2016: https://bugs.debian.org/cgi-bin/bugrepo … bug=843231 and is referenced in the Arch Wiki, just above the recent window focus issue: https://wiki.archlinux.org/index.php/op … transition
I implemented their suggested fix just now, and we'll see if it improves the LightDm>Openbox background transition.

hhh wrote:

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.

DeepDayze wrote:

Which file needs that change as I don't see /usr/lib/openbox/openbox-autostart on debian.

/usr/lib/x86_64-linux-gnu/openbox-autostart

Last edited by johnraff (2018-07-31 07:57:47)

hhh · 2018-06-18 09:28:36

^ That's for a 64 bit install, I'm guessing the 32 bit path is slightly different.

DeepDayze · 2018-06-18 15:31:46

johnraff wrote:

DeepDayze wrote:
Which file needs that change as I don't see /usr/lib/openbox/openbox-autostart on debian.
/usr/lib/x86_64-linux-gnu/openbox-autostart

Ok thanks and yes I have a 64bit BL install. Will check this file and try that fix.

DeepDayze · 2018-06-18 15:32:54

Did anyone try that background transition fix and did it work for them?

hhh · 2018-06-18 17:08:33

Yes. My system is 64 bit, so /usr/lib/x86_64-linux-gnu/openbox-autostart, mine looks like this now (note all the hash marks for the opening block of code)...

#!/bin/sh

# Set a background color
#BG=""
#if which hsetroot >/dev/null 2>/dev/null; then
#  BG=hsetroot
#elif which esetroot >/dev/null 2>/dev/null; then
#  BG=esetroot
#elif which xsetroot >/dev/null 2>/dev/null; then
#  BG=xsetroot
#fi
#test -z $BG || $BG -solid "#303030"

GLOBALAUTOSTART="/etc/xdg/openbox/autostart"
AUTOSTART="${XDG_CONFIG_HOME:-"$HOME/.config"}/openbox/autostart"

# Run the global openbox autostart script
if test -f $GLOBALAUTOSTART; then
    sh $GLOBALAUTOSTART
elif test -f $GLOBALAUTOSTART.sh; then
    sh $GLOBALAUTOSTART.sh
fi

# Run the user openbox autostart script
if test -f $AUTOSTART; then
    sh $AUTOSTART
elif test -f $AUTOSTART.sh; then
    sh $AUTOSTART.sh
fi

# Run the XDG autostart stuff.  These are found in /etc/xdg/autostart and
# in $HOME/.config/autostart.  This requires PyXDG to be installed.
# See openbox-xdg-autostart --help for more details.
if which xdg-autostart >/dev/null 2>/dev/null; then
   CMD=xdg-autostart
else
   CMD=/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart
fi
exec $CMD "$@"

Logout, and prepare for login bliss.

DeepDayze · 2018-06-18 23:28:02

Disabling the background setting in the global OB autostart in /usr/lib/x86_64-linux-gnu/openbox-autostart by commenting out the code block as shown by H3 worked for me as well. Desktop loaded faster as the time spent checking for wallpaper setters and/or setting a default bg was eliminated. Be careful to comment out ALL the lines as shown in H3's post otherwise it can cause OB to hang, as happened to me as I missed commenting out a line.

For clarification these are the relevant lines to change in that file and only comment these same lines like this:

# Set a background color
#BG=""
#if which hsetroot >/dev/null 2>/dev/null; then
#  BG=hsetroot
#elif which esetroot >/dev/null 2>/dev/null; then
#  BG=esetroot
#elif which xsetroot >/dev/null 2>/dev/null; then
#  BG=xsetroot
#fi
#test -z $BG || $BG -solid "#303030"

Last edited by DeepDayze (2018-06-18 23:44:13)

johnraff · 2018-06-20 03:26:50

johnraff wrote:

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.

hhh wrote:

About the background login transfer fix...
Yes, and it looks like that line is already commented out with a buster upgrade.

So it is! Debian have patched the code in response to a bug report: https://bugs.debian.org/cgi-bin/bugrepo … bug=843231

But it's quite an improvement so maybe we should push out our own fix (dpkg-divert of /usr/lib/x86_64-linux-gnu/openbox-autostart in bunsen-configs or bunsen-openbox) for Helium?

(bunsen-openbox doesn't exist but it might be cleaner to create one on the same lines as bunsen-thunar than to pack yet another tweak into bunsen-configs.)

ohnonot · 2018-06-20 04:02:31

about the login background color thing:

not sure if it's a good idea to edit that file (/usr/lib/*/openbox-autostart).

however, if you execute 'openbox' at login, instead of 'openbox-session', it isn't executed.

Here's the content of /usr/bin/openbox-session:

#!/bin/sh

if test -n "$1"; then
    echo "Syntax: openbox-session"
    echo
    echo "See the openbox-session(1) manpage for help."
  exit
fi

# Clean up after GDM
xprop -root -remove _NET_NUMBER_OF_DESKTOPS \
      -remove _NET_DESKTOP_NAMES \
      -remove _NET_CURRENT_DESKTOP 2> /dev/null

# Set up the environment
A="/etc/xdg/openbox/environment"
test -r $A && . $A
A="${XDG_CONFIG_HOME:-"$HOME/.config"}/openbox/environment"
test -r $A && . $A

# Run Openbox, and have it run the autostart stuff
exec /usr/bin/openbox --startup "/usr/lib/x86_64-linux-gnu/openbox-autostart OPENBOX" "$@"

imo, it's trivial to replace both scripts (this one and /usr/lib/*/openbox-autostart) with a bunsenlabs version, without the need to mess with the openbox package itself.

johnraff · 2018-06-20 06:45:08

^True, but it's substituting messing with the login process (lightdm implications?) for messing with openbox to the extent of adding a single # in /usr/lib/*/openbox-autostart.

(Although I was wondering whether sometime in the future a custom bunsen-session script might be useful, to make co-existence with other desktops easier.)

But this particular issue gets fixed in Buster, and meanwhile it would be quite easy to override a file like openbox-autostart with a dpkg-divert. We use fewer of these now than before, but bunsen-thunar uses one to remove the non-functional wallpaper item from Thunar's context menu. It looks complicated, but it would hardly have to be changed to do the same thing for openbox.

Last edited by johnraff (2018-06-20 06:47:35)

ohnonot · 2018-06-21 05:14:10

johnraff wrote:

meanwhile it would be quite easy to override a file like openbox-autostart with a dpkg-divert.

never knew about that.
debian's package management is really magic.

johnraff · 2018-06-21 05:26:06

Actually, I thought about it a bit more, and I don't think it will be a trivial fix whether done by changing our login-startup process or adding a dpkg-divert to openbox-autostart.

It's made complicated by the architecture-dependent part of the filepath, so our diverting package (if using dpkg-divert) will first have to find where the file is. In bunsen-thunar it was easier because in that case the file only needs to be diverted, ie disabled, but what we want to do here is to modify it, or replace it with a modified version. The whole point of the architecture-dependent library path in Debian is to enable multiple architectures so in fact there could be more than one openbox-autostart! I think in the case of Openbox this is rather unlikely, but still in principle we should cope with it.

OTOH @ohnonot's suggestion of starting openbox without 'openbox-session' would mean we would have to provide a substitute candidate for Debian alternatives' "x-session-manager"; ie a .desktop file in /usr/share/xsessions, a startup script and a substitute for openbox-autostart. A "start-bunsenlabs" script has in fact some appeal, but could otherwise be left till Lithium to think about.

This all seems like a lot of fuss just to add a single "#" to a single file, but the result is worth having from the user experience point of view.

Just post a HowTo?

Just run a hack-script to edit that file with sed, and forget about Debian policy compliance for the year till Buster arrives (when it will no longer be needed)?

Bite the bullet and make a "proper" package to do it cleanly, the Debian Way, and covering all possibilities?

I'd really prefer the last option, but it needs a bit more thought...

ohnonot · 2018-06-21 06:17:36

if it's fixed upstream, what about backports of openbox?
maybe it already exists?
or make it, be it for bunsenlabs only or submit to stretch backports?

johnraff · 2018-06-21 06:33:47

^Indeed a backport of openbox is another option. That would get a few other bugfixes too, and might be the best way.

There's no Debian backport, but I'll have a go at compiling one.

Whether the Big D would accept it for their own repo is another issue though - getting a package accepted is not a simple process, especially for people who aren't DebianDevelopers or Maintainers.

DeepDayze · 2018-06-21 12:33:31

johnraff wrote:

^Indeed a backport of openbox is another option. That would get a few other bugfixes too, and might be the best way.
There's no Debian backport, but I'll have a go at compiling one.
Whether the Big D would accept it for their own repo is another issue though - getting a package accepted is not a simple process, especially for people who aren't DebianDevelopers or Maintainers.

What if you submitted suggested changes along with patches to the maintainer? Most likely you may have to file a bug report including the patches and outlining the changes proposed.

Last edited by DeepDayze (2018-06-21 12:35:00)

hhh · 2018-06-21 14:23:11

johnraff wrote:

Just post a HowTo?

^ This, I would say. No fuss and no responsibility, it's really just a user tweak, after all.

johnraff · 2018-06-22 01:48:15

@earlybird The fix is already in the Buster version of OpenBox, so a simple backport from there would get it. Agreed it's unlikely Debian would consider this important enough to backport it themselves though. (The Buster version's dependencies are satisfied on Stretch so the backport should be trivial to do.)

I was originally thinking of a dpkg-divert of /usr/lib/*/openbox-autostart, but it's complicated by the architecture-dependent element in the path. Unfortunately /usr/bin/openbox-session has to use the right path to call openbox-autostart, so a customized version of that would still need to be separately compiled for each architecture we support, or else do an on-the-fly test of the system architecture.

And /usr/lib/*/openbox-autostart has to be architecture dependent because it calls openbox-xdg-autostart in the same architecture-dependent directory. I've just compared the i386 and amd64 versions of openbox-xdg-autostart and they're identical, though. Unless some obscure architecture's version of the file has to be different (haven't checked arm) I don't see why any of these files have to be under x86_64-linux-gnu or i386-linux-gnu to be honest.

So yes we could do a dpkg-divert on one of the startup scripts, but it might end up being just as complicated as doing a backport of Openbox, no? For a start, I'm going to install the Buster Openbox on this Stretch system as-is and see if any issues come up, then try a backport Buster>Stretch...

johnraff · 2018-06-22 07:54:45

Backported openbox is now available on the experimental helium repo I was using before.
To get it, add:

deb https://kelaino.bunsenlabs.org/~johnraff/debian stretch-backports main

to your apt sources and 'apt-get update'. The repo is pinned at 100, so then 'apt-get install -t stretch-backports openbox'.

This works, and brings in a couple of other small bugfixes in Openbox 3.6.1-7, but I'm not sure if this is necessarily the best way to go. Unless it was put in our main repos (not a good idea IMO), users would still have to go through that process to get it - not really easier than editing a single system file as @hhh suggested.

The smooth login transition is something we want to impress first-time users with, no? So some built-in fix...
...more thought about a dpkg-divert...

Last edited by johnraff (2018-06-23 02:49:40)

verndog · 2018-06-22 14:20:14

johnraff wrote:

When first started up, Openbox sets a default grey background colour which is then overwritten by nitrogen, or any other wallpaper setting app. What this means for BL is a nasty glitch between the LightDm login and the BL desktop wallpaper, when a grey background is briefly shown.
...

Do you know if this happens using xinit instead of lightdm? I should read the bug link.

ohnonot · 2018-06-22 15:18:38

verndog wrote:

Do you know if this happens using xinit instead of lightdm? I should read the bug link.

please read this:
https://forums.bunsenlabs.org/viewtopic … 656#p73656

johnraff · 2018-06-23 03:00:38

earlybird wrote:

Ah, then let's just backport.

Experimentally available here

deb https://kelaino.bunsenlabs.org/~johnraff/debian stretch-backports main

(pinned at 100)
Built on my Stretch system but I had to upgrade debhelper from 10 to 11 first from stretch-backports.
(And 55 other packages needed as build-depends, but everything from Stretch.)

I'll put the source in a GitHub repo today, and you can see if it looks OK. If so, you might consider putting it in the BL repos, either helium (where it would automatically upgrade users' openbox) or stretch-backports (where it would be optional).

The only change I made before rebuilding Openbox 3.6.1-7 was to update the changelog. I added a ~bl to the usual debian ~bpo9+1 suffix just in case a future Debian backport came out in the future.

Last edited by johnraff (2018-06-23 08:14:45)

#1 2018-06-18 03:29:21

[fixed] Openbox sets temporary grey background during startup

#2 2018-06-18 09:28:36

Re: [fixed] Openbox sets temporary grey background during startup

#3 2018-06-18 15:31:46

Re: [fixed] Openbox sets temporary grey background during startup

#4 2018-06-18 15:32:54

Re: [fixed] Openbox sets temporary grey background during startup

#5 2018-06-18 17:08:33

Re: [fixed] Openbox sets temporary grey background during startup

#6 2018-06-18 23:28:02

Re: [fixed] Openbox sets temporary grey background during startup

#7 2018-06-20 03:26:50

Re: [fixed] Openbox sets temporary grey background during startup

#8 2018-06-20 04:02:31

Re: [fixed] Openbox sets temporary grey background during startup

#9 2018-06-20 06:45:08

Re: [fixed] Openbox sets temporary grey background during startup

#10 2018-06-21 05:14:10

Re: [fixed] Openbox sets temporary grey background during startup

#11 2018-06-21 05:26:06

Re: [fixed] Openbox sets temporary grey background during startup

#12 2018-06-21 06:17:36

Re: [fixed] Openbox sets temporary grey background during startup

#13 2018-06-21 06:33:47

Re: [fixed] Openbox sets temporary grey background during startup

#14 2018-06-21 12:33:31

Re: [fixed] Openbox sets temporary grey background during startup

#15 2018-06-21 14:23:11

Re: [fixed] Openbox sets temporary grey background during startup

#16 2018-06-22 01:48:15

Re: [fixed] Openbox sets temporary grey background during startup

#17 2018-06-22 07:54:45

Re: [fixed] Openbox sets temporary grey background during startup

#18 2018-06-22 14:20:14

Re: [fixed] Openbox sets temporary grey background during startup

#19 2018-06-22 15:18:38

Re: [fixed] Openbox sets temporary grey background during startup

#20 2018-06-23 03:00:38

Re: [fixed] Openbox sets temporary grey background during startup

Board footer