[WIP] Improvements to search

[tobiasdiez]

This is a new version of my old pull request, now updated to the 2.8 version and incorporating all the suggestions from the last time. (Except the clean commit history )

The changes include:

• Search bar is now at the top
• Autocompletion suggestions are shown in a popup
• Search options are available via a drop-down list, this implements Feature Request Add a few cleanup formatters #853
• "Clear search" button also clears search field, this implements Feature Request Fixes and cleanup for OpenOffice #601
• In incremental search mode: next result is selected by pressing enter (instead of Control + F as previously)
• Incremental search now uses the same search engine as the other search modes
• Added a new search mode (Live filter) which filters the table as soon as the search text is changed

I have a few questions:

• There are quite a few changes from formatting the code in Eclipse. Is it ok if I include them?
• I have a problem with listening to changes in the textfield and programatically setting the text with setText(). The latter command triggers first an event for the deletion of the text and then another one for inserting the new one. Is there a way to be informed just once about such a change? (This occours in the following case: if the user accepts an autocompletion, then the text is changed via setText(). Thus, in incremental and live filter mode, two searches are performed.)
• The SearchWorker implemented the AbstractWorker interface. As far as I understood, this enables one to do work asynchronously and then change the GUI later. However, the worker is simply run via
  worker.getWorker().run();
  worker.getCallBack().update();
  In my understanding, this defeats completely the purpose of using the AbstractWorker. What is the right way to run it?
• A general observation about the SearchRule class. Every method of it takes the query as an argument. I would propose to save the query internally in SearchRule and thus simplify the interface a little bit.
• The setting "Autocomplete names" is not yet implemented. In my opinion this can be completely removed.
• The setting "Select matches" is not yet implemented since I do not understand the purpose of this setting. Should it control whatever the first match is selected after the search is performed? Moreover, I think it was not implemented in the old search pane.

Things which should be done at some point (I will open a ticket after this pull request was accepted):

• All the other inline autocompletions (in fields for example) should also use the new dropdown style autocompleter
• Search result table is not styled the same as main table, related SF Bug 847

[simonharrer]

Regarding new eclipse formatting rules: for me it is very hard to review the patch because there are too many lines that have been changed because of the change in formatting rules. This makes it very hard to determine which lines do actually have changed. I would propose that eclipse formatter changes should be done in isolation in separate pull requests.

[tobiasdiez]

I completely understand this. Now there is a second pull request #166 just containing the format/cleanup changes. Is this enough to make comparison easier or should I somehow also modify this PR?

[simonharrer]

The thing is that when I want to know what happened in a pull request, I look at https://github.com/JabRef/jabref/pull/162/files which in this case is +2000 lines and -2000 lines at the moment. A lot of these lines were just reformatted, e.g., all the changes in the SearchManagerNoGUI. When the PR is small, formatting changes are no problem, but in this case it would help if this PR would only contain the functional changes, if this is possible without reprogramming everything.

Regarding the thing with the AbstractWorker and the run/update method. This is correct as it is because in the constructor of the AbstractWorker a bit of MAGIC (it is really a lot of magic) happens so that when you invoke the run method, it will run ouside the Swing EDT and the update method will run inside the Swing EDT.

Regarding the SearchRule: At the moment the search rule can be configured during its constructor and then invoked with different queries to allow reuse of the configuration done by the user in the GUI. At the moment the configuration mainly consists of [bool caseSensitive, bool regex]. But this model does not fit that well. I think it would be a good idea to just create test Predicates that receive a BibtexEntry and they can determine whether it will be included in the search or not.

I think we can delete "Select matches". I do not see any usefulness in this setting, especially as it has not yet been implemented.

"Autocomplete Names" does work on my machine. We should not remove it.

[simonharrer]

We do not want to loose all the work you did. Can you rebase on master? I will try to have a look at all the changes.

Another remark: why not make the live option the only one search mode and removing the explicit search button? For me, this is the typical search behavior in most of the applications I know. Even windows search.

[tobiasdiez]

I will try to rebase on master at the weekend.
What should I do with the settings "Autocomplete names" and "Select matches" (see above)?

[tobiasdiez]

The rebase run into problems since some files were moved (for example BasePanel.java). This is why I just have reverted the commit containing the code formatting changes. Now the code should be more understandable.

[koppor]

@tobiasdiez It would be very, very helpful if you managed to show the diff only and if all the merge and reformat commits would have been gone.

Proposal: Add a new local git worktree and copy all the files of your current branch to the new directory. Then do a new commit. I hope that this commit has clean changes and is readable. Then you can do a git push -f origin:uisearch to overwrite the uisearch branch with the clean commits. Would that be possible? Then you can also reset your original branch to the new origin/uisearch. If something goes wrong, you still have a copy locally where you can compare using KDiff3 etc. (For the record, there are many good diff tools).

[simonharrer]

@matthiasgeiger and myself checked the new search UI and we liked it. Especially the live feature! :)

We are currently discussing to simplify the search altogether in #104. Maybe we can combine a few things. May be you can have a look at this issue as well and we can work something out for integrate these ideas in your PR as well.

[tobiasdiez]

@koppor I opened a second, cleaner PR #307 (I don't want to override my branch). I hope this is also ok.

@simonharrer I had a look on the discussion in #104 while implementing this PR. Indeed, some of the design decision were strongly influenced by this thread. On the other hand, some of the motivations for the suggested changes in #104 do no longer apply to the search control at the top of the window (in contrast to the previous implementation as a side control). For example, the size of the dropdown showing the different search options is not very important so that is now no problem to show all the search options as a list.
To be honest, I would prefer if you could accept this PR and we discuss further improvements later. It was very time consuming to merge all the commits from the last months and it would be nice if I don't have to do it again :)

[simonharrer]

Ok, we will disucss this in the upcoming developer call.

[koppor]

Please follow up at #332.