gnome-search-tool cannot find files in a hidden directory

Asked by VanillaMozilla on 2011-01-03

Using Places > Search for Files... I searched in File System for any file whose name contains 'brasero.session'. The 'Show hidden and backup files' option was selected. The file was not found, although it is actually located in ~/.config/brasero/ .

As far as I can tell, this test always fails for any file located below a hidden directory. I can supply a screen shot if necessary.

Is this a known bug?

Question information

English Edit question
Ubuntu gnome-utils Edit question
No assignee Edit question
Last query:
Last reply:

OK, I get it. You have to press the "Add button".

This seems rather unsatisfactory, since the option is shown. I don't suppose there's any chance of refining this behavior a little?

Sam_ (and-sam) said : #2

If you define it once it'll be kept for the next search, at least it's here the case.
You can do the same via gconf-editor and select preference there.

Or use CLI tools to locate files. (e.g. find, locate, whereis)

mycae (mycae) said : #3

Id recommend changing your question into a bug. This is kind of annoying, but consistent with gnome's simplification of options theme.

Id had a quick look but did not see any existing bug; though I may have been using the wrong keywords

OK, but I'd like to rewrite it, since the original question as stated is not correct. I'll just start with a new bug report and link this discussion. Do you suggest Ubuntu gnome-utils, or send it straight to Gnome Bugzilla?

But first, I have a suggestion on how to fix it.
1. Add a blank option to the list of dropdown options.
2. Change the "Add" button to a blank button (or no button).
3. If any option (except blank) is selected, then the button automatically changes to "Remove" status.
4. Change "Available options" to "Other options" or just "Options". (If this involves any sort of delay because of international string translation, skip this step.)

This is the simplest and least disruptive way I can think of to fix it. It preserves the space-saving but informative nature of the current system, and it's easily discoverable. Coding changes would limited essentially to a single logical test and replacement of two strings with blanks.

I have a screen shot, but I don't seem to be able to attach it. Are there any comments before I submit it?

Sam_ (and-sam) said : #5

An added option does already change the button to 'Remove', at least here on 10.10.
Also described there.

It isn't possible to attach a screenshot on LP 'answers' but to bug report.

## Anyway, I wouldn't have a problem with the layout(function), although I actually never use this tool, I rather use CLI.

3. Although the grammar wasn't clear, the intention is to change it from blank to remove, or preferably from a grayed out "Button" to an active "Remove" button. I have rethought it a little, and the revised change is about as simple and easy as I can make it for both program maintainers and users.

I have reported it as Gnome bug . Any hints on getting someone to actually read it and make the changes?

Sam_ (and-sam) said : #7

There is a mailing list.

Sam_ (and-sam) said : #8

Not sure if anyone will work on this seriously.
> gnome-search-tool - not needed in Unity, needed for 2D experience
## next to last line at the end of page.

> gnome-search-tool - not needed in Unity, needed for 2D experience

I don't know what that means, but Ubuntu doesn't even know about this bug because there's no Ubuntu bug report.

I think they need to fix the search tool or replace it. Although I think I have the errors fixed in my copy, it doesn't seem all that reliable.

Can you help with this problem?

Provide an answer of your own, or ask VanillaMozilla for more information if necessary.

To post a message you must log in.