We were peeking the filesystem type synchronously since nautilus
was checking for some file infos that are only required once
synchronously. However the call for the filesystem is usually slow
which makes nautilus main thread hang.
To avoid I/O in the main thread, make the filesystem type request
asynchronously and part of all the others attributes for the file.
https://bugzilla.gnome.org/show_bug.cgi?id=756280
We were not taking into account the time the operations
takes to prepare the operation itself. That makes big
operations take more time than needed for show the toolbar
operations button feedback than expected (2 seconds).
Fix that exposing a new timer that takes into account all
the time since the start of the operation and use that
for deciding when to show the file operations toolbar button
or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756096
We were using as default that we can trash files, and after
we only set the if it is possible to trash or not if the filesystem
reports that has the info.
In most of schemes that the trash is not supported, the filesystem
actually don't have that info, making can_trash true and providing
the option on nautilus context menu, which does nothing.
Default to not being able to trash to avoid this situation.
We changed the meaning of remote from being only network://
to be a lot of schemes.
Thing is, the properties action was disabled for "remote", and
now that means lot of locations.
I think there is not enough reason to disable properties altogether,
if the network:// file doesn't provide enough info, probably it should.
We were disconnecting all the signals on dispose, except
the ones that comes from the widgets and are added with
gtk_widget_class_bind_template_callback. Therefore those
can be emitted after a dispose.
In the toolbar case, we connect to the toggle signal of a
button, which when the toolbar gets disposed, the buttons gets
untoggled and the signal is emitted, then the toolbar tries to
perform actions on external data that was cleared already on dispose.
To avoid that, just clear the data on finalize instead of
dispose.
In done_loading we check for floating bar and empty states.
In case the directory doesn't exists anymore in this case,
we cannot do that (without adding bunch of if's).
So instead reorder the unrefing so the directory is alive
when all the checks are performed.
This fixes seeing the floating bar when a directory fails to
load because the user doesn't have permissions.
https://bugzilla.gnome.org/show_bug.cgi?id=755207
Lately we did some changes on the view/slot/window/app
interaction with the directory/model ownership. That means
that now most of the times the directory/model is freed when
it should.
In this case, when loading the children of a directory reports
an error, say the user doesn't have permission to access the
directory, the view unref the directory in the signal callback,
and any further interaction with it by the directory itself after
signaling becomes accessing invalid memory.
To avoid this, the directory should have a ref on itself for any
signal that can cause the owners of it to unref.
https://bugzilla.gnome.org/show_bug.cgi?id=755207
I have been going back and forward on this. And even if
I strongly think this is not good enough to be in the default
installation of Nautilus, removing 'features' or behaviors that
users were used to without providing a good alternative is even worse.
Probably Nautilus didn't have such high standards when this was
implemented, and this behavior was accepted even that emails from
usability and accessibility were asking to not do it, but it was done
given that no alternative was possible because of Apple patents on
'spring folders'.
So final decision from my side and after discussing it with some
people, is to continue shipping it by default until we have a better
solution.
The setting will be still there as 'open-folder-on-dnd-hover' and
can be modified by the user using dconf.
Discussions for better solution will be followed in
https://bugzilla.gnome.org/show_bug.cgi?id=754455
Currently the dnd on the sidebar is only triggered when hovering
above the sidebar itself. However we would like to give some
feedback all along on the dnd operation.
For that GtkPlacesSidebar has set_drop_targets_visible public API,
which was implemented a few months ago and the GtkFileChooser is
already using.
I just forgot to implement the support for it on Nautilus... even if
the original work was done for Nautilus, since users will probably
use dnd more on nautilus than on the file chooser.
I'm not entirely happy with the implementation, since it uses custom
functions to access the drag data, given that we need them at drag-begin
time and in random places on the code, since nautilus is doing all the dnd
work manually and on different places.
The final result is that drag and drop is still managed mostly on its own
widgets, in this case list-view and canvas-view, and nautilus-dnd manages
a central accessor for dnd in nautilus, in this case requesting depending
on the widget that is the owner of the data, its data through the custom
functions of that particula widget. All other ways I tried to do it entirely
with only gtk_drag_* or gdk_drag_* functions were in vanish if no a complete
refactoring is done, and probably it doesn't worth the effort. Also I
actually separated the list view dnd code as well, so now at least the
pattern to handling dnd on nautilus is more or less consistent.
Sometimes is reported that there are not items as sources.
That makes nautilus crash trying to iterate betweeen them
in nautilus_drag_default_drop_action_for_icon.
Even if the fix should be there, it's a situation that
shouldn't happen at all, so I leave it as a responsability
of the caller.
When relayouting we want to finish adding and layouting
the previous layout, but sometimes we can try to layout
when it's actually not possible to create a grid, for
instance if the size of the desktop is not enough or is
not yet allocated.
To prevent that, return early if we try to relayout in
that case and schedule a relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=755582
We were using the internal list of the application to
iterate through the windows and closing them.
Problem is that when closing one window, the list is modified,
so next time accessing the list we are accessing the "old"
list, which is invalid and makes nautilus crash.
To fix it make a copy of the list to preserve the consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=755803
It's still not ideal, since we would like to be on the middle of the
label. But is better than what we have... (and hopefully we will
have listbox for next release and this shouldn't be a problem)
https://bugzilla.gnome.org/show_bug.cgi?id=754620
Most of the times we were using as a location the invented
uri for the search directory as a model for the search, which
is wrong and the search was no returning results and the view
loading the cached files.
Before the window slot changes done a few weeks ago this was fine
because we didn't set more than once the location of the query editor
in a single search. So we were protected about this situation.
However now with the isolation of the model, the window slot is unaware
of the details of the model (if it is an invented uri or not) so can't
control that.
To fix it, make the query editor aware of the type of model used, and in
case of it being a search directory, use the base model as a location
for the search, and if not, use the file location uri.
https://bugzilla.gnome.org/show_bug.cgi?id=755336
