#388 some inputs about design

[Anonymous]

1. In the search window noticed Filename and path fields. I dont think both are required because they have same information. IMHO path alone is better. But better to have option which allows to select the fields to display.

2. In preview window if there are multiple searches there is only the next/prev option to scan through them. Shouldn't it be better to have actual keyword been displayed in that bar so that we can jump to the desired text in preview?

3. Noticed at times that while docfetcher is open cpu usage spikes up without any search in action... i believe it could be updating indexing...had there been an option to only capture the changes but not index them immediately while its running.

[Anonymous]

1. And copy[selected text] in preview pane only works with KB. Selection using mouse and copy using KB looks a bit odd. Probably selection/copy both using mouse is logically better.

[Nam-Quang Tran]

Hi,

Please post program discussions such as this one on the forum, not here on the bug tracker. The bug tracker is for program defects and crashes.

1) I think both the filename and path column have their purpose. The filename column is there because it is often rather difficult to figure out the filename by looking at the filepath, since the filepath may be too long or cut off. Instead of hiding the filename column, I suggest using drag & drop on the column header to move the column to the far right side where it won't get in the way.

2) I'm not sure if I understand your second proposal. Perhaps you mean something like a "search within search" feature, as discussed in this thread? The latter feature won't be implemented anytime soon due to lack of time, but I'll keep it in mind.

3.1) DocFetcher updates its indexes about 1 sec. after you modify a file in a folder that was indexed by DocFetcher. Additionally, the folder-watching option must have been turned on when the index was created. If you see the CPU usage spike 1 sec. after file modification, then it is probably caused by indexing, otherwise the problem may lie elsewhere, perhaps even in a different program.

3.2) You're suggesting to only capture the needed changes without indexing. But then, when is DocFetcher supposed to actually do the indexing? It must do the indexing at some point while it's running. If it waits until the next search, the search will take longer - not good. I think a delay of 1 sec. is just fine, because that makes the indexing predictable (i.e. the user knows modifying the file will immediately trigger an index update).

Best regards
q:-) <= Quang

[Anonymous]

1) sorry. I didnt realize we can move the columns. thats good.
2) say i'm searching for pdfs which contains all 3 keywords. search find 5 such documents. When i look into one of that doc, i find 100 total hits(including all 3 keywords which can be jumped over using next/prev arrows). So if i want to see all those i'll have to click, next, next... 100 times. Instead suppose i know that keyword 2 or 3 only appears just 1 or 2 times in that pdf it would be easy for me to directly jump to that keyword in preview pane. So i suggest Whatever keywords are searched, they should be also displayed in preview pane and i can click any of the keyword instead of going through next....next 100 times.
3) 1 sec of delay for detecting index watching is fine. What i'm saying is to not do agressive indexing whenever it detects the change. Suppose the cpu is already busy doing other important stuff, docfetcher could wait till some cpu is idle (say atleast 50% cpu is idle). So let it keep recording the changes - No issues, but the real indexing is defered till system is free.
4) Hope selection/copy text using mouse in preview pane is fine.

[Nam-Quang Tran]

2) Doing this sort of keyword scanning is very difficult to implement, because queries in DocFetcher are not restricted to simple keyword sequences; in general, the user can enter arbitrarily complex queries. Have a look at the "Query Syntax" section in the manual to see what I mean.
I think the aforementioned "search within search" feature would be the right thing to do, although it won't get implemented anytime soon, as I've already said.

3) Throttling the indexing when the CPU is idle is far easier said than done, especially in Java-based applications where accessing low-level information like CPU usage is rather difficult. This is the sort of feature you will probably find only in commercial apps (or anything backed by a company), simply because it requires quite a lot of programming effort. So, not planned for DocFetcher.

4) Sure, why not.

[Anonymous]

2) let me re-iterate its need using the attached pic. As you could see preview pane jumps to the first word it finds (memory here) and there are 1/276, 1446 hits which are impossible to traverse through using next/prev. I know there will be too many hits for the keyword "memory" but "virtual" would be less, so i would like to jump over to "virtual". Offcourse if keywords are too many you cant accomodate all of them but may be just the first 3-4 keywords only, which can be clicked (as in the image). If we could grep/jump to those it would be better. And this becomes more useful in pdf and other doc types where your preview is splitted and you dont have the luxury to see full html preview and also ctrl-f. The key point here is to jump to desired keyword.

I wish if you could think over this option. Would be great to have.

And i just noticed about a bug: during my first search i find some hits and selected doc is viewable in preview pane. If the next search gets 0 hits, the preview pane still display the old document which was last selected. so if zero results the preview pane should become empty.

:-)

[Nam-Quang Tran]

The main problem here is not whether I see its use (I do), it's the fact that the feature cannot be implemented as easily as you think. I don't have time for a discussion of the technical details, just take my word for it.

I'll be away for 1-2 weeks, starting today, so I'm afraid I can't continue this discussion.