| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
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 and an upcoming patch will do
another cleanup.
|
| | |
|
| |
|
|
|
|
|
| |
I pushed the unfinished patch in a wrong checkout.
Push the faulty bits needed to make it complete.
https://bugzilla.gnome.org/show_bug.cgi?id=760790
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
| |
And in same time port away from deprecated override_background_color
function.
https://bugzilla.gnome.org/show_bug.cgi?id=760790
|
| |
|
|
| |
When the operation is finished turn the icon into a "check" icon.
|
| | |
|
| |
|
|
|
| |
These days XDG_CURRENT_DESKTOP can contain multiple desktop names
seperated by ':'.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
No longer using tabs.
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
|
| |
|
|
|
|
| |
So when searching, window-slot is able to get the location.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
|
| |
|
|
|
|
| |
Since now they are the same, just use the public api.
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
|
| |
|
|
|
|
|
| |
Even if we disconnect them on the subclasses, as long as we connect them
here we should disconnect them as well.
https://bugzilla.gnome.org/show_bug.cgi?id=759717
|
| |
|
|
|
|
|
| |
So we have all the disconnection in one place and we avoid
random callbacks while destroying.
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 347369d18eb6 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 864c815479a25 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
|
| |
|
|
| |
It's good to have a way to search for assignments with grep "whatever ="
|
| |
|
|
| |
If not a critical is raised.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus undo manager reuses undo information based on a flag that is pushed
when an undo operation begins and popped during the operation itself. In the
case of trashing / deleting files, the flag was not popped in some situations,
which caused the next operations to not be undoable.
Flip operands of a logical operator so the flag is always popped, avoiding
issues caused by lazy evaluation.
A better solution would be to always update the flag internally in the manager,
and only peek its value externally.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
|
| |
|
|
|
|
|
|
|
|
|
| |
The menu item for this feature was removed in previous versions of nautilus.
A context menu item for creating links from copied files was added, but some
users prefered to create links from selected files.
Since this is demanded, implement the menu action for it and use the gsetting
added in the previous commits.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
|
| | |
|
| |
|
|
| |
Since it's mark down syntax
|
| |
|
|
|
|
| |
This fixes an oversight in commit 0eef086.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
|
| | |
|
| |
|
|
|
|
| |
For the previous patch.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
|
