Desktop icons disappearing and freeze on minimize last window

Bug #1394770 reported by H.B. Taylor
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Variety
Fix Released
Undecided
Unassigned

Bug Description

I'm running Ubuntu 14.04 and the default Unity/Compiz UX. If I am running Variety (the latest version from the PPA), Variety changes the wallpaper as it is supposed to, but after a short period of time I notice the following two things:

1. My desktop icons disappear (I have a clean desktop, but a couple of .desktop files)
2. After the desktop icons disappear, if I minimize apps/windows one by one, the last window causes the system to freeze for a moment.

I can clear the freeze by pressing the "window" key on my keyboard, which brings up Dash.

I've done some investigation in general, and it looks like the problem is because of the show-desktop-icons setting in org.gnome.desktop.background. If I execute the following two, commands, the desktop icons come back and I don't see the minimize freeze. But as long as Variety is running, the problem will come back. It doesn't coincide with a wallpaper change, since the icons will disappear at a time when the background hasn't changed.

gsettings set org.gnome.desktop.background show-desktop-icons false
gsettings set org.gnome.desktop.background show-desktop-icons true

 I've had to stop using Variety since I was constantly getting hit by that problem and derailing what I was doing at the time. I really like Variety, and have tried to look into its files, scripts, etc., to see if there was something that was effectively taking over the desktop background drawing that might cause it, but nothing jumps out at me.

Revision history for this message
Peter Levi (peterlevi) wrote :

Please check if this bug and the solutions proposed are applicable for you: https://bugs.launchpad.net/variety/+bug/1317740. There is also some testing with "xrestop" described that is worth doing.

Another thing to try is to comment out everything in ~/.config/variety/scripts/set_wallpaper which is not applicable for Unity (i.e. remove the parts for other DEs, there is a comment before each section). The only part you need is the one for Gnome 3/Unity.

You may add the two lines above (gsettings set org.gnome.desktop.background show-desktop-icons false
gsettings set org.gnome.desktop.background show-desktop-icons true) to this set_wallpaper script as well - this might fix your issue with the desktop icons, but I doubt this will fix the freeze issue.

Changed in variety:
status: New → Incomplete
Revision history for this message
H.B. Taylor (hbtaylor) wrote :

The desktop icons disappearing and the freeze issue on minimizing are actually one and the same. I can minimize the last window all I want as long as the desktop icons are present. As soon as the desktop icons disappear, I can no longer minimize without that freezing behavior. So, I did some further testing. At least on my system, I'm pretty comfortable saying it isn't "Variety causing it", but there is definitely something in the set_wallpaper script that IS the problem.

I quite Variety, so there wasn't anything being done by Variety itself. I commented out everything in set_wallpaper that wasn't for GNOME/Unity, and created a script that called set_wallpaper for each image in a directory structure. It ran set_wallpaper for that image, waited 2 seconds, and then moved to the next one.

The 3 lines of GNOME/Unity commands were the only things executing, and I still saw the problem. So I commented out all but the command that sets the desktop wallpaper. No problem. I did the same for each single gsettings command, and they all worked well through multiple passes through each of my images.

So I enabled the first two commands. They set the desktop wallpaper and the login screen wallpaper. Bingo! The problem occurred. It didn't happen right off the bat, but I would see it within a dozen or so executions of set_wallpaper. I wondered if there was some kind of lock/race condition involved, so I added a second of sleep between those two calls. The problem went away!

So, right now I'm running the set_wallpaper script with all of the non GNOME/Unity stuff commented out, and a second of sleep between those gsettings commands, and it seems to be working. I'm going to do some additional research to see if I can figure out what kind of problem happens in some cases. I'm thinking some kind of file lock that causes gsettings to chase its tail.

I'll update this with anything I find later, but for me a valid workaround was to introduce a short delay between the gsettings calls.

Revision history for this message
Peter Levi (peterlevi) wrote :

H.B. Taylor, that's some amazing debugging job, thanks a lot for the input!

The two lines you talk about are these, right?

gsettings set org.gnome.desktop.background picture-uri "file://$WP" 2> /dev/null
gsettings set com.canonical.unity-greeter background "$WP"

Can you please test something else: remove or comment the one with "com.canonical.unity-greeter" and tell me if your login screen background still changes (please test with the checkbox Customize -> Login screen support both turned on and off). On my machine with 12.04/Unity, this line is actually NOT needed to change the login screen background, and if this is the same on 14.04, I may simply remove it completely from this script, as it obviously causes issues.

Revision history for this message
H.B. Taylor (hbtaylor) wrote :

Yes, those are the two lines. I meant to include them in the prior message, but spaced it.

I did the tests you mentioned. I tried the 4 combinations of "unity-greeter" command and "Customize -> Login Screen". I looked at the lock screen and the login screen.

The lock screen always showed the same background as the desktop, regardless of those two settings. The Login Screen showed the same background as the desktop ONLY if the "Customize->Login Screen" setting was enabled. The "unity-greeter" command had no effect on either of those.

Therefore, I've left it commented out of my set_wallpaper script and removed the 1 second delay. I don't much care about the login screen, so I've left the Login Screen option disabled based on the theory that it is simpler to not have it deal with that.

I still don't know what it really causing the behavior, but I'm glad that I seem to have found a way to avoid it. It feels like some kind of contention issue with the dconf database in ~/.config/dconf/user, but so far I haven't found a way to prove that.

Revision history for this message
Peter Levi (peterlevi) wrote :

Thanks again. Ok, so it looks like we can remove the "unity-greeter" line altogether.
The Login screen option does not too too much - it copied the image file to a folder where LightDM has permissions to read it before it sets it as a wallpaper, this is enough for LightDM to pick it up.

Peter Levi (peterlevi)
Changed in variety:
status: Incomplete → Fix Committed
Peter Levi (peterlevi)
Changed in variety:
milestone: none → 0.5.0
status: Fix Committed → Fix Released
Revision history for this message
Marcelo (warriorfly) wrote :

A similar bug happened to me. I use Ubuntu 4.14, updated to 12.26.2015.

If I let off the following option:
gsettings set org.gnome.desktop.background show-desktop-icons false

and try to minimize the last window the ambient freezes. The animation of the window being minimized freezes and the system does not respond, including the menus. The mouse is still working normal. If I press Ctrl + Alt the system returns in most cases, pursuing animation.

I realized that by enabling the option:
gsettings set org.gnome.desktop.background show-desktop-icons true

causes the system to return to behave normally. This would be a new bug, or relating to this? I do not use Variety.

Revision history for this message
Martin Pecka (peci1) wrote :

I'd say this is caused by https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1276186 . Was the commited fix really a fix or just a workaround? If it's just a workaround, you should mark this bug blocked by 1276186 .

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.