| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusView is an abstract class that manages
various context menus, depending on the view's
location, the clicked point and the implementation
details.
While this in theory provides a good isolation
from other classes, in practice NautilusView
manages the pathbar context menu, which is not
necessary, as it doesn't depend on the current
view by no means.
Fix that by making NautilusPathBar manage the
context menu by itself instead of the view. To
cleanly implement that, add a new signal that
matches GtkPlacesSidebar::open-location signature,
and adapt NautilusWindow to reuse the existing
methods to handle pathbar's new signal.
https://bugzilla.gnome.org/show_bug.cgi?id=753158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusWindow immediately displays the newly opened
tab or window and, for that to happen correctly, an
old hack is present.
This hack, however, added some unecessary complexity to
NautilusWindow code, and is completely obsolete nowadays.
It was needed to fix bug 679640, but seems like the real
cause of the bug was fixed and this hack does nothing,
appearently.
Remove the old hack and lets see if will continue to behave
properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus classes add custom methods to grab the focus
differently according to the class.
The problem with this approach, however, is that we end
up with more code coupling, since it's necessary to include
more headers to use the custom grab methods.
To fix that, make classes override GtkWidget::grab_focus
method and remove the custom methods, so widgets can simply
call gtk_widget_grab_focus.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2e1ac98 introduced the new behavior of persistently
storing the show-hidden setting whenever it changes.
This, however, caused an update cycle where NautilusDirectory
tracked the show-hidden change and invalidates the mime types
of the files, sending the apropriate ::file-changed signals.
When NautilusView receives the signals, it unconditionally
updates the action states, which sets the show-hidden action
again, causing another change on the setting and re-triggering
the NautilusDirectory signals, which are detected by NautilusView
and perpetuating the cycle.
Fix that by only storing the show-hidden setting when it
differs from the current one.
|
| |
|
|
|
|
|
|
|
|
|
| |
NautilusWindowSlot currently manages the floating bar,
requiring access to the underlying model of NautilusView
and making the code even more coupled and adding more
complexity to the codebase.
Fix that by delegating the management of the floating
bar to NautilusView itself, and turn NautilusView a
GtkOverlay subclass in order to facilitate the transition.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
NautilusWindowSlot is the class responsible for managing
the empty views, causing even more code coupling and
blurring the lines of functionality of each class. Also,
it requires that the slot access the underlying model
behind NautilusView, something we're avoiding in order
to get Nautilus ready for future modifications.
Fix that by delegating to NautilusView the responsability
to manage the empty views, and not NautilusWindowSlot.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I put a new attribute, but allow_stop is actually meaning the
view is busy. So use that attribute and adjust its behaviour
a little to fix some corner cases.
|
| | |
|
| | |
|
| |
|
|
| |
Since it's only interesting if searched by search relevance.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The first time we create open a location in the slot there
is no view at all...
|
| |
|
|
|
|
|
| |
When the folder the user opens is empty we were providing no
feedback, which cause confusion.
Show an icon with a label for that case, similar to the feedback
we provide when no search results are available.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that we are sure that every time the search directory done-loading
signal is emitted only when the search engine finished successfully,
we can make the floating bar act appropriately, and not hide it
just when the view was done loading new files, but instead when the
search engine actually finishes.
Also, we were hiding the spinner always that we set a file selection,
and selection is necesary to press enter to open the
first search result. Now that we can track if the view is actually busy,
don't hide the spinner even with a selection set.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
So the current view don't keep polling files info while we try
to actually change the location.
This was causing nautilus to be slow like hell on some situations,
since the new location waits until it has it's files info ready
to actually change the view, but the old view was also polling files info.
Given that the priority of both actions are the same, even if they are
in different threads, one of those could cope the other one.
So just avoid this situation (although there is similar issues like this
with the current code...).
|
| |
|
|
|
|
|
|
|
|
| |
Now that stopping the view also stops the model search,
make sure we disconnect from its signals before, so we don't
show the no search results because we got a done-loading
with an empty directory because we stopped the search.
We want to let the view with it's current items, even if the
directory stopped to search and it cleared its files (and therefore
it reports 0 files).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were stopping the loading and searching of the view when location
changed or when location change was canceled, etc.
Before it was fine because stopping the view was not making the
actual directory behind stop.
In previous commits we now make the model stop loading/searching
if the view stops as well, so now that this has a different meaning,
we don't want to stop the new directory, since it could be the one
that will become the current directory.
So just don't stop the current view for simple location changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now we were not stopping the search if no callbacks from clients
were present. That happened when the user canceled the search while the
search directory was waiting for its files metadata, since that async
call was not canceled.
This was actually making nautilus freeze on situations where the search
was so expensive that other threads couldn't cope with it.
To fix it, make sure we stop the search if no clients are present as
callbacks, and make sure we stop the load of the view when we cancel the
async call in the stop_loadin handler of the view.
|
| |
|
|
|
|
|
|
|
|
|
| |
We stop loading the view on destroy, and we add a check on
done_loading to not do some things if we are on destroy.
But the check was checking for the slot not having a window,
which actually has if the view is being destroyed while the slot
is not, like when switching views.
To avoid this crash, mark the model as NULL before all the checking,
and check for the model, not for a window in the slot.
|
| | |
|
| |
|
|
|
|
|
| |
With latests commits we changed the finished signal to report
also the search engine status.
I forgot to change it for the shell-search-provider as well,
which was making nautilus crash when searching on shell.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We recently made a change that the view switchs automatically
to list view if it is searching.
But we introduced a bug, we were setting as default list view in
that case, and therefore if nautilus was closed while searching
the default view mode changed to list view.
Fix that and only set as default list view if we are not searching
and "switch to list view on search" setting is set.
|
| | |
|
| |
|
|
|
|
|
| |
It actually means that there is some data from search engine,
and that is valid and that is ready to be read.
Also add an explanation about why we need this property and
how it works.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It is confusing with all the finished/done-loading signals
all around. This actually what it does is mark the directory as
ready to read from. Also, it connects the pending clients callbacks.
So also factor out it to make sure the difference of those actions.
|
| |
|
|
|
|
|
|
| |
Until now the user was not receiving feedback whether the search
finished or not when there were no results, resulting in an empty view.
To provide a better search experience, provide feedback to the user
in form of a icon + label in the view whether the search finished with
no results.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was working as:
- Search directory starts a new search
- Search engine starts all search providers, each one in its
own thread.
- User changes query
- Search engine stops all search providers
- Searchs providers, since they are in its own thread, cancel
in a unknown time.
- Search directory starts a new search, even before all providers
are finished.
- Search engine is marked as need to restart.
- Search providers finished.
- Search engine emits finished signal, since all search providers
now are stopped.
- Clients doesn't have a way to know if the engine
actually finished searching the current search, or the previous
search that the client asked to stop. That might confuse clients
if they ask for results.
- Search engine restart the search providers without noticing the
client, that thinks that the latest search it started was finished
already.
So to fix this confusion, only report that the engine actually finished
if the engine is not going to restart the search providers.
In this way a client can start a batch of consecutive searches without
the risk of getting search finished signals from previous searches.
Clients now will always get the search-finished signal of the
latest search they started.
|
| |
|
|
|
|
|
|
|
| |
We were emitting the done loading signal everytime the search
directory were ensure loading. But we were ensuring loading in more
cases than it actually done loading.
We are done loading when the search engine finishes. So only emit
the done loading signal at that moment.
|
| |
|
|
|
|
|
| |
We were marking as search finished before the search thread actually
finished the operation.
Wait to mark as finished when the search thread actually reach
its cancel.
|
| | |
|
