On 3/10/19, Richard Owlett <rowl...@cloud85.net> wrote:
> I'm running Stretch with MATE desktop.
>
> If I submit a sub-string of a filename to "MATE Search Tool", *ANY* hit
> reports the full path to the target. That is *GOOD*!
>
> HOWEVER, if I'm exploring a specific directory with Caja and then search
> for the *IDENTICAL* sub-string I get a "hit" with ABSOLUTELY no
> indication of the file's location :{
>
> My test case:
> I created a test file at
> /home/richard/Downloads/tk8.6.9/tests/ttk/owltstmarch9 .
> I hope that is arbitrary enough ;}
>
> Using 'march' as test string when using:
> 1. "MATE Search Tool" yields exact location.
> 2, Caja admits file exists *SOMEWHERE*
>
> As an end USER:
> 1. "MATE Search Tool" gives expected result - i.e. giving
> full path to target.
> 2. Caja's search otherwise:
> A. The first time I used it, I expected to get hits *ONLY*
> in the current sub-directory.
> B. However it reports hits for *ANY* sub-directory at or
> below the current one. This can be very useful.
> *HOWEVER* it's usefulness is reduced by not reporting the
> full path to the target.
>
> Comments?
#GlassHalfFull: Thank goodness it only grabs from the bottom shelves
and doesn't also reach up over its head into higher parent directories
for those inquires. A developer type file name such as /readme.md or
/make comes to mind as an example there.
Since *your experience* is that Caja does only reach deeper into
[child] directories and not back up overhead, is there maybe something
explicitly expressed in their documentation that covers that feature?
If no documentation on the topic can be found AND so a bug report is
to be filed, a user could state that the current behavior inhibit's
the user's perception of full usability. The user could then offer a
bug report disclaimer stating that the user understands that the
current behavior may be by conscious design so maybe this is a
wishlist bug report item, instead.
A wishlist bug report could suggest that it would be nice to be
offered a toggle-able, e.g. radio button or checkbox type, option that
either:
* Only searches deeper into the file hierarchy thus still honoring the
maintainers' conscious current intended status quo..
OR...
* Searches the entire file hierarchy then provides query results that
include easily cull-able, usability-friendly full file paths.
It is a curious feature for which I can't immediately think of a usage
case. All that means is I've simply never encountered a situation that
mandated just such a search. *I think* the MANY searches I've done
over the years have been with the intention of needing that full file
path to accomplish whatever related task had instigated each search.
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *
