thunar issueshttps://gitlab.xfce.org/xfce/thunar/-/issues2024-02-29T12:55:24Zhttps://gitlab.xfce.org/xfce/thunar/-/issues/1306Search should be available from the command line somehow (special URI syntax,...2024-02-29T12:55:24ZAndrew ChadwickSearch should be available from the command line somehow (special URI syntax, or option)# Outline
Thunar should support specifying both a location and a recursive search pattern on the command line. This would allow better integration of Thunar (in search mode) with plugins like Whisker Menu, Places, and (maybe) Smartbookm...# Outline
Thunar should support specifying both a location and a recursive search pattern on the command line. This would allow better integration of Thunar (in search mode) with plugins like Whisker Menu, Places, and (maybe) Smartbookmark. It would also allow a Custom Action in the Xfce4 Application Finder to be written that calls Thunar to do a search.
(Currently (in Debian testing), Whisker Menu defaults to using Catfish, which I've never liked much)
There are a couple of syntaxes that might be worthwhile, and it is perhaps possible to do both.
## Approach 1: Leverage generic URI syntax
My preferred approach for Thunar's internals would be getting it to accept generic URI syntax on the command line, possibly store every aspect of a tab's location that way, and possibly expose it to users who press <kbd>Ctrl+L</kbd> on a `smb://` URI. Since generic URI processing libs are hopefully in use everywhere, this should allow API access to searches from the likes of `exo-open` and dbus too.
### Option 1: fragment syntax
Thunar could leverage existing [URI fragment syntax](https://en.wikipedia.org/wiki/URI_fragment) to allow URIs like
* `file:///home/me/Pictures#cat%20dog`
* `smb://server/pics#cat%20dog`
to represent a search in the identified place for the search pattern "`cat dog`" should be compatible with #817, but not necessarily with #1096 or existing select-by-pattern if we choose to throw those in the URI too.
### Option 2: query syntax
_If_ this is permitted by the RFCs for all schemes (check that the generic URI syntax of [RFC 3989](https://www.rfc-editor.org/rfc/rfc3986) always overrides sub-RFCs like [RFC 1089](https://www.rfc-editor.org/rfc/rfc8089.html) that don't mention query or fragment at all), it might allow
* `file:///home/me/Pictures?thunar-search=cat%20dog`
* `smb://server/pics?thunar-search=cat+dog`
to mean the same thing as above. Query syntax would inherently allow other things to be specified in the URI too, such as a new #1096 filter mode if that is to be represented somewhere other than the query string itself, or even the venerable, existing <kbd>Ctrl+S</kbd> select-by-pattern behaviour.
I'd be a little wary about using query syntax instead of fragment syntax, because (a) those are (sort of, kind of,) part of the _location_ and not a bit of app-defined behaviour for identifying a part of a document, and (b) there may be implementation-defined special behaviour for some query strings. I'm wary, but (b) can worked around with namespaces, and (a) might even not be valid objection :smile:
## Approach 2: Add a command line option
The simpler way of getting the search into Thunar would be to add a `--search-string` option on the command line. It's obviously not going to be processable by things passing in URIs (dbus, exo-open, Smartbookmark (assume it uses exo-open)), but it's a lot simpler to process and probably easier for users to type (or parse)
## Both approaches together?
There's no reason why both modes can't coexist, so it may make sense to implement approach 2 first, followed by approach 1 at a later date. The explicit command line option would either replace or add to any search query string that's part of a URI.https://gitlab.xfce.org/xfce/thunar/-/issues/1201Location column selection reverts when changing folder in another window2024-02-16T20:18:44ZRalph PickeringLocation column selection reverts when changing folder in another windowI am using Thunar 4.18.6 on Kali 2023.2. The issue I have noticed is that after selecting the location column in list view, if I double-click a folder in a different window, the location column disappears. This doesn't occur with other c...I am using Thunar 4.18.6 on Kali 2023.2. The issue I have noticed is that after selecting the location column in list view, if I double-click a folder in a different window, the location column disappears. This doesn't occur with other columns - selecting or deselecting other columns is unaffected by changing folder in a different window. I first noticed the behaviour when using the search, which is when having the location column is particularly useful, but it also occurs if the location column is selected in a normal folder view.https://gitlab.xfce.org/xfce/thunar/-/issues/1096Enhancement: adding a filter capability to Thunar2024-03-22T11:26:45ZNadir Boussoukaianad4reg@gmail.comEnhancement: adding a filter capability to ThunarHaving a permanently visible input at the bottom of a Thunar window/pane which is a filter to limit the number of files to display (in the current view mode icon/compact/detailed). It would need to be inactive unless activated by enterin...Having a permanently visible input at the bottom of a Thunar window/pane which is a filter to limit the number of files to display (in the current view mode icon/compact/detailed). It would need to be inactive unless activated by entering a text and should be cleared on changing directories.
The 'filter' box can limit the files displayed by entering a text to match against file names, done in any part of the filenames, and it is realtime while we type.
I know there exist a possibility with the current version: hitting the search button (or ctrl+F) and have search box work on the currently displayed directory only (you can set the search capability not to include subfolders in the preferences) : I use it, it is realtime while we type. So it is close.
But it requires a few clicks more, and since you jump in "search mode" it changes the display from compact to detailed view prior to search, so it causes some delay because it fetch all files sizes first and it is significant when there are a lot of files.
Then you also loose the selection if you want to: select several files for further operations and get out of the search mode.
(FYI the permanent bottom filter box is available on Dolphin and it works like described here)https://gitlab.xfce.org/xfce/thunar/-/issues/1026Close type ahead search box when window is maximized2023-02-03T09:53:15ZAlexander SchwinnClose type ahead search box when window is maximized![xorg](/uploads/db897d21398e43fb3f8273e60dfcce76/xorg.png)
When changing the window size by dragging one of the window borders, or moving the window, the box is closed. Though when pressing "maximize" in the header bar, the box is kept...![xorg](/uploads/db897d21398e43fb3f8273e60dfcce76/xorg.png)
When changing the window size by dragging one of the window borders, or moving the window, the box is closed. Though when pressing "maximize" in the header bar, the box is kept, which looks a bit silly :slight_smile:!https://gitlab.xfce.org/xfce/thunar/-/issues/1008Search: Location column sort order differs from other columns2023-01-13T20:28:26ZnewhoaSearch: Location column sort order differs from other columnsI noticed the sort order of the Location column when in search mode is different than the sort order of the Name and Size columns. In the example below the Name and Size column sort 128 (the highest number) last, but the Location column ...I noticed the sort order of the Location column when in search mode is different than the sort order of the Name and Size columns. In the example below the Name and Size column sort 128 (the highest number) last, but the Location column sorts 128 between 0 and 16.
Name, Size, Location columns:
![column-sort-name](/uploads/b6c87891bf3d3e35c44621bf61ca2887/column-sort-name.png) ![column-sort-size](/uploads/efb3a5d75186dd45c19b5056499e3a2b/column-sort-size.png) ![column-sort-location](/uploads/edd33060a9dd170bbf6a707ce57e106c/column-sort-location.png)
[sample files - column-sort-test.tar.gz](/uploads/361eb6b5f56c0b693100265410d6fa98/column-sort-test.tar.gz)https://gitlab.xfce.org/xfce/thunar/-/issues/915Using the arrow keys from keyboard to select the search results of Thunar's R...2022-10-22T12:50:30ZMuntasim Ul HaqueUsing the arrow keys from keyboard to select the search results of Thunar's Recursive Search featureThunar's recursive search is a welcome feature. Kudos to the developers involved!
One thing that's bugging me though is, using the arrow key/s from the keyboard to select the search results that I get after using the recursive search fe...Thunar's recursive search is a welcome feature. Kudos to the developers involved!
One thing that's bugging me though is, using the arrow key/s from the keyboard to select the search results that I get after using the recursive search feature.
How to reproduce:
Say, I searched something in Thunar using the recursive search and got the filtered (searched) results. Now to select any item of the search results, either file or folders, I could use the mouse (which could be inconvenient for a keyboard-centric usage).
Or you could, as I found out, press the Tab key twice (the first Tab press would select the side pane, and the second Tab press would select the first search result). Now after pressing the Tab key twice, I could select the search results using the down arrow key from the keyboard.
Selecting the search results using just the keyboard is doable, as I just described. But it isn't very intuitive.
It would've been intuitive if I could select the first search results by just pressing the down arrow key from the keyboard. This would minimize the key press needed to get a work done and thus would improve Thunar's usability.https://gitlab.xfce.org/xfce/thunar/-/issues/894Some columns can change globally depending on view2024-02-16T20:18:43ZnewhoaSome columns can change globally depending on viewIt seems that the Search and Recent views can have (or remember) their own unique columns, which is very nice. But some columns, like Location and Recency, disappear and reappear globally (in all windows and tabs) when Search, Recent, or...It seems that the Search and Recent views can have (or remember) their own unique columns, which is very nice. But some columns, like Location and Recency, disappear and reappear globally (in all windows and tabs) when Search, Recent, or Normal view modes are opened in new windows.
1) Search a folder
2) Right Click on Columns and add some columns (Location or Recency)
3) Choose a search result and select "Open in New Window"
or
1) Open Recent view
2) Right Click on Columns and add some columns (Location or Recency)
3) Open a new window or change a folder in another window
When a new window opens in detail view, and the columns in normal detail view are different that the Search/Recent columns, the Search/Recent view columns reset to the normal detail view columns.
This also happens in reverse, if you open a second window and begin a search, the normal window columns reset to the search view columns.
Hope this was explained well. You can keep both windows open and just switch between folders and Recent view to see the column changes back and forth in both windows.
Seems like it might be related to the patches or issues mentioned in MR !240https://gitlab.xfce.org/xfce/thunar/-/issues/837Right click context for searched items is incomplete2024-01-05T00:52:33ZTioRight click context for searched items is incompleteThis is what the context menu looks like for the items searched for:
![2022-07-12_16-52](/uploads/f9567804da580719d4f02e3b2cfb3d9f/2022-07-12_16-52.png)
This is what the context menu should look like:
![2022-07-12_16-54](/uploads/e482...This is what the context menu looks like for the items searched for:
![2022-07-12_16-52](/uploads/f9567804da580719d4f02e3b2cfb3d9f/2022-07-12_16-52.png)
This is what the context menu should look like:
![2022-07-12_16-54](/uploads/e4829e42bfdd385f8df452ac9b84fd2a/2022-07-12_16-54.png)
It is missing out delete, rename, and a lot more options.
Tested with Thunar 4.17.9git-9771dff7https://gitlab.xfce.org/xfce/thunar/-/issues/823Search closes when switching between two tabs with search results2023-01-09T17:54:08ZnewhoaSearch closes when switching between two tabs with search resultsAfter searching in multiple tabs, the search results will close/exit when returning to the previous tab.
1) Open Thunar
2) Create 2 folders: Folder1 and Folder2 (they can be empty)
3) Open Folder1 in a new tab (Tab 1)
4) Open Folder2 in...After searching in multiple tabs, the search results will close/exit when returning to the previous tab.
1) Open Thunar
2) Create 2 folders: Folder1 and Folder2 (they can be empty)
3) Open Folder1 in a new tab (Tab 1)
4) Open Folder2 in a new tab (Tab 2)
5) Search for something in Tab 2
6) Go back to Tab 1
7) Search for something in Tab 1
8) Go back to Tab 2
Most of the time, when you go back to Tab 2, the search will exit and return you to the normal folder view. This can be done back and forth (if you search again in Tab 2, then go back to Tab 1, Tab 1 will exit search).
There are some times when this doesn't happen, but I couldn't find a consistent way to replicate it not happening and it happens much more often than not.
Using Thunar 4.17.8 git 62fc1473https://gitlab.xfce.org/xfce/thunar/-/issues/817Search patterns: support negation (`-searchterm`, logical ¬)2024-03-01T07:08:07ZAndrew ChadwickSearch patterns: support negation (`-searchterm`, logical ¬)Following on from #28, now that we have recursive search, things have changed a bit. Search now produces a result set, on which normal file operations and UCAs can run. Filtering with globs on a result set like this can still happen with...Following on from #28, now that we have recursive search, things have changed a bit. Search now produces a result set, on which normal file operations and UCAs can run. Filtering with globs on a result set like this can still happen with `Select by Pattern` at present. However, sometimes it's nice to have a bit more control over what's _in_ the results set.
I think that the most useful pattern to support would be negation, or a logical NOT. It's also quite easy to implement!
## Thunar's current state
Currently, the search string is split on whitespace, and each such term must match in every target file's basename. This is a little like Nautilus's implementation.
## Other implementations
Nautilus does not support negation, so implementing this will make Thunar's recursive search more useful than Nautilus's.
Internet search engines use a `-` at the front of a search term to indicate that results should not include that term. Something like this should work well when searching trees with lots of false positives.
This would make the Thunar search something like [fzf](https://github.com/junegunn/fzf)'s `--exact` mode. That uses `!` as its prefix for NOT-terms, but the concept is very similar.
## Expected behaviour
I definitely prefer the `-` prefix to `!`, and there are probably more people using Google or DuckDuckGo than there are using fzf. That said, it does mean you can't search for specific file names with a search term beginning with a `-` (searching for `-min` wouldn't match `hyphen-minus.txt`). `!` has the advantage of being terminal punctuation in most languages, so it is less likely to appear in a file or directory name at the start of a string (some exceptions: RISC OS application directories, old systems where `!readme.txt` sorts earlier etc.)
Should we go with `-` due to user familiarity, I would expect the search string `pear -apple -tag` to match 'pear juice.txt' but not any of `APPLE AND PEAR PRICE COMPARISON.DOCX`, `pineapple.jpg`, or `pear and pomegranate tagine recipe.md`.
## Future ideas and scope
Perhaps one day we we could unify the syntax for `Search` and `Select by Pattern` so that Thunar doesn't have to support two different search/select syntaxes. I think that's outside the scope of this feature request. It's best keep things simple at first and test!
The limitation mentioned above would disappear if one could search for `*-min*`. One day, perhaps.Andrew ChadwickAndrew Chadwickhttps://gitlab.xfce.org/xfce/thunar/-/issues/805ThunarListModel should expose the search query string as a GObject property2022-05-31T20:20:52ZAndrew ChadwickThunarListModel should expose the search query string as a GObject propertyFrom !255, which this work should probably follow on from:
> Andrew Chadwick 🌱 @achadwick · 9 hours ago
>
> Noticed that `folder` is a property of `ThunarListModel`, but the search query has no property yet. For parity, I think a `sear...From !255, which this work should probably follow on from:
> Andrew Chadwick 🌱 @achadwick · 9 hours ago
>
> Noticed that `folder` is a property of `ThunarListModel`, but the search query has no property yet. For parity, I think a `search_query` property should be added sometime.
>
> Also, `thunar_list_model_set_folder()` has become overloaded with the query as an optional parameter without being renamed. I guess it could be overloaded more with a convention for changing the search query without affecting the current folder :sweat_smile:
Changing the new `search_query` property should start a new search without affecting the current folder.https://gitlab.xfce.org/xfce/thunar/-/issues/793Search should properly normalize strings before case folding and comparison2022-05-30T09:12:55ZAndrew ChadwickSearch should properly normalize strings before case folding and comparisonFollowing on from !244, as promised.
## Feature request and progress
The current filename-based search implementation folds case for both the search term "needles" and the filename "haystack" strings. This is helpful, but it doesn't ye...Following on from !244, as promised.
## Feature request and progress
The current filename-based search implementation folds case for both the search term "needles" and the filename "haystack" strings. This is helpful, but it doesn't yet meet the needs of a globally aware file manager. Thunar should probably:
- [X] Easy: normalize the strings to NFD (at least) before case folding
- [X] Harder: optionally try to strip diacritics (like Firefox does with the right checkbox, might need some UI)
- [ ] Harder still maybe: real locale aware comparisons like `g_str_collate()` does it, so that characters like Turkish dotless I get casefolded correctly
### Stage 1: simple Unicode normalization
<details><summary>Click to expand</summary>
This is the process of converting strings with composing characters to the fully-composed version, or vice versa. This is done with `g_utf8_normalize()`. For example:
* "à" can be represented in decomposed form <U+0061 (LATIN SMALL LETTER A) U+0300 (COMBINING GRAVE ACCENT)> or composed form <U+00E0 (LATIN SMALL LETTER A WITH GRAVE)>
This is needed for both needles and haystack because we're using the Unicode-unaware `g_strrstr()` for the substring matches. It should be performed before casefolding.
</details>
### Stage 2: locale-naïve diacritic stripping via decomposition
<details><summary>Click to expand</summary>
It would be super if users whose filenames contain a lot of diacritic characters could search for them by typing the unadorned form of the character. See the reference below by Turkish user "loki" on StackExchange for a quick user story in an unrelated program.
The way GLib anticipated we'd all be doing this is by providing `g_str_match_string()`, `g_str_tokenize_and_fold()`, and ultimately (and alarmingly!) `g_str_to_ascii()` which is supposedly locale aware. Except that it isn't, and it converts almost everything that isn't already ASCII or a known asciification into a `?`. The concept of searching for, and amongst, sets of generated alternative forms is worthwhile, however, and I'll be returning to it
Firefox is an interesting case here. It has UI for diacritic matching and also whole word matching (I'll be returning to that too!)
![Pic of the search bar that appears in firefox when you press Ctrl+F](/uploads/62a4b7853030d45bdc4150e373fa5715/image.png)
One caveat: if we do this by decomposing by normalizing to [Normalization Form KD](https://www.unicode.org/reports/tr15/#Norm_Forms) and stripping out the characters for which `g_unichar_combining_class()` returns non-zero, as in the Eevee reference below, this could change the meanings of certain texts. But for the examples given:
* Korean 한글 ([Hangul](https://en.wikipedia.org/wiki/Hangul)) becomes 한글 (Hangul, but written in jamo salad)
- Wiktionary (for example) is pretty relaxed about the <https://en.wiktionary.org/wiki/한글>
- It's basically the same string but decomposed into its constituent jamo.
- Doesn't really matter if it's intelligible because we're not displaying this.
- There's an [algorithm for recomposing the salad back to precomposed Hangul syllables](https://stackoverflow.com/a/42478456)
* Japanese イーブイ (Ībui, or [Eevee](https://en.wikipedia.org/wiki/Eevee)) becomes イーフイ (Īfui)
- Not round-trippable. Information _has_ been lost, but this may not matter (I'm uncertain about this)
- The misspelling is known to search engines if that's any yardstick <https://duckduckgo.com/?q=%2B"イーフイ"&t=ffab&iax=images&ia=images>
- I don't know how well that corresponds to Japanese keyboards
This cannot be round tripped always, but that doesn't matter to us because it's _supposed_ to be a mangling of the text. I remain to be convinced that this transform on both needles and haystacks would render the search unworkable by returning a huge number of hilariously bad matches that a user literate in the language in question couldn't come up with a workaround for. Particularly if we have a Firefox-like diacritics button in the search area…
Here's a sample implementation, in Python
```python
import locale
locale.setlocale(locale.LC_ALL, "")
import gi
from gi.repository import GLib
def normalize(s, diacritics=True, casefold=True):
if diacritics:
s = GLib.utf8_normalize(s, -1, GLib.NormalizeMode.NFKD)
s = "".join(c for c in s if not GLib.unichar_combining_class(c))
else:
s = GLib.utf8_normalize(s, -1, GLib.NormalizeMode.NFKC)
if casefold:
s = GLib.utf8_casefold(s, -1)
return s
s = '한글 イーブイ ャ IJsselmeer ٣³3➌ Ø İstanbul hayırlı Queensrÿche Spın̈al Tap soupçon n̶o̶t̶ ̶t̶h̶i̶s̶'
print(s)
s = normalize(s)
print(s)
print(GLib.str_to_ascii(s, None))
```
Produces
```
한글 イーブイ ャ IJsselmeer ٣³3➌ Ø İstanbul hayırlı Queensrÿche Spın̈al Tap soupçon n̶o̶t̶ ̶t̶h̶i̶s̶
한글 イーフイ ャ ijsselmeer ٣33➌ ø istanbul hayırlı queensryche spınal tap soupcon not this
?????? ???? ? ijsselmeer ?33? oe istanbul hay?rl? queensryche sp?nal tap soupcon not this
```
Convince me we shouldn't be doing this (well, not `g_str_to_ascii()` because that's terrible)! I need more examples in multiple languages. Is there ever a mangling that's going to return mismatched search results in a way that makes no sense to the user?
Another caveat here: this algorithm is completely unaware of what language is being written (because Unicode cannot encode it), and also of the current locale (which is probably what's most meaningful to the user). This is why it breaks even under `LANG=tr_TR.UTF-8`.
(and `g_str_to_ascii()`, which is supposed to be locale aware, can't handle downsampling dotless I to dotted ASCII i, let alone the useless mess it makes of Japanese or Korean characters. Let us not use this or its related functions `g_str_match_string()` or `g_str_tokenize_and_fold()`)
</details>
### Stage 3 galaxy brain: locale aware comparisons
<details><summary>Click to expand</summary>
This is less worked through because it may be a bad idea.
Remember that Firefox can match by word? And that `g_str_tokenize_and_fold()` actually splits on whitespace? Could we do something like that, and then make use of the locale-specific cmp()able hash that something like `g_utf8_collate_key()`? However, this doesn't seem to cope with dotless I in a Turkish locale, and it still needs pre-casefolding (and `g_utf8_casefold()` can't do that)
(Other big flaw with matching by word: wordsplitting Japanese and Chinese is *hard* because they don't use whitespace to divide words most of the time. This would have to have some UI.)
Another resource is the big database of Unicode confusables in Raymond Chen's reference below. However, I'm not sure how you'd start with that, and it's not present in unicode-data on my system.
A third half-baked idea would be to get the translators to do upstream's work for them, and have a localizable casefold override string like `C_("searching:casefold-override", "")` (for C/en_US) which the Turkish translators, say, could flesh out as `"ı:i İ:i"`. And then apply the resultant mapping as a pre-pass before `g_utf8_casefold()` to work around its shortcomings.
</details>
## Some light background reading
* [Dark corners of Unicode by Eeevee](https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/)
* [The [gnarly] world of stripping diacritics by Raymond Chen](https://devblogs.microsoft.com/oldnewthing/20141124-00/?p=43553)
* [stackoverflow:42974173 - questioner loki explains some Turkish language search expectations](https://stackoverflow.com/questions/42974173)https://gitlab.xfce.org/xfce/thunar/-/issues/788It's possible to start searching by typing "Search: " in the Location bar, bu...2024-03-01T07:02:49ZAndrew ChadwickIt's possible to start searching by typing "Search: " in the Location bar, but search mode is not enteredVersion: Thunar git main as of 909efefedbc28716863f754e00a804bc81c93975.
## Steps to reproduce
As the title says, it is possible to start a new search by pressing <kbd>Ctrl+L</kbd> (`Open Location…`) and entering a string such as "`Sea...Version: Thunar git main as of 909efefedbc28716863f754e00a804bc81c93975.
## Steps to reproduce
As the title says, it is possible to start a new search by pressing <kbd>Ctrl+L</kbd> (`Open Location…`) and entering a string such as "`Search: some search terms`". However the display isn't the usual search listing: if you are in Icon View to start with, the search results are shown in Icon Vew too:
<details><summary>Click to expand screenshot</summary>
![Just searched the Thunar source for ".service" by this method](/uploads/81bfdfcdae648df9e4f5f9fa4ed4ad2a/image.png)
</details>
This "search" cannot be terminated with <kbd>Esc</kbd>, and the search togglebutton on the toolbar is not toggled on.
### Continued weirdness
If you now press the more conventional <kbd>Ctrl+F</kbd> combination (`Search for Files…`), then a new "real" search begins. It's as if Thunar wasn't in search mode at all before, despite the search results clearly showing!
<details><summary>Click to expand screenshot</summary>
![Then I started a new search for ".desktop" with the normal method](/uploads/96f3c517068274832e84da36203c67e7/image.png)
</details>
The results are shown in List View, which is what I expect, and now the Search button is toggled on. This search can be terminated with <kbd>Ctrl+F</kbd> or <kbd>Esc</kbd> while the search entry box has focus and Thunar will switch back to Normal mode.
## Observations
Thunar should enter "proper search mode" no matter which keys you press to initiate the search. This becomes important if one fix for #787 would be to stop monitoring while in search mode.
I don't like the search entry box being actually the location entry box with some editable text stuffed in the front somehow. It seems to lead to situations like this when you consider that strings have to be parsed. I think I'd prefer two separate boxes in a GtkStack whose state gets toggled when you press <kbd>Ctrl+F</kbd>, <kbd>Ctrl+L</kbd>, or <kbd>Esc</kbd>. If there's to be text at the front of the search entry box, make it static and uneditable so that I can press <kbd>Ctrl+A</kbd> to go to the start of the search string like a normal text entry box.Sergios - Anestis Kefalidisskefalidis@xfce.orgSergios - Anestis Kefalidisskefalidis@xfce.orghttps://gitlab.xfce.org/xfce/thunar/-/issues/786Search mode: Back button should exit search2023-10-23T14:34:42ZnewhoaSearch mode: Back button should exit searchCurrently if you go to folder-1/folder-2/Search, hitting the toolbar's back button while in search mode takes you to folder-1.
The expected behavior would be to simply exit the search and return you to your view before the search - fold...Currently if you go to folder-1/folder-2/Search, hitting the toolbar's back button while in search mode takes you to folder-1.
The expected behavior would be to simply exit the search and return you to your view before the search - folder-2.https://gitlab.xfce.org/xfce/thunar/-/issues/752Search file contents.2022-04-18T03:07:52ZSergios - Anestis Kefalidisskefalidis@xfce.orgSearch file contents.Add an option to also search file contents for the search query.Add an option to also search file contents for the search query.Xfce 4.20Sergios - Anestis Kefalidisskefalidis@xfce.orgSergios - Anestis Kefalidisskefalidis@xfce.orghttps://gitlab.xfce.org/xfce/thunar/-/issues/231Nit: Thunar cannot be closed while the search widget is active2020-10-14T22:48:21ZBugzilla MigrationNit: Thunar cannot be closed while the search widget is active## Submitted by Manuel Grießmayr
Assigned to **Xfce Bug Triage**
**[Link to original bug (#15069)](https://bugzilla.xfce.org/show_bug.cgi?id=15069)**
## Description
A funny little big that is barely worth to be mentioned. Open Thu...## Submitted by Manuel Grießmayr
Assigned to **Xfce Bug Triage**
**[Link to original bug (#15069)](https://bugzilla.xfce.org/show_bug.cgi?id=15069)**
## Description
A funny little big that is barely worth to be mentioned. Open Thunar. Type some text to trigger the search popup. Try to close the window via the button in the right top window corner.
System: Xubuntu 18.10 64 bit
Version: 1.8.2https://gitlab.xfce.org/xfce/thunar/-/issues/32Select file/folder as you type, even if content is not fully processed yet2021-05-07T07:52:07ZBugzilla MigrationSelect file/folder as you type, even if content is not fully processed yet## Submitted by HennR
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7680)](https://bugzilla.xfce.org/show_bug.cgi?id=7680)**
## Description
The problem occurs when you open a big directory which takes some seconds for ...## Submitted by HennR
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7680)](https://bugzilla.xfce.org/show_bug.cgi?id=7680)**
## Description
The problem occurs when you open a big directory which takes some seconds for the content to get displayed.
When you want to select a file or folder by typing its name, while the folder is not completely processed, the small pop-up gets opened but when the content arrives thunar will not jump to / select the file / folder.
It would be awesome if thunar would trigger typed search terms on finishing the loading process and keep the search term visible until the folder is fully loaded.