On Thu, 10 Oct 2013 09:54:37 +1100 Lex Trotman elextr@gmail.com wrote:
On 10 October 2013 07:01, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Proposition: move the presentation to glade as much as possible, and fill the content with code, as in any normal program.
Well, not everybody likes Glade or XML, but why only FIF, why not all search dialogs?
I don't like XML either; only because I'm at the FiF dialog ATM.
- The all/project/custom combo box. This thing has 2 functions
dedicated to it, and about 50 LOC in total. So what it does?
all - this is exactly the same as leaving the Files empty.
Yes would seem to be an alias of the delete button on the entry. Are you sure that the delete button is always guaranteed to be present, and not deprecated by GTK3 or removed by themes or ... something else that removes it?
I'm not sure about the future of GTK+ at all, but that's another theme.
In the eventual future absence of the clear icon, you are free to clear the text with Delete/Backspace if it's selected, or with Ctrl+A and Delete/Backspace if it's not.
custom - this is exactly the same as entering something in Files.
Well, its "Not Project", ie you need some way to switch away from using project settings, how good "Custom" is as a name is open.
So it only exists because Project exists, and has no intrinsic value.
project - this is not exactly the same as placing the Project 'File patterns' in Files. It pastes them, all right, but then locks the field, so you can't add / remove / edit a pattern. And the only reason to lock them is "consistency": the 'project' choice must correspond to these patterns exactly. Well, if you do a Find, and then switch to 'custom', and then open the Files history, you will be able to edit the patterns after all... Last and least, 'project' grays the patterns, making them less visible.
Make sure this functionality isn't important to the project plugin(s). I remember vaguely some significant discussion on the subject during one of the project plugin developments.
If a plugin can access the field, it can simply fill it with something and lock it, without using an additional combo box.
Of course, if I change FiF, I will make sure that the plugins work.
The fact that you can edit the paths when you have switched to custom is irrelevant, that doesn't save to the project.
I could not understand this sentence, but agree about "not saving the project". It doesn't save "all" and "custom" either. :)
Proposition: Remove the combo box. Add a paste icon on the right of files, above the Directory selection icon, and set it's tooltip to "Paste the project patterns, if any".
This is not the same functionality, choosing project on the combo is a sticky choice that follows the project settings, with this change the user would have to remember to paste when changing the project setting or after a custom search.
And it also blocks editing the patterns. The most common starting point for specifying custom patterns does not work.
The "same functionality" can be achieved by using a check box, since the distinction between "all" and "custom" is nonsense. That'll still block editing, but at least won't be so clumsy.
Or we can check if the field contains the current project patterns, and fill it with the new project patters on switch. Big deal.
FiF checks if a project is open, but not whether it really contains 'File patterns' - RFC.
Which is the project's problem, not the search's. Search should not impose requirements on projects.
It doesn't, and I do not propose such a thing. It's just strange that "project" is disabled if there is no project, but enabled if there are no project paths.
- For non-recursive searches, grep does not allow a directory to be
specified instead of file. To work around that, we read the directory, back-parse all --include=*.x patterns, and match them manually.
Proposition: grep -rl --include=*.c --exclude-dir=[^.]* --exclude-dir=.?* void . :)
We pass our Directory as a workind directory to spawn, and the recursive search already uses . as a grep FILE argument. --exclude-dir is supported since more than 5 years.
But not in POSIX grep.
We are not using POSIX grep, it doesn't even support recursive search AFAIK. We are using GNU grep, and the above options work on our supported platforms, *NIX and Win32.
The hard coded grep options thing has always been a problem (eg see the Note in the manual). The grep setting in tools should accept a whole command like most of the other settings, probably with the usual %something substitutions.
"should" == "does not, and there's nobody willing to do it"?
And you won't be able to produce one --include= directive for each pattern in Files with the usual substitutions.
- Pressing ENTER in Directory does not activate Find.
Proposition: obvious.
I thought that was a PR, but I can't find it, nvm.
Maybe I was unclear. ENTER in 'Search for' or 'Files' activates the Find button. ENTER in Directory does not.
- [ ] Extra options. Unchecking this is the same as clearing the text
field, except that you can re-enable them later.
Proposition: Make 'Extra options' a label. If we want to keep the options, add a normal history. Personally I don't care about them.
In the absence of grep in tools prefs being a full command, this is where your --include and --exclude should be the default value.
I'll explain again. The only point of the checkbox is to be able to quickly disable the extra options, which is the same as clearing them, *except* that you can restore them quickly.
If we consider them so important as to have an extra interface element, why don't we use a normal history, and have several sets of options?