Fluxbox background disappears on certain events

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

I stopped using Fluxbox a while back, so I don't know if it's still an
issue or not. But you can go ahead and delete/remove the bug report if
you want.

Thanks,
Paul

On 9/5/07, Lionel Le Folgoc <email address hidden> wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Thanks in advance.
>
> ** Changed in: fluxbox (Ubuntu)
> Status: New => Incomplete
>
> --
> Fluxbox background disappears on certain events
> https://bugs.launchpad.net/bugs/69938
> You received this bug notification because you are a direct subscriber
> of the bug.
>

When I start rhythmbox while using Fluxbox, the background wallpaper disappears from the style that I have chosen and displayes the Ubuntu 'default' background. I am running Hardy Heron. This is not a major issue, just a minor annoyance.

Note: I have noticed the above behaviour when using Enlightenment as well.

I have noticed this problem as well. Or something similar. The background wallpaper is replaced with the Ubuntu 'default' background when I start Rhythmbox and, in addition, when I start Nautilus.

In addition, fluxbox actions that require the desktop no longer work. For example, right clicking the desktop should bring up the Root Menu (or at least with the default setup) but it does not. I am still able to bring up the RootMenu using a hotkey. Other actions that require a click on the desktop no longer work. I've also noticed that it interferes with conky. The Ubuntu 'default' background goes over top of the conky output, for lack of a better description.

I've noticed this in both Hardy Heron and in Jaunty Jackalope Alpha 4 (although the conky problem does not happen in Jaunty Jackalope).

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Maverick Meerkat. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Expired for fluxbox (Ubuntu) because there has been no activity for 60 days.]

This problem is still occurring in Trusty, it's extremely frustrating as the inability to get a menu up and running means no programs can be launched other than through a terminal.

Steps to reproduce:

1. Install Ubuntu Desktop 14.04 from latest ISO image.
2. Install fluxbox using: sudo apt-get install fluxbox
3. Select Fluxbox from the list of window managers/desktop environments in the login screen.
4. Launch Nautilus (some other programs have the same effect).
5. Background changes to Ubuntu default wallpaper, can no longer right click to bring up Fluxbox menu.

I'm happy to help test any patches which attempt to fix this bug.

this is not a bug, this is what happens when you have a programm spanning the whole desktop at a layer beneath most regular windows. think about it as having firefox or chrome running in fullscreen-mode below your xterm: what happens if you right-click in the area of where chrome draws its pixels? right, you open the right-click menu of chrome. again: not a bug (in fluxbox), it's just another window covering the rootwindow completely.

regarding nautilus: http://superuser.com/questions/738011/nautilus-changes-my-fluxbox-experience-how-can-i-bring-the-original-configurati

$> nautilus --no-desktop

ticket can be closed from my point of view (fluxbox maintainer)

I'm sorry, but I disagree - this *is* a bug, it involves unexpected behaviour when running an application. That's either a bug with Fluxbox, the application, or the interaction between the two.

However, if the fix is to pass extra arguments to the Nautilus command, perhaps a simple way to close this bug would be to patch the file: /etc/X11/fluxbox/fluxbox-menu, or the script which generates it? If that was done, users would never come across the bug, which is a much better experience than being pointed to a site where the solution is 'run the nautilus command manually with some arguments, create a shell script or patch Nautilus', none of which are particularly helpful to a new user.

I'm happy to submit a patch which does this, although it might take me a week or two to work through the necessary bits of Fluxbox.

