| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
A gsetting was previously added for enabling the "Delete Permanently" option in
the menu. Add a checkbox to the preferences dialog that allows users to change
the value of the gsetting.
https://bugzilla.gnome.org/show_bug.cgi?id=759712
|
| | |
|
| |
|
|
| |
It was renamed, but not sure how it managed to stay there.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What we are doing:
Directory starts io.
It cancels the cancellables associated to each async operation.
It starts new operations.
When the new operation finishes, either because it's cancelled or
because it successfully finished, it modifies the directory private
data and sets its associated cancellable as NULL to indicate the
directory that it's all done, so the directory just checks for the
cancellables in its private data to know if there is some operation
going on.
However, what can happens is:
Directory starts io.
It cancels the cancellables and sets as null to start a new operation.
It starts a new operation.
The old operation finishes cancelled, and sets as null the private
cancellable of the directory.
Now the directory thinks there is no operation going on, but actually
the new operation is still going on.
The directory starts io and checks if there is something to stop, but
sees there is no cancellable and keeps going.
Then the new operation finishes and hits an assert when realizes that
the directory state is inconsistent.
To fix this, don't set as null the cancellable in the private data of
the directory when the operation has been cancelled.
It's okay to set as null when the operation finishes succesfully, since
it's ensured that only one operation can be running withouth being
cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=759608
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I always spend some time searching for the files that are the
preferences dialog. Just rename it as it makes more sense to
name it preferences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can return to an old location which happens to be a search
location.
The issue is, we were not updating all the associated properties
of the search when that happened so the window slot and the
files view was in a inconsistent state.
For that, we need the files view to also accept to change to search
locations, in which case it needs to set it's query appropiately
to the query the search location was using.
Thanks to Georges for the initial work on this.
https://bugzilla.gnome.org/show_bug.cgi?id=756183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
How search works:
The main engine starts.
It starts in order all the search providers which start one
or more threads.
Then the owner of the engine can decide to stop, and therefore
requesting the providers to stop.
Then the providers take their time in the different threads to cancel
and to report to the engine, which is the main thread, that they
finished.
At that point the engine signals that the engine is stopped and
finished.
However, if one of the search providers fail to report it's finalization
the engine is hanging forever, making everything stopping to work.
This was the issue when the engine requests the model provider to stop,
and then start again before it got time to request the directory info,
since we add the iddle but never rested it's id, so never signal a finish.
This was working most of the times because, this idle is only requested
when we stop the model provider and it's still running, but usually the
work the model has to do is so little that always gets finished before
stopping it.
So to fix this issue, reset the idle id when finished.
https://bugzilla.gnome.org/show_bug.cgi?id=756183
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It was allocating some variables that weren't used anywhere
in the code. Cleanup those variables and make the code less
cluttered.
|
| |
|
|
|
|
|
|
|
|
| |
We had two files for application related functions, one for actions and
one for the application itself.
Move the actions to the same file so it's easier to scan and share code.
We did something similar to nautilus window for 3.16, and I had this
planned for some time, but didn't get to it before.
Also remove tabs sneakely...
|
| |
|
|
|
| |
Forgot to remove it from gresource. It built succesfully locally because
it was already generated...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current bookmark manager is mostly a "show the internals in the UI",
with just showing the properties in a text base way.
Users can already accomplish the key functions of the manager through
the sidebar: you can rename, remove, and reorder through drag and drop.
The only thing you can't do with the sidebar is edit the path of a
bookmark, but I would argue that that's problematic anyway (since you
can break bookmarks that way, and it is much less error-prone to
navigate to the location and bookmark it than hand edit a location
field).
The fact that the only way to open the bookmark manager is through a
keyboard shortcut is probably a sign that it isn't really getting used
anyway, and that it isn't worth the trouble of fixing it up.
So remove it and instead, if needed, focus on improving bookmarks
management in the sidebar.
https://bugzilla.gnome.org/show_bug.cgi?id=759504
|
| |
|
|
|
| |
So we will be able to remove some of the public API, since we
can use GList functions.
|
| | |
|
| |
|
|
|
|
| |
To be more clear and follow a similar structure than gedit.
Also remove tabs sneakily...
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Major enterprise distributions already moved to gnome 3, and if they
don't already is unlikely they are going to do an upgrade mechanism on
their clients from gnome 2 to gnome 3.20.
So remove the conversion of metadata that was done for initial support
of upgrade from gnome 2 to gnome 3.
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=757826
|
| | |
|
| |
|
|
| |
And fix distcheck.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a file gets moved, nautilus directory cancel the loading of
the attributes of that file, in case that file is in the work queue
of that directory, since it will move to another directory.
For that, we cancel the cancellable associated to the async request
of the attributes of that file.
However, since this is threaded, if some client of the directory kick of
I/O with the nautilus_directory_async_state_changed and the cancellable
didn't reach the callback, the file attributes are still going on, and
we reach an assert when trying to stop them again, since the file
requesting for those attributes is no longer the one we want to stop
loading.
This was causing problems when the race kicks in, for example, the
move to context menu action.
To fix it, apart of cancel the cancellable associated, set the directory
private data files as null, to avoid trying to stop the already stopped
request.
https://bugzilla.gnome.org/show_bug.cgi?id=756253
|
| | |
|
| | |
|
| |
|
|
| |
now that nobody looks
|
| |
|
|
|
|
|
|
|
| |
It was not noticeable enough when a operation started.
For 3.18 we don't have much more room to experiment ways to
increase it, so go for the easier solution and show the popover
when a operation starts.
https://bugzilla.gnome.org/show_bug.cgi?id=753728
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It has been difficult to know the ownership and other things of
nautilus over the time. To not spend again so much time on it, it would
be helpful to have a short overview of nautilus internals.
For that, add a markdown file that explains general concepts and
behaviors of the internals of nautilus.
For now I explained the file, directory and view ownership, to avoid
future confusions and leaks which are kind of catastrophic in Nautilus.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Files attributes in nautilus are cached, and sometimes having a cached
value its problematic for special cases like mounting due to how window
slot mounts locations, which relies in the file not having the mount
information ready, which is not true when the file doesn't get
finalized and doesn't get acknowledge by the volume monitor when its
root gets unmounted.
To avoid that, invalidate all file attributes when changing locations.
A better solution for this specific case would be to make the root
volume monitor to acknowledge all its children when unmounted, and keep
it alive as long as there are children.
But this fix is anyway needed since previous 3.18 is how it was done and
seems it's a needed for now "workaround all" issues with cached values.
https://bugzilla.gnome.org/show_bug.cgi?id=757555
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
For debugging purposes on gdb.
|
| | |
|
| |
|
|
| |
So it's consistent with everywhere else.
|
| |
|
|
|
| |
It's clearly wrong. The TODO doesn't make it better :)
We are leaking few of GFiles already...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of a generic function to filter GLists, implement a simpler
and clearer filter function for file lists, since it was the only
use of that function.
In this way the ownership of files and directories are clearer
since it always returns a new allocated nautilus file list, and also
it always uses nautilus_file_ref instead of the generic g_object_ref
to match what we do everywhere else in nautilus, so it's not confusing
when breaking at nautilus_file_ref/unref for ref counting debugging.
This change fixes multiple leaks on nautilus files catched by valgrind.
|
| |
|
|
|
|
|
|
|
|
| |
Even if we wanted to always use the active window as the default
action to open locations, seems gtk_get_active_windows doesn't work
as expected for us. Until we figure out the problem, pass explicitly
the target slot that the caller provides so users don't experience
the location opening in a different window than the expected.
https://bugzilla.gnome.org/show_bug.cgi?id=756499
|
| |
|
|
|
|
|
| |
If the new window flag is set, make sure that, whatever the caller
pass as target slot, we don't use it.
https://bugzilla.gnome.org/show_bug.cgi?id=756499
|
| |
|
|
|
|
|
| |
This commit updates the GtkPlacesView code
to match upstream's one. The gains:
- Better alignment of labels
- Measurement of available disk space
|
| | |
|
| |
|
|
| |
As requested by Richard Hughes.
|
