I also see the same, nautilus does not open when it is managing the desktop.

Same problem here.

When "show-desktop-icons" is set in "org.gnome.desktop.background", (e.g. via tweak tool "Desktop -> "Icons on Desktop") nautilus is started with command "nautilus -n" during gnome startup (via "nautilus-autostart.desktop").
From "nautilus --help":
-n, --no-default-window     Only create windows for explicitly specified URIs

I.e. when no URI is specified, no nautilus window is displayed - typing "nautilus" does nothing, typing "nautilus ~" displays nautilus window.


Issue:
when nautilus is started with "nautilus -n"
* clicking on "Files" icon in dash or launching nautilus from overview does nothing (no window is displayed)
- expected behavior: nautilus window is displayed
* right click on nautilus icon in dash and selecting "New Window" does nothing
- expected behavior: new nautilus window is displayed
* when nautilus window is displayed on inactive workspace, clicking on nautilus icon in dash does nothing
- expected behavior: switch to workspace with nautilus window, nautilus window is active


Steps to reproduce:
* set "show-desktop-icons" in "org.gnome.desktop.background" (e.g. via tweak tool "Desktop -> "Icons on Desktop")
* logout & login to gnome
* type "pgrep -a nautilus" and check that nautilus is started as "nautilus -n"
* try to launch nautilus from overview
* try to launch nautilus from dash
* launch nautilus from terminal by typing "nautilus ~"
* right click on nautilus icon in dash and select "New Window"
* switch to another workspace and click on nautilus icon in dash

Seems to work if nautilus is started with "nautilus --gapplication-service"

Quickly looking at the code, nautilus_application_activate() seems to return immediately if the -n (no_default_window) is set to true. I guess it should make the distinction between the first time nautilus is started and the following activation?

I didn't tried to bissect this, but my wild guess is that the issue is coming from:

commit 4e192481ebb5ac374c83a7280c8ce6aa3ce12687
Author: Cosimo Cecchi <cosimoc@gnome.org>
Date:   Tue Apr 29 03:56:15 2014 -0700

    application: minimal port to handle_local_options()

I've also this bug

Possibly related to Bug #738280 which was fixed in 3.14.1

No, in my tests the restore --new window was not sufficient.

On my system for now I changed
nautilus -n (in nautilus-autostart.dektop) to nautilus --gapplication-service; this seems to help it (good enough) to allow to have desktop icons AND be able to launch nautilus later on.

*** Bug 740247 has been marked as a duplicate of this bug. ***

Created attachment 290900 [details] [review]
nautilus-application: Create an option to manage icons

Until now we were using --no-default-window in cases when we wanted to
manage the icons on the desktop, which is the most common use case of
this setting. But the logic of this setting was creating some problems
to this use case.

The problems were:
- When using --no-default-window in the desktop file, the user couldn't
open a new window of nautilus, since the only window allowed was the
desktop one.
- When set in gsettings after an instance is running, it created a new
window due to activating the application.

Instead of that, change the setting to an appropiate name and
description and manage those cases.

I'm happy with the ~/.config./autostart/nautilus-autostart.desktop workaround for now:

Exec=nautilus --gapplication-service

Created attachment 291004 [details] [review]
nautilus-application: Don't trigger activate signal for -n option

Until now we were using --no-default-window in cases when we wanted to
manage the icons on the desktop, which is the most common use case of
this setting.

The problems were:
- When using --no-default-window for the first inscante, the user
couldn't open a new window of nautilus, since the only window allowed
was the desktop one in the first instance. The code was just early
returning in activate if the private setting of the instance is set.
- When using --no-default-window for the consecutive instances after
starting nautilus without --no-default-window it was creating a new
window anyway, since the first instance doesn't have the setting set in
its private and the second instance was just calling the activate of the
first instance. For instance that was happening when the user
activate/deactivate the show-desktop-icons gsetting, since the
nautilus-autostart desktop file was running nautilus
--no-default-window, but the first instance was a instance withouth the
--no-default-window.

So the solution for both cases is avoiding calling activate if the
--no-default-window is an arggument, instead of a private setting of the
instance.
To avoid calling activate we can return a value less than 0 to the
GApplication in the handle_local_options function. So if the
--no-default-window is passed as an argument, we just skip the activate
call.
Since when launching consecutive instances they take care of its own
handle_local_options they can skip as well the activate call redirected
to the first instance.

Big thanks to Ray Strode for discussion, debugging and base of this
patch, and Debarshy Ray for discussion and debugging.

The first patch attached here was using the old way to try to workaround the problem.

But it was a little hackish and we were keeping a boolean attribute in the object which is actually don't needed.

The last patch fixes those "hackish" things using GApplication details and delete the attribute from the class.

Review of attachment 291004 [details] [review]:

Thanks for looking into this. Looks good to me.

*** Bug 740391 has been marked as a duplicate of this bug. ***

Thanks for review Cosimo!

Attachment 291004 [details] pushed as ae4d496 - nautilus-application: Don't trigger activate signal for -n option