Remote locations by default don't handle recursive search, since
it has high costs associated. We can't, however, neglect the ability
to search recursively on those folders, nor share the same setting
with common folders too.
To fix that, add a new setting called "enable-remote-recursive-search"
which will be used by the next commits to properly implement recursive
search for remote locations.
GTK+ 31cc642288a4b707bd1400dc258c47f7cfa82829 commit rewrited
notebook style and now background color is set on notebook > stack.
Update css rule to remove background also from stack.
To snap an icon to the closest grid cell, we were trying to round
the x position with an offset of 0.5. However, cells are not
normalized, so that 0.5 is actually doing little to round the
position.
This is making the icons to snap to the right closest cell once the
user drags more the icon left to the current cell.
The actual size of the cell is SNAP_SIZE_*, so to fix this use half
of the SNAP_SIZE to "round" the number.
https://bugzilla.gnome.org/show_bug.cgi?id=750446
This adds the "nautilus-window" styleclass to the main Nautilus window.
This commit provides a way for third party themes to apply their
own custom styling to Nautilus by using the newly introduced styleclass,
since the inbuilt Adwaita.css stylesheet is only being loaded when
the Adwaita theme is used.
https://bugzilla.gnome.org/show_bug.cgi?id=761098
The view doesn't display files while it's loading, and that's
mostly fine and what we want to avoid jumping while seeing new
files.
However, the when searching, it's expected to not all files be there,
and the first ones reported by the search system have a higher score
to appear, so that means it's fine if the user doesn't see files with
low score while files with high score are presented.
On the other hand, is not fine to wait until the search system
stops to show all the files that were found.
So for search we want to show files while they are being loaded, that
means the directory doesn't have the all_files_seen flag set.
Previously, we were solving this issue setting the all_files_seen
flag in the search directory so the view will show them when hits
are added. However, that also means the view thinks the loading is
complete, removing the floating bar and any hint that it was loading.
So what we actually want is special case the search, and show the files
while they are being found.
The previous patch reverted the change to mark the search directory
as all_files_seen to be consistent. This patch makes the view display
files while they are being found.
We were marking as all_files_seen when hits were added, so the view
will react on it and display the files that were recently added.
However, that's not consistent, and the view calls done_loading
if all files are seen. This has, as a UI effect, removing the floating
bar, and therefore any hint that the view is still loading/searching.
So let's be consistent here and in the upcoming patch we will fix
this issue with the search.
There is code that is used in case FAM is not available. But
we use inotify since 2006, so I'm confident we are fine without
checking for it.
This remove some not needed code.
There is some css that nautilus wants to always use regarding
of the theme that is used.
An example of this is the recently css added for making the desktop
backgrund transparent.
Additionally, the "round button" css is also always wanted.
For that, create a new css file that will have the css we want
to always load and load it in the application initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=760790
We were not disconnecting them, so they could be called after
the search-directory is freed, causing a crash.
To be honest, not sure how it survived until now, probably because
previously (I didn't check) the search engine was freed when stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
We were leaking it in these cases. But we need to make sure
we don't free the directory if we are using the same as the
internal one. So manage that in the load_directory as a generic
function.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
This is the last patch of a series of patches to fix all the
related issues with search synchronization, robustness on search, etc.
This patch orders fix when the view is requested to load a search
directory.
This is tricky because the views expect real locations, and when a
caller sets the view to start searching the view expect to already have
a real location loaded, so it can set the invented search directory with
the model as a backing uri.
In the case that window slot request a search directory, we are screwed,
because either we load first the real backing uri, which will screw
the window slot and all of the connected users of the view when the
is-location signal is done, or we first set the query and then load the
search directory, which will screw it anyway because the real location
set up at that point in the view is not the one associated with the
search directory.
So we effectively need to do both at the same time.
To do that, implement a set_search_query_internal which will allow us to
pass a backing uri, so when the slot sets a location that is a search
directory, instead of loading the directory itself, we only set the
query indicating the real location behind, so it can set up everything
in the search directory before loading it.
This patch was done with a few things in mind, and it actually fixes
few other issues. For example, now then we reuse the directory from the
slot, we actually create a new search directory, so we actually don't
reuse it. The point for this is because if we reuse the directory, any
stop to the search directory will stop the future search that we just
set. This happens when the slot stops the old view to load (which had
the same search directory before this patch) after setting the new
view to load.
A better fix would be to get rid of the nautilus-search directory
invention or to make it only internal, and make the window-slot be aware
when a location was also searching (with a struct instead of using
nautilus-bookmarks).
https://bugzilla.gnome.org/show_bug.cgi?id=759717
Nautilus slot ends any location change before starting a new
one or when is done loading.
The done loading signal is emitted when the view finalize to load
a directory.
However, when loading a new location, if the previous one was not
finalized to load, nautilus was crashing, due to the is-loading signal
in the view first emitting it for finalizing the previous location
change.
Then the callback of window slot was freeing the new_content_view,
because this callback can be done when canceling a location change.
However, at that time, the new_content_view is actually the one which
is going to be used as a content view when we are just changing
locations, for example, while searching.
It's kind of strange that the callback of the view ending a load
frees the new_content_view, since this is already managed by setup_view.
And since we already have a cancel_location_change, we can use that
on the majority of situations when we actually want to cancel a change,
and let the end_location callback for the specific case of ending a load
of the view.
So now only the cancel_location_change frees the new_content_view, and
we avoid a crash freeing the current view while loading it when changing
locations.
This is the last patch of the series of patches to fix the crashing
nautilus while searching.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
So we were relying on the model to be NULL to not update all
the view widgets and details in the done_loading callback.
However, we need the model alive so in the signal of is-loading
emitted on the done_loading function, external objects can peek
the model, etc. even in destruction time.
So instead of setting the model as NULL on destroy and relying on it,
use a explicit boolean to not update view widgets on destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
Dispose is intended to let the object still valid for external
calls.
Freeing the action group on dispose makes the view somehow invalid,
so some calls were made at that time and were making the view to crash.
This change to dispose was made in commit 347369d18e to fix a crash as
well. However, an upcoming patch fixed it as well as noted in the
commit message.
So although dispose seemed good, it's not if it makes the object
invalid.
On the other hand, instead of dispose we should use destroy, since we
are already using it, and implementing dispose was kind of an error.
In upcoming patches we will move some disconnect_signal calls from
finalized to destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
When building the scripts menu, update_directory_in_scripts_menu()
gets the list of files in the script directory, filters out hidden
files and sorts the filtered list by display name. Unlike the filtering
step, which returns a new list with ref'ed files, sorting may change
the start of the list, but not the list's actual content. As a result,
the nautilus_file_list_free() call added in commit 864c815479 tries
to free already freed memory (i.e. disposed files), resulting in a
crash when any scripts are found.
https://bugzilla.gnome.org/show_bug.cgi?id=760338
Nautilus undo manager previously relied on a stack-like implementation of its
operating state. The stack operations (pushing and popping) were removed in a
previous commit due to possible unexpected behavior and errors. The flag alone
now has an inadequate name for what it represents.
Rename the flag to "is_operating", since it is set when the manager is
performing an undo / redo operation and unset otherwise. Rename the associated
getter function accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
Nautilus undo manager reuses undo information based on a flag that marks whether
an undo / redo operation is currently being performed. Previously, the flag was
managed both internally and externally. This proved to be unnecessary and even
harmful, as it led to an unexpected behavior.
Remove push and pop functions and handle the flag explicitly, at the start and
at the end of an undo / redo operation. Replace external use of pop with the use
of a getter function, also introduced in this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
When thumbnailing a directory with jp2 some times nautilus
was crashing.
However tests on gdk_pixbuf were successful and gnome-desktop-thumbnails
generation tests were also working.
Also, nautilus is using raw pthreads in the thumbnail generation
code, and seems the crash was actually only happening when inside the
pthread and when using gdk-pixbuf, not only the gnome-desktop-thumbnail.
Looking at the implementation of glib in threads and nautilus, one of
the differences is that nautilus sets a stack size.
The crash is happening because, unluckely, libjasper with some big
images is using more stack size than the one nautilus is setting, which
leads to a crash in libjasper.
To fix it, remove the stack size set by nautilus, similarly to what glib
does, not setting an actual stack size.
Obviously the right thing to do is rewrite nautilus code to use the
glib threads, but I want to let that as a newcomer bug to do.
