Improve search interface

[tobiasdiez]

The search ui interface needs some attention. The current author-auto completion lives between broken and useless. My proposal would be to add a proper flyout that can now be seen also in some other applications (e.g. OneNote or Outlook). I particularly like the following:

from https://www.fullstory.com/platform, see also https://help.fullstory.com/hc/en-us/articles/360020828253-Getting-Acquainted-with-OmniSearch

[koppor]

The other proposal by @tobiasdiez (at https://github.com/JabRef/jabref/issues/3535#issuecomment-352068826) is written down there: https://github.com/koppor/jabref/issues/341

[teertinker]

Hello, if there will be any change of the search function please keep the missing "global search" function in mind. From my point of view it is still a pain to enter the search term for every single tab/bib I want to search.

[koppor]

The global search is issue https://github.com/JabRef/jabref/issues/4096 (and not directly related to this issue - and thus can be handled separatetly).

[mchellelm]

Hi, we're a team of 5 (@shameenkals @JasonBourne999 @lachyp @artherdunger10) from the University of Adelaide who would like to tackle this issue! Our goal will be improving the author-auto completion as well as implementing a proper fly-out as proposed in this issue. We aim to have a pull request by early May. Is there anything in particular we should know about?

[tobiasdiez]

Thanks for your interest!

We are currently in the process of migrating the search syntax to Lucene (see #8206 for ongoing work). So in early prototypes its a good idea to not fiddle to much with the search syntax parsing. Please also have a look at the other linked issues (in particular https://github.com/koppor/jabref/issues/341) for further inspiration.

Our experience shows that its usually a good idea to create a PR very early during the development of a feature. You can then use it as a place to ask questions that might come up, and we can give feedback about the general direction the PR is heading to. Please feel free to contact us through one of the various channels if questions arise.

[claell]

Adding a screenshot of the GitLab issue search here as well for inspiration:

[LachyP]

Hi, I'm from the team of students in @mchellelm's group attempting to tackle this issue. So far we've been reading the documentation and experimenting with the code to try and figure out what changes need to be made to create a search interface like the one pictured at the start of this issue and we just have a few questions:

1. How would you suggest we start with conducting searches with multiple different categories on the AutoCompleter?
2. Given that the results of an auto-completion are dynamically stored in an ObservableList object, how would you suggest we go about adding headings to this list when its rendered in the GUI? Would this be done via java or via CSS?

[tobiasdiez]

I would say the headings should be static and predefined (at least for now). A good starting point would be to have a single category "Authors" whose contents is a filtered list of author names as provided by the auto completer. When the user selects one of the options, then something like authors = xyz should be added to the search text. Then as a follow-up further headings (such as "Priority") can be added with values either hard coded (prio1, prio2, ...) or from some auto completer (which then probably has to be newly implemented).

In general, one defines the structure of the control in java (or fxml, which I wouldn't suggest for this component here due to the performance overhead) and how it looks in css.

Does this answers your questions?

[LachyP]

Yes that makes sense, thankyou. I'll let you know if we have any more troubles

[koppor]

Pre-condition: https://github.com/JabRef/jabref/pull/8963