Search 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) 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 Ctrl+L 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 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 always overrides sub-RFCs like RFC 1089 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 Ctrl+S 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
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.