| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Pass new uncrustify criteria. No logic changes.
|
| |
|
|
|
|
|
|
|
| |
The `G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE` attribute doesn't have to
be always set. The commit 0e597803 added the
`G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE` fallback inside the
`NautilusFile` class, but not for other places. Let's fix this oversight.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2862
|
| |
|
|
|
|
|
|
| |
The `G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE` attribute doesn't have to
be always set. This case is not handled by the `NautilusSearchEngineSimple`
class and the `NULL` pointer can be passed in the `g_content_type_is_a`
function currently. This is an error. Let's check the returned pointer
to prevent this situation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is not guaranteed that all `GFileInfo` attributes are always set when
requested. They used to be silently set to `NULL`, `FALSE`, or `0` earlier
when they were not provided by their implementations. However, some of the
helper functions now print critical errors when the attributes are not set
by their implementations even though they were requested. See the
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3261 merge request for
more details. So Nautilus now prints tons of critical errors when started.
The unset attributes can be detected over the `g_file_info_has_attribute`
function. But Nautilus doesn't care in most cases about the reason why the
attribute is `NULL`, `FALSE`, or `0`. There are also more generic helper
functions that don't print these critical errors. Let's use them for the
attributes that may not always be set to get rid of those critical errors.
I suppose that the `name`, `display_name`, `size`, `icon`, and `file_type`
attributes don't need this special handling, although it is not clearly
stated anywhere...
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2861
|
| |
|
|
|
|
|
|
| |
Currently, build warning is shown about the potential usage of
uninitalized variable. This is false-positive, but let's explicitly
initialize the variables using switch to get rid of the warning.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2152
|
| |
|
|
|
|
|
| |
The search providers convert dates from unix time to `GDateTime` and vice
versa. Let's use `GDateTime` everywhere.
Relates: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2152
|
| |
|
|
|
|
|
| |
The access and modification dates are used to calculate rank, but are
not propagated from all providers. Let's propagate them from all providers.
Relates: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2152
|
| |
|
|
|
|
|
| |
this will let user search for the files using the
crtime (creation time) of the files
Closes #1761
|
| |
|
|
|
| |
There are some style issue since the last run. Let's run it again
before enabling style-check CI job.
|
| |
|
|
|
|
| |
* Cleaner separation of phases
* Avoid some races
* Fix some leaks
|
| |
|
|
| |
To avoid clogging up the main loop.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Returns whether the search should be recursive given the location and the
search engine type.
Using this both in tracker and simple search engines.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Compute the recursive parameter depending on the query flag for recursivity,
enabling it only if the query recursive flag is NAUTILUS_QUERY_RECURSIVE_ALWAYS,
while should be disabled otherwise.
At this point the "recursive" property that was set only for this search engine
doesn't make any sense anymore and we can safely drop it, together with the
calls that were done at search-engine level to handle this special case.
We move now the responsibility to to the engine itself, more than to the model.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This reverts commit 37693c427941d60634bad80dd7c2d0b3a8523cea.
The patch was pushed by accident.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When starting the search providers, some provider might finish
before all providers are started, so a wrong value of providers_running
will be used, making Nautilus crash.
To fix this, keep a queue of the started providers and whenever the
value of the finised/running providers is needed, check the status of
each provider.
https://bugzilla.gnome.org/show_bug.cgi?id=785723
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we are using the old GObject class declarations, which have two
problems.
One problem is that we cannot use smart pointers like g_autoptr. The other
problem is the boilerplate code generated that makes the code less readable,
so harder to understand.
To fix this use G_DECLARE* type.
https://bugzilla.gnome.org/show_bug.cgi?id=771929
|
| |
|
|
|
|
|
|
| |
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
|