(As an aside, the Chrome argument doesn't really address this problem, as I can leave Chrome in full screen mode and get back to the desktop as it was. I cannot do that by quitting Nautilus, unless I run 'killall nautilus', and even then the background image does not return to normal.)

the chrome-argument addresses the problem completely: you have a window completely covering all of the available space. any event on any poin there is handled by the app covering that area. let it be chrome, nautilus or wine (which creates a "virtual desktop" and thus spanning the whole area): the app covering that area receives the events. if you as the user spawn apps which spawn the whole area: what can fluxbox do about it? maximize a regular xterm, put it onto the bottom-layer and the same effect you have with nautilus happens: your clicks are handled by xterm, not fluxbox. if you want to fluxbox' root-menu to popup anywhere you click: bind the RootMenu action to whatever key-mouse-combo you like the most which is not handled by any app that might run at the position you trigger the event.

if you "quit nautilus" and still have nautilus running and covering that area you have not quitted it correctly or completely, it's just that easy. and thus your counter-argument against the chrome-argument is just that: incomplete.

The Chrome argument does not address the problem that if I launch Nautilus from the menu then I can no longer access the menu, even if I quit Nautilus using the standard cross icon in the top right corner of the window. Plus, even if I kill all the Nautilus processes, the background image has still changed.

As I said, that may be a bug with Nautilus instead of Fluxbox, but either way it breaks functionality and changes the user interface. I can't see how that is anything other than a bug. Yes there are workarounds like binding the RootMenu action or passing extra arguments to Nautilus, but these things should not happen in the first place, especially when the fix is to change how the menu is generated.

Use --no-background if you don't want it writing the background. Turns out
using a GNOME component outside GNOME leads to undefined behavior
On Aug 3, 2014 7:15 AM, "pwaring" <email address hidden> wrote:

> The Chrome argument does not address the problem that if I launch
> Nautilus from the menu then I can no longer access the menu, even if I
> quit Nautilus using the standard cross icon in the top right corner of
> the window. Plus, even if I kill all the Nautilus processes, the
> background image has still changed.
>
> As I said, that may be a bug with Nautilus instead of Fluxbox, but
> either way it breaks functionality and changes the user interface. I
> can't see how that is anything other than a bug. Yes there are
> workarounds like binding the RootMenu action or passing extra arguments
> to Nautilus, but these things should not happen in the first place,
> especially when the fix is to change how the menu is generated.
>
> --
> You received this bug notification because you are a member of Fluxbox
> Maintainers, which is subscribed to Fluxbox Project.
> https://bugs.launchpad.net/bugs/69938
>
> Title:
> Fluxbox background disappears on certain events
>
> Status in Fluxbox Window Manager:
> New
> Status in “fluxbox” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a script that randomly selects a wallpaper from my art folder
> and than uses the command "fbsetbg" to set it as my background. This
> script is in my ~/.fluxbox/startup file.
>
> The script runs fine and displays the wallpaper after I login. I
> noticed, however, when I run certain programs (WINE in particular) the
> fluxbox background just disappears, and goes back to a plain gray. I
> am fairly certain the problem is not with the script or the entry on
> my startup file, but I am providing them below anyway.
>
> Here is my startup file:
>
> wallpaper.sh
> gaim &
> xmms ~/music/GamingFMClassicConsoleLowBW.pls &
> swiftfox &
> exec /usr/local/bin/fluxbox
>
> and the script (wallpaper.sh):
>
> #!/bin/bash
> WALLPAPERS="/home/paul/wallpaper" #change this path for your system
> ALIST=( `ls -w1 /home/paul/wallpaper` )
> RANGE=${#ALIST[@]}
> let "number = $RANDOM"
> let LASTNUM="`cat $WALLPAPERS/.last` + $number"
> let "number = $LASTNUM % $RANGE"
> echo $number > $WALLPAPERS/.last
> fbsetbg $WALLPAPERS/${ALIST[$number]} &
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/fluxbox/+bug/69938/+subscriptions
>

--no-background isn't a valid argument according to the man page (on trusty).

a) any process can change the background image. changing the background image is done by drawing pixels to the root-window, any process can do that. and .. to your surprise .. one can do that without detecting the change. and furthermore: how should the window-manager react on the change? obviously the end-user has called a program which set the background, from fluxbox' point of view there is no difference between fbsetbg or nautilus in regards to if they change the background pixels. even IF "the app" (wine or something else) does not write their background pixels to the root-window but to another window in front of the root-window which is NOT handling events (so fluxbox would receive the right-click in that case): we have no means to detect the changes in the pixels belonging to that window.

b) the chrome-argument didn't try to explain the change of background window but addressed the issue that right-clicks are handled by the app covering the area where the end-user clicks with her mouse. if you as the end-user launch any app with maximal coverage of the monitor than you can not right-click the root-window which is what would trigger the RootMenu. you are not considerung right-clicking a regular xterm or a regular sized chrome or a regular sized xyz and not getting the RootMenu a "bug" either, do you? if you launch apps in "fullscreen", this is what you get.

