| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Replace the eel_boolean_bit typedef with a plain guint and remove all
includes.
|
| |
|
|
|
|
|
|
| |
There are a few non-braced single-statement in the final cases, which
have gone unnoticed until detected by a recent uncrustify update.
Let's add the missing braces around single-statements even if it's the
last case.
|
| |
|
|
|
|
|
|
|
|
| |
We have been using doubly-linked lists to store MIME type names strings.
But this is not a great container for strings, and we are copying the
lists multiple times.
So, use GPtrArray instead. This avoids copies thanks to reference
counting, and enables autocleanup thanks to built-in data freeing.
|
| |
|
|
|
|
|
| |
Unused since cb7c77a8acf857c3bf16e73bc7beba4b9d09faac
So, let's limit the MIME type filter API to a setter and a getters. This
will allow porting to an immutable, refcounted GPtrArray next commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use a list of cases to define when the recursive search should be done, instead
of a simple true/false boolean.
A part from the self-explanatory cases `ALWAYS` and `NEVER`, the `IF_INDEXED`
option permits to any search engine that uses an indexed-search to return
results from subfolders of the search location.
One case we want to address, is the shell-search provider, that should not perform
recursive searches, but it could return values from subfolders of the user home
if the search is executed by search engines like tracker.
|
| |
|
|
|
|
|
| |
This commit removes redundant header inclusions and tries to optimize
headers by using forward declarations of types in headers. Such
optimization should generally make builds speedier in that changes in
certain headers will not cause unrelated sources to be rebuilt.
|
| |
|
|
|
|
|
|
|
| |
search_starred is always FALSE, because we don't provide UI to filter
search for starred files.
Remove it and any related code. Doing so, we are dropping the only uses
of hardcoded tag ids outside src/nautilus-tag-manager.c, which makes it
possible to set the tag id as a private constant next commit.
|
| | |
|
| |
|
|
|
|
|
|
| |
It was a mix of both terms, given that tracker uses 'favorite' but we
use 'starred' in the UI. Since the part that interact with tracker is
minimal, is better to be consistent with the UI.
This renames 'favorite' to 'starred' except the tracker queries.
|
| |
|
|
|
|
|
| |
Add option to make files Favorite, by either toggling a star in the
list view, or from the context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=786039
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, the number of letters before and after the match decrease
the rank of the search hit by the same amount.
Though, the prefix matches should be prefered over the sufix ones,
so make the number of letters after the match decrease the rank
by a much smaller factor than the number of letters before the match.
https://bugzilla.gnome.org/show_bug.cgi?id=785942
|
| |
|
|
|
|
|
|
| |
And make the style of Nautilus the same for all files.
Hopefully we can fix all the style issues we can find in the next days,
so expect a little of movement on this.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
|
|
|
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
