| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This is about doing it from the populate-popup signal from the sidebar, analogous
to commit a73c8c7736cee89bf5470de47aec876b86878bcd.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
|
|
|
| |
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
|\
| |
| |
| |
| | |
Conflicts:
src/nautilus-places-sidebar.c
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Grabbing the focus to a GtkEntry causes its selection to be set which
in turn causes it to reset the IM context. Avoid doing that when we
already have the search entry focused to not mess the IM context.
https://bugzilla.gnome.org/show_bug.cgi?id=698205
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
We don't need to check if the file is in the desktop, since the desktop
view will call in with show_foreign = FALSE already.
|
| |
| |
| |
| |
| | |
When a special desktop item (Home, Trash and the volumes shortcut) is
dragged, only the desktop itself is a valid destination target.
|
| |
| |
| |
| |
| |
| | |
Or moving icons on the desktop itself will break.
https://bugzilla.gnome.org/show_bug.cgi?id=697682
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Since now GdkDisplay objects in GTK have one single GdkScreen, this code
can now be simplified under that assumption.
|
| |
| |
| |
| |
| | |
Since now GdkDisplay objects in GTK have one single GdkScreen, this code
can now be simplified to avoid iteration on screens.
|
| |
| |
| |
| |
| |
| | |
We stopped having pluggable views a long time ago; remove the factory
code completely in favor of a simple nautilus_view_new() that looks at
the specified view ID among the list of views we support.
|
| | |
|
| |
| |
| |
| | |
Reuse a helper we already have for this condition.
|
| |
| |
| |
| |
| | |
There's really no use for this in the current Nautilus, and we're
getting rid of nautilus-view-factory.
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=697252
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When two search results rank equally, we fall back to the collated
order.
Since search is usually ranked reversed (highest at the top), we need to
ensure we don't accidentally reverse the collated order as well.
https://bugzilla.gnome.org/show_bug.cgi?id=688772
|
| |
| |
| |
| |
| | |
Count how many letters are left after the string occurrence, and
subtract that from the match score.
|
| | |
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=680983
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=697108
|
| |
| |
| |
| |
| |
| |
| |
| | |
It's inconsistent with "find" and it can yield to unexpectedly large
result sets.
Do not follow symlinks when recursing the search down the hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=697181
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Code was very fragile and didn't work when the window wasn't initially
realized, such as when launching a search from the Shell provider.
We can get the same effect by moving the cursor at the end of the entry
after the focus has been set.
https://bugzilla.gnome.org/show_bug.cgi?id=697224
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we enabled the Cut action for the Recent location, and kept
Copy and Copy To disabled. This should be the other way around, as
copying a file from there is a valid option, whereas cutting/moving it
doesn't make sense, being a virtual location.
https://bugzilla.gnome.org/show_bug.cgi?id=690138
|
| | |
|
| | |
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=696962
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This is consistent with the Shell and what is used in the
properties/Open With dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=696374
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using an async input method we can't rely on the entry's text or
preedit text being updated as a direct result of processing a key
event.
Instead, we can look at the event keyval and check if it's going to
yield a printable character to decide if we are interested in the
event.
https://bugzilla.gnome.org/show_bug.cgi?id=696260
|
| |
| |
| |
| |
| |
| | |
Input methods will typically only process events after getting focus.
https://bugzilla.gnome.org/show_bug.cgi?id=696260
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the current text in the entry is equal to the new query's text we
shouldn't needlessly set the text on the entry since that affects the
cursor position.
gtk_entry_set_text() already does a similar check internally but that
isn't enough here because NautilusQuery doesn't keep the full string
but instead a stripped version of it.
https://bugzilla.gnome.org/show_bug.cgi?id=696430
|
| |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=696532
|
| |
| |
| |
| |
| |
| |
| | |
So that at least in english locale, entries can fill the width without
ellipsizing.
https://bugzilla.gnome.org/show_bug.cgi?id=696213
|
| | |
|