GNOME Bugzilla – Bug 710427
Sidebar not shown after start-up although checked in menu
Last modified: 2013-10-22 20:13:14 UTC
This report is about the program starting up, when I click on the file browser symbol in the dash of the GNOME overview with the tool tip: »Files« [1]. Hopefully, Nautilus is the correct product to report this against. If not, please reassign it to the correct product. Using Debian Sid/unstable, where GNOME 3.8 just hit the archives, but Nautilus still is at 3.4.2. Starting that browser, the sidebar is not visible although going to the menu (downwards pointing arrow) the menu entry sidebar is checked. Disabling it and enabling it again, the sidebar is shown. This is reproducible every time the program is started. [1] https://wiki.gnome.org/Design/Apps/Files [2] http://ftp-master.metadata.debian.org/changelogs//main/n/nautilus/nautilus_3.4.2-2_changelog
Thanks for the bug report. Yes, nautilus is the product name for the GNOME «Files» application. However, Debian unstable ships a nautilus version that is too old and not supported upstream anymore (nautilus stable releases are already at version 3.10). GNOME developers are no longer working on version 3.4, so it would be great if you can report this bug to the Debian bug tracking system: http://www.debian.org/Bugs/ Please feel free to reopen this bug if the problem still occurs with a newer version of nautilus.
António, thank you for the quick reply. Does anybody of the developers remember to have seen or fixed such a bug?
Paul, thank you for insisting. This time I tried a different search query and found an earlier report of probably the same bug: bug 699165. Just to be sure it is the same bug, what is the output of the following command in the terminal? gsettings get org.gnome.nautilus.window-state start-with-sidebar
António, thank you for your great support. $ gsettings get org.gnome.nautilus.window-state start-with-sidebar true So bug 699165 indeed looks the same.
(In reply to comment #4) > true Weird, it if were bug 699165, the output would say "false". Perhaps the setting was changed in the meantime... can you still reproduce this bug?
First, I have to correct myself regarding the version. This is Nautilus 3.8.2-2 [1]. I just looked in the Debian package Web interface, which has not yet been updated. > (In reply to comment #4) > > true > > Weird, it if were bug 699165, the output would say "false". It fits pretty well with the error case. The sidebar option has to be toggled twice to be seen. In bug 699165, the sidebar is not there after startup because it is disabled. Pressing F9 to enable it, does not work. Pressing it again, would disable it and then pressing it again would show the sidebar. In this case, that means bug 710427, pressing it the first time would disable it and then again enables it. So it looks like the first sidebar enabling is ignored. > Perhaps the setting was changed in the meantime... can you still reproduce this > bug? Yes, I can. [1] http://packages.qa.debian.org/n/nautilus/news/20131013T161919Z.html(In reply to comment #5)
Can you also reproduce this bug if the setting is "false"? You can set it to false using this command: gsettings set org.gnome.nautilus.window-state start-with-sidebar false To verify the setting was successfully changed, run the command bellow: gsettings get org.gnome.nautilus.window-state start-with-sidebar It should say "false". After trying to reproduce this bug, you can revert it back to "true": gsettings set org.gnome.nautilus.window-state start-with-sidebar true Can you still reproduce the bug after changing back to "true"?
António, I’ll can test that tomorrow. As a side note, on a different not up to date Debian Sid/unstable system with `nautilus` 3.4.2-2 and `gnome-shell` 3.4.2-15+b1 and `start-with-sidebar` set to `true`, everything works. So this seems to be a regression.
António, by the way, what distribution, versions and `start-with-sidebar` setting do you use?
I tested both in nautilus 3.10.0 from Fedora 20 alpha. With "false" there is bug, with "true" there isn't. Which means I can reproduce bug 699165 but not this one. While the symptoms are the same, I'd like to wait for a common fix before marking them as duplicates.
It turns out, I ran the command under the wrong user, which had set it to `true` and not `false`. So it is indeed the same as bug 699165. Sorry for the noise. *** This bug has been marked as a duplicate of bug 699165 ***