| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus file operations are implemented as asynchronous jobs scheduled using
g_io_scheduler. Since g_io_scheduler has been deprecated, these operations
should be using the simpler GTask API. The helper functions used in the
operations have been changed in a previous patch so it is now possible to port
the jobs themselves to the new API.
The job structures are now data for tasks, which are handled by the existing
functions in separate threads. For finalizing the operations, the existing
"job_done" functions are now used as callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=761549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus file operations are implemented as asynchronous jobs scheduled using
g_io_scheduler. Since g_io_scheduler has been deprecated, these operations
should be using the simpler GTask API. In order to make this change possible, a
first step would be to replace the scheduler in the helper functions called
during the jobs.
Replace g_io_scheduler_send_to_mainloop with g_main_context_invoke in helper
functions. Since g_main_context_invoke is not blocking, add a mutex and a
condition so the current thread is blocked until the operation is completed in
the main loop.
https://bugzilla.gnome.org/show_bug.cgi?id=761549
|
|
|
|
| |
(cherry picked from commit fcd0d8b2be3d09e7e4170243951618ba1b378f28)
|
|
|
|
|
|
| |
They were missing.
https://bugzilla.gnome.org/show_bug.cgi?id=761706
|
| |
|
| |
|
|
|
|
| |
The position was set wrongly as 2 for all of them.
|
|
|
|
| |
(cherry picked from commit aa58221d98721fe92ce210bab7393843b2978f80)
|
|
|
|
| |
(cherry picked from commit 1fdd8a1399caf5f8fce4c1df3606c64f0223dfcf)
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 94b4b9e59f7c307256b7f09b0fad58486c071b6a)
|
|
|
|
| |
(cherry picked from commit 56261b96207897db3b648a998c7fa1ab8e45acda)
|
| |
|
|
|
|
|
|
|
|
|
| |
We needed a check there to not show it if the window is the desktop one.
Also this fixes the operations button not being hidden again due to
the desktop window popover being shown.
https://bugzilla.gnome.org/show_bug.cgi?id=761551
|
| |
|
|
|
|
|
| |
To use libgd tagged entries you must use this css which
doesn't come with the submolude.
|
| |
|
|
|
|
|
|
|
|
| |
It helps translators by differentiating the help strings from other strings
in the app that might be identical, and allowing to translate them
accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=761414
|
|
|
|
|
|
| |
This commit removes the annoying 2px border added to
the dialog's internal-vbox when not explicitly asking
for a 0px border.
|
|
|
|
|
|
|
|
|
|
| |
In commit ae55fec152123 I added a wrong gschema file in a wrong
directory, probably fallout of some local file when switching branches.
However, what it doesn't make sense is how it got added, since I never
use git add -A or similar, and I didn't add any new file. Maybe rebase?
Anyway, remove it since it was accidental.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's important to give feedback even when the search popover is closed
about which filters are in place. This is only achievable if the search
bar shows some labels tags as gnome-photos or gnome-documents does.
Unfortunately we don't have this tool in gtk+ yet, so we need to use
libgd.
So implement the query-editor with a custom GdtaggedEntry and update
the libgd subrepository to apply the latest style changes.
|
|
|
|
|
|
|
| |
And use it internally.
Better than setting up the widgets by hand every time we wanted
a reset.
It's made public because we are going to use it in a upcoming patch.
|
|
|
|
|
|
| |
Use the same mimetypes utilities and extract the functions to
mime-actions to clean it up and being able to be used outside of
the search popover class.
|
|
|
|
| |
So we use the same function all over.
|
|
|
|
| |
Update the label shown below the search bar when preferences change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a switch in the search popover.
The search popover is meant to be as a temporary filter. That means
that the "Search subfolders" switch that was present there was reset
every time a new search was performed.
Even if the nature of the popover is temporary and therefore should be
understandable that the switch is also temporary, this can bring
confusion in such a sensible matter.
To avoid confusion, add two preferences, one for remote file systems
and one for local file systems to allow the choice to make a recursive
or non recursive search, and remove the switch to avoid frustration.
Also, I expect this choice to be more a permanent one than a temporary
one, as in, I expect users to what they really want is to make a
permanent choice whether they want recursive search or not.
For local file systems, on what I can gather, either wants to emulate
the type-ahead search, because it's file system is slow to perform
a recursive search and will always be, therefore a permanent choice,
or the opposite where the file system of the user is fast enough to
perform a recursive search, which will most of the cases be like that,
and therefore also a permanent choice.
For remote file systems is similar. Either the internet connection of
the user is fast enough for the whole session or use, therefore wants
recursive search always enabled, or it's not, and therefore it doesn't
want recursive search enabled.
|
| |
|
|
|
|
| |
For clarity.
|
|
|
|
| |
Just a thynko/typo.
|
|
|
|
|
|
| |
It's more flexible and better to maintain different signals
for different changes, rather than a single signal with a single
generic parameter.
|
|
|
|
|
| |
We are accessing it from multiple threads of the search, so we need
to make sure we don't free it in the middle.
|
|
|
|
|
|
|
|
|
|
| |
This was not implemented. We want to differenciate between a range of
days we want to search for and a specific date, as set on the mockups.
The calendar selector will be specific dates, whether the days selector
will be a "since".
Also on the way fix various things and code preferences.
|
|
|
|
| |
"n" is not really useful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the view is still loading.
This happens when we schedule an idle to update the selection info
to display it in the floating bar, but selection becomes null.
Then the idle callback will remove the floating bar because the status
is none.
But that is wrong, because the floating bar is used for more than to
display the selection. We use it for displaying whether the view is
loading or searching, so if that happens we were removing the floating
bar.
To fix it, check in the idle callback for the other use case of the
floating bar, that means if it's still loading, and do nothing in that
case since that is taken care in a different code path.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An element within the group that complies a property A doesn't mean
the element automatically complies property B if we don't know
previously that those properties are mutual exclusive.
This can bring misbehavior if at some point a property C is introduced
making the other two non mutual exclusive.
Basically, it's better to check for the property you are going to assume
on the code than the opposite mutual exclusive property.
Also, is usually easier to understand what an element is than what is
not.
|
|
|
|
|
| |
Using a generic create_and_get_query is slighly misleading
to understand when or not should be the query created.
|
|
|
|
| |
We use it now directly in the search bar.
|
|
|
|
|
|
|
|
| |
I was confused even for a few miliseconds plus the idle time
why there was no searching going on.
So decrease the floating bar delay to the point it only won't appear
if the user wouldn't have time to look for a hint to know if the view
was searching or not.
|
|
|
|
|
|
| |
We need to update it and create the query if it's not created already.
In this way, when the user changes location the query and therefore
the popover will acknowledge it and update its widgets.
|
|
|
|
|
|
| |
We need to update the switch also when there is already a query,
since the query can change location and we would want to update
the backing setting to reflect if the file is remote or not.
|
|
|
|
|
| |
We want to catch errors with warnings and crashes, not with
misbehavior.
|
|
|
|
|
|
|
|
|
|
|
| |
We weren't syncing the last used/ last modified setting in the search
popover when changed location, which means the query didn't get the
last used user choice.
We don't want however to listen to a gsetting key and change every
ongoing search, so instead what we do is get the setting for the
initial creation of a search, and then every user change will set
the gsetting value, but will only affect the next created searches, not
the ongoing ones.
|
| |
|
|
|
|
|
|
| |
We were using it only for binding with the query editor and update
the switch for recursive search, but looks like something it doesn't
belong to the search popover, and instead to its owner, the query.
|
|
|
|
|
| |
And the query is empty, as in no mimetypes, date or text to
search.
|
|
|
|
|
|
|
| |
We need to update the query location when the user changes
the location and the slot acknowledge it.
If we don't do it, next time a search is done the simple engine will use
the previous location.
|
|
|
|
| |
It was partly unimplemented.
|
| |
|