GitLab

Why on earth should it be somewhere else?

It will take care of the various states of file operation progress' user
interface.

The unmount process follows this flow:
- pre-unmount is emitted
- GIO performs checks to see whether the volume is safe to unmount, and
  spawns GtkMountOperation dialogues accordingly
- if everything is fine, the unmount signal is emitted

So, it's wrong to close or redirect windows from pre-unmount, as the
mount could actually not be unmounted after that.

GCC 4.6 introduced a new warning about variables declared and
initialized, but not really used in the function body. Remove all of
these occurrences to build cleanly.

Now that we're a single-window application, this has become much more
relevant.

And move them outside of src/file-manager

Part of the final step towards removing src/file-manager completely;
only code shuffling around, not any real code change.

EggSmClient is not well-maintained, and it doesn't seem like it will
ever hit GTK+, and the overall implementation seems to be poorly tested
and buggy.

Moreover, moving to 3.0 with nautilus being an application, it makes
less sense to have it save opened windows state, as it might not be
always running at all.

It makes no sense now that nautilus doesn't do session services such as
autorun anymore.

Instead of calling _release().

This is part of the 3.0 redesign plans.

This way we lose ability to focus already open windows after mount.
Since gnome-settings-daemon uses default folder handler to show freshly
mounted folder, there's little we can do.

The porting to GApplication broke the session management code that took
care of saving and loading existing windows if the session saving is
active.

We now fix it by changing a bit our startup process, so that the
EggSMClient object is actually created at the right time.

Use late-initialization, otherwise we and up locked while reading
session information. Also, don't try to use that information more than
once in the app lifetime.

If it's set, we quit immediately.

As we're building the NautilusUndoManager in _startup() now, which might
not have been called if the application is remote.