Package: fluxbox Version: 1.3.2-2 Severity: normal Tags: patch Hello!
I found out that fbsetbg may in some cases mess up with the user's
~/.fluxbox/lastwallpaper
This misbehavior is caused by the fact that the DISPLAY environment
variable is in the form hostname:displaynumber.screennumber
where .screennumber _may_ be omitted, as long as it's .0 , as
documented in the X(7) man page.
This means that :0.0 and :0 are equivalent.
I am not sure why, but it happens that sometimes the DISPLAY
environment variable is set to :0 , while in some other cases
it's set to :0.0 , in a seemingly inconsistent and unpredictable
manner.
As a consequence, taking fbsetbg code into account, the following
scenario may happen (I actually saw it happen, and I couldn't
understand what was going on, until I studied the fbsetbg code).
The user opens a Fluxbox session and he/she has:
$ echo $DISPLAY
:0.0
The user wants to set the following wallpaper:
$ fbsetbg -t /path/to/my/old/wallpaper.jpg
The wallpaper is set and remembered for the :0.0 display:
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
Good, everything is fine, the user does what he/she has to do and then
exits from Fluxbox.
Next time the user opens a Fluxbox session, the last set wallpaper
is remembered and set again, since:
$ grep rootCommand ~/.fluxbox/init
session.screen0.rootCommand: fbsetbg -l
After some time, the user wants to change wallpaper and issues
the following command:
$ fbsetbg -t /path/to/a/new/nice/wallpaper.jpg
What happens if, in this new Fluxbox session, the user has
$ echo $DISPLAY
:0
?
It happens that fbsetbg fails to see :0 as equivalent to :0.0
and does not replace the previously set wallpaper with the new one.
It just adds the new one, as if it were set for a different display!
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
$tile $full|/path/to/a/new/nice/wallpaper.jpg||:0
There! From this point on, depending on the DISPLAY value, the
wrong wallpaper may be set, when a new Fluxbox session is opened.
After studying the problem, I prepared the attached patch, which
fixes the issue for me and works in a backward-compatible way.
The idea is to always truncate the final .0 , if present, so that
screen 0 is always named in the same consistent manner within
the fbsetbg script.
In order to be backward-compatible, the script searches for $DISPLAY ,
but also for ${DISPLAY}.0 , in ~/.fluxbox/lastwallpaper , when
it has to replace an old wallpaper with a new one.
Please apply the patch to the Debian package and/or forward it
upstream.
Little legal details: I think my modifications are too trivial
to be copyrighted by me. Hence, you don't need any license from
me, in order to distribute fbsetbg with my patch applied.
Anyway, in case my modifications turn out to be in fact copyrighted,
I hereby license my patch under the same exact terms as fbsetbg
itself.
Thanks for your time!
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fluxbox depends on:
ii libc6 2.13-21
ii libfontconfig1 2.8.0-3
ii libfreetype6 2.4.8-1
ii libfribidi0 0.19.2-1
ii libgcc1 1:4.6.2-7
ii libice6 2:1.0.7-2
ii libimlib2 1.4.4-1+b1
ii libsm6 2:1.2.0-2
ii libstdc++6 4.6.2-7
ii libx11-6 2:1.4.4-4
ii libxext6 2:1.3.0-3
ii libxft2 2.2.0-3
ii libxinerama1 2:1.1.1-3
ii libxpm4 1:3.5.9-4
ii libxrandr2 2:1.3.2-2
ii libxrender1 1:0.9.6-2
ii menu 2.1.46
ii zlib1g 1:1.2.3.4.dfsg-3
Versions of packages fluxbox recommends:
ii feh 2.1-1
ii xfonts-terminus 4.30-2
Versions of packages fluxbox suggests:
pn fbautostart <none>
pn fbdesk <none>
pn fbpager <none>
-- no debconf information
fbsetbg.diff.gz
Description: GNU Zip compressed data
