| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
(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.
|
| | |
|
| |
|
|
|
| |
This was just not done yet, as Georges informed me.
We were making sync operations before this patch.
|
| |
|
|
|
| |
It's only for static arrays, which means it uses the stack
size for knowing the number of elements.
|
| |
|
|
| |
Using dt instead of date can be confusing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I know that it looks like it makes sense, but don't do it :)
Basically, all the logic for when a the query changes and to
load a new search directory (and therefore reload) is done outside
of the engines or the query. So basically don't touch it here.
What I believe is that reload should start the search again, not only
stop it and invalidate the file attributes of the search directory,
because as you could see it actually stops the search but doesn't
restart it.
I think this change of logic that makes reload not work properly on all
cases was introduced by me when I introduced the concept of restarting
the search engine internally, not only start and stop.
I will take a deeper look in future.
|
| |
|
|
|
|
| |
Instead, don't use it. We need a way to say that the view is
loading/searching, which is the floating bar now, and hopefully
something different in the future.
|
| |
|
|
|
| |
This is done for any user action. In this way we don't have to
do this confusing check here.
|
| |
|
|
| |
Don't mix more styles in nautilus.
|
| | |
|