c) fluxbox does not generate the menu used in ubuntu/debian, it is generated by their own mechanism. you can fill a bugreport towards that end, if you like. some other menu-generators are using the .desktop files: fluxbox does not control the content of these .desktop files either, the launch arguments are inside. if you change the general launch arguments there: a regular gnome-user will be very disappointed, i can promise you that.

again: i do not see how fluxbox can handle the things you think are "bugs": fullscreen-apps (no matter on what desktop-layer) will complaint if the right-clicks are not coming through. background-setters would be pissed when fluxbox would reset the background (if fluxbox would be able to reliable detect such changes).

do not think i do not see the problem you have (experience wise), but there is nothing i as the currently active fluxbox maintainer might do about it.

again: nautilus is a file-manager. files. not background-images. not right-clicks on the "desktop". files. if you want to use nautilus and it does the things it does to "increase user-experience" (i can even understand the arguments for spanning the whole desktop) then thats what you get. when i launch an app on my windows-machine (as in windows-the-os) and that app changes the background and spans all space: i am not able to either trigger the regular right-click-menu on the desktop NOR does windows changes back the content of the background). you may not like it, but thats the behaviour you get from app xyz.

the topic of this bugreport is "fluxbox backgrounds change" and from my point of view this can be closed coz it can not be solved: if something sets a new background then thats what happened: something set a new background. case closed.

--*no*-*desktop* - sorry. In the middle of the woods replying on my phone
without much cell service. Had to look up that manpage.
On Aug 3, 2014 7:35 AM, "pwaring" <email address hidden> wrote:

> --no-background isn't a valid argument according to the man page (on
> trusty).
>
> --
> You received this bug notification because you are a member of Fluxbox
> Maintainers, which is subscribed to Fluxbox Project.
> https://bugs.launchpad.net/bugs/69938
>
> Title:
> Fluxbox background disappears on certain events
>
> Status in Fluxbox Window Manager:
> New
> Status in “fluxbox” package in Ubuntu:
> Confirmed
>
> Bug description:
> I have a script that randomly selects a wallpaper from my art folder
> and than uses the command "fbsetbg" to set it as my background. This
> script is in my ~/.fluxbox/startup file.
>
> The script runs fine and displays the wallpaper after I login. I
> noticed, however, when I run certain programs (WINE in particular) the
> fluxbox background just disappears, and goes back to a plain gray. I
> am fairly certain the problem is not with the script or the entry on
> my startup file, but I am providing them below anyway.
>
> Here is my startup file:
>
> wallpaper.sh
> gaim &
> xmms ~/music/GamingFMClassicConsoleLowBW.pls &
> swiftfox &
> exec /usr/local/bin/fluxbox
>
> and the script (wallpaper.sh):
>
> #!/bin/bash
> WALLPAPERS="/home/paul/wallpaper" #change this path for your system
> ALIST=( `ls -w1 /home/paul/wallpaper` )
> RANGE=${#ALIST[@]}
> let "number = $RANDOM"
> let LASTNUM="`cat $WALLPAPERS/.last` + $number"
> let "number = $LASTNUM % $RANGE"
> echo $number > $WALLPAPERS/.last
> fbsetbg $WALLPAPERS/${ALIST[$number]} &
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/fluxbox/+bug/69938/+subscriptions
>