Bug 993550 - shows grey background when file manager handles desktop
Summary: shows grey background when file manager handles desktop
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 07:23 UTC by udo
Modified: 2015-06-30 00:41 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-06-30 00:41:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description udo 2013-08-06 07:23:18 UTC
Description of problem:
Ever since upgrading to Fedora 19 I do not have a desktop with my own background image but with a grey-ish background underneath the icons

Version-Release number of selected component (if applicable):
gnome-shell-3.8.3-3.fc19.x86_64

How reproducible:
Run Fedora 19 with 'have file manager handle the desktop' enabled as that makes the desktop usable.

Actual results:
Grey background instead of selected image

Expected results:
No grey background but selected image

Additional info:
This is on AMD A10-5800K with ARUBA Cayman-style GPU.
When I right-click the desktop to edit the background the correct image that I chose is shown. When using the 'windows' key to use the menu I also see the correct background.
This issue happens when running radeon (ati) r600 video driver from git but *also* when using llvmpipe (swrast) driver.

Comment 1 udo 2013-08-18 17:03:09 UTC
gnome-shell-3.8.4-2.fc19.x86_64 does not fix this issue. (I restarted the shell after updating)

Why isn't the 'handled' status the default? I.e.: what use is a desktop when there's no stuff on it?

Comment 2 Alexandre Franke 2013-09-16 18:58:46 UTC
Not having icons on the desktop anymore is a design decision. Using the desktop as a place to store things is a bad idea as most of the time it's hidden by windows anyway.

http://3.bp.blogspot.com/_uDrMMyFxly8/TLIUTo710-I/AAAAAAAAAWM/nO1n_il4r2Q/s400/Cluttered+Desktop.jpg is also a good example of how icons on the desktop can be (and often is) abused.

Comment 3 Alexandre Franke 2013-09-16 18:59:42 UTC
http://jeff.ecchi.ca/blog/2010/07/25/desktop-in-the-shell/ gives more details.

Comment 4 udo 2013-09-17 05:29:41 UTC
Please fix the bug.
I.e. do not remove the feature saying it is a design decision, but make it work again as it did in Fedora 17.
Thank you.

What logging, etc, can I provide to help you?

Comment 5 udo 2013-10-06 14:51:31 UTC
The link in Comment 3 is weird attempt at convincing me to get rid of gnome, thus that is not helpful to the project.
How you populate the desktop is your fault.
Starting to write about a feature instead of fixing the bug is weird.
This is basic desktop functionality that has been in GUIs since ages.
Of course you need to take time for all the other important stuff, but failing basic stuff is more important in my eyes than new features.

So what can I do to help this bug to get fixed?
What logging, etc, can I provide to help you?

Comment 6 Florian Müllner 2013-10-24 16:05:38 UTC
(In reply to udo from comment #5)
> So what can I do to help this bug to get fixed?

Assuming https://bugzilla.gnome.org/show_bug.cgi?id=706665, this has been fixed a while ago ...

*** This bug has been marked as a duplicate of bug 1001051 ***

Comment 7 udo 2013-10-24 16:09:08 UTC
What do I need to install to fix the issue?

Comment 8 udo 2013-10-24 16:10:47 UTC
Also: this bug was earlier so it is a duplicate?

Comment 9 Florian Müllner 2013-10-24 16:19:30 UTC
(In reply to udo from comment #8)
> Also: this bug was earlier so it is a duplicate?

The point is:
 - gnome-shell does nothing special regarding the background when
   showing desktop icons
 - desktop icons are implemented in the file manager by opening a
   fullscreen window of type DESKTOP
 - if a window is supposed to have a transparent background, the
   corresponding application needs to request it this way

So the fix needs to be in nautilus, not gnome-shell. If you are anal about bug numbers, feel free to add a reference to the upstream bug here, reassign to nautilus and mark the other as dupe.

Comment 10 udo 2013-10-24 16:23:38 UTC
> So the fix needs to be in nautilus, not gnome-shell.

Thank you for explaining this issue.

Comment 11 udo 2013-12-15 09:13:20 UTC
The fix for bug 1001051 did not help the non-Classic (gnome-shell) issue of the grey background when the file manager (nautilus) handles the desktop.

So I am unsure where the problem lies.
What can I do to help find the root cause?

Comment 12 gustavo 2014-01-16 14:42:16 UTC
fedora 20 + oxygen-gtk make it happen again :(

Comment 13 udo 2014-02-17 07:41:45 UTC
Problem persists in fedora 20:
$ rpm -q nautilus
nautilus-3.10.1-3.fc20.x86_64

Please fix.

Comment 14 udo 2014-03-16 13:00:03 UTC
Any updates?
Stuff we can try to help find the root cause?

Comment 15 udo 2014-06-08 13:49:50 UTC
What logs do you need to fix this bug?

$ rpm -q nautilus
nautilus-3.10.1-4.fc20.x86_64

Comment 16 gustavo 2014-06-09 10:17:35 UTC
bug still present in fedora 21 (rawhide - 09/06/2014) when nautilus used with oxygen-gtk

Comment 17 Matthias Clasen 2014-06-10 13:43:23 UTC
Lets move this bug to where the fix is needed, then

Comment 18 udo 2014-06-10 14:26:22 UTC
Euh...
$ rpm -ql oxygen-gtk
package oxygen-gtk is not installed
$

Comment 19 Rex Dieter 2014-06-10 14:46:57 UTC
try instead:
rpm -q oxygen-gtk2 oxygen-gtk3

Comment 20 udo 2014-06-10 14:54:34 UTC
$ rpm -q oxygen-gtk2 oxygen-gtk3
package oxygen-gtk2 is not installed
package oxygen-gtk3 is not installed
$

Comment 21 Rex Dieter 2014-06-10 16:34:52 UTC
It would appear comment #16 isn't valid (for all reporters here at least).

Back to nautilus.

Comment 22 Florian Müllner 2014-06-10 17:23:21 UTC
(In reply to udo from comment #20)
> $ rpm -q oxygen-gtk2 oxygen-gtk3
> package oxygen-gtk2 is not installed
> package oxygen-gtk3 is not installed
> $

But are you using Adwaita? If not, than a theme issue still seems likely (just one that is not exclusive to oxygen-gtk) ...

Comment 23 udo 2014-06-10 19:15:52 UTC
$ rpm -qa|grep adw
adwaita-gtk3-theme-3.10.0-2.fc20.x86_64
adwaita-gtk2-theme-3.10.0-2.fc20.x86_64
adwaita-cursor-theme-3.10.0-2.fc20.noarch

But I believe I use clearlooks:
$ rpm -qa|grep clear
clearlooks-phenix-gtk3-theme-3.0.15-2.fc20.noarch
clearlooks-phenix-common-3.0.15-2.fc20.noarch
clearlooks-phenix-gtk2-theme-3.0.15-2.fc20.noarch
clearlooks-phenix-metacity-theme-3.0.15-2.fc20.noarch
$

Comment 24 udo 2014-06-10 19:28:30 UTC
gnome-tweak-tool shows:

theme

Window  Clearlooks-Phenix
GTK+    Clearlooks-Phenix
Icons   Gnome
Cursor  Adwaita

Comment 25 udo 2014-06-11 14:45:05 UTC
Which theme is relvant?
I could try to select an other theme to see if that fixes the situation..

Comment 26 Matthias Clasen 2014-06-11 18:05:52 UTC
Please try Adwaita as GTK+ theme

Comment 27 udo 2014-08-28 15:03:07 UTC
Did so.
Restarted the gnome shell.
No change.

Comment 28 udo 2014-09-27 10:14:13 UTC
Any more tests I could do?
Any progress?

Comment 29 udo 2015-01-08 16:34:10 UTC
What tests I could do?
What progress can we achieve?

$ rpm -qa|grep clear
clearlooks-phenix-common-5.0.7-1.fc20.noarch
clearlooks-phenix-gtk3-theme-5.0.7-1.fc20.noarch
clearlooks-phenix-metacity-theme-5.0.7-1.fc20.noarch
clearlooks-phenix-gtk2-theme-5.0.7-1.fc20.noarch
$ rpm -qa|grep adw
adwaita-gtk3-theme-3.10.0-2.fc20.x86_64
adwaita-gtk2-theme-3.10.0-2.fc20.x86_64
adwaita-cursor-theme-3.10.0-2.fc20.noarch
$ rpm -q nautilus
nautilus-3.10.1-4.fc20.x86_64

Anything else?

Comment 30 udo 2015-01-08 17:01:59 UTC
$ rpm -q gnome-shell
gnome-shell-3.10.4-9.fc20.x86_64

Perhaps?

Comment 31 gustavo 2015-01-08 18:40:47 UTC
Still the same when using oxygen-gtk.
Screenshot here: http://pccito.ugr.es/~gustavo/bug/993550.png
Now on Fedora 21 (updated today).

[gustavo@pccito ~]$ rpm -qa | grep clear
[gustavo@pccito ~]$ rpm -qa | grep adw
adwaita-gtk2-theme-3.14.2.2-1.fc21.x86_64
adwaita-icon-theme-3.14.1-1.fc21.noarch
adwaita-cursor-theme-3.14.1-1.fc21.noarch
[gustavo@pccito ~]$ rpm -q nautilus
nautilus-3.14.2-1.fc21.x86_64
[gustavo@pccito ~]$ rpm -q gnome-shell
gnome-shell-3.14.3-1.fc21.x86_64
[gustavo@pccito ~]$ uname -a
[gustavo@pccito ~]$ cat /etc/fedora-release 
Fedora release 21 (Twenty One)

Comment 32 gustavo 2015-01-08 18:42:26 UTC
killing nautilus background came back

Comment 33 udo 2015-01-17 06:06:21 UTC
Suddenly, after booting into 3.18.2 that I compiled, the grey background is gone.
I cannot correlate this (yet) to recently updated RPMs.

Comment 34 Fedora End Of Life 2015-05-29 09:17:16 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 35 udo 2015-05-29 12:35:48 UTC
No deep insights?
Questions?

Comment 36 udo 2015-06-01 13:36:14 UTC
And the problem is back after updating to fedora 22.

Comment 37 Fedora End Of Life 2015-06-30 00:41:23 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.