search options

[biohegedus]

The naming and docs for search options are not clear and/or logical for me.

[koppor]

Do you mean "Incremental" vs. "Float" vs. "Show results in dialog" vs. "Global search" or something else?

[biohegedus]

I mean exactly these.

[simonharrer]

Do you have an idea how they should be named?

[lenhard]

For the record, this seems to come from the mailing list: http://sourceforge.net/p/jabref/mailman/message/34383062/

[biohegedus]

I have not thougth about the naming yet, since I do not understand these or their logic. E.g. If these options are different types of searches why the "show results in dialog" is an option in this group. These should be two option groups. One group for the search types the other for the display type. Or if all of these options indicate some of the display option or mode of the search then checking any of them and search for a word I shuld get the same results. I ran into this, since I could not perform a search within only a given group. I was tald to perform "float" to have a search only in the given group.

[mlep]

Some ("Incremental", "Float", "Filter" "Show results in dialog") are different ways to display the results.
But some are about the scope ("Global" = all of the opened databases).
Right?

[simonharrer]

Search: query, caseSensitive, isRegex.
Search (ext): Autocomplete Words

Scope: current file or all files (global)

Display: float, filter, dialog, incremental
Display (ext): Highlight Word, Select matches (does not seem to work for me.)

Incremental is an option that is more a unix style of going through the results using a next button. I am not sure if we still need such an option.

[mlep]

Thank you Simon for the clarification.

About Incremental:

• we can ask users which one they use the most
• where is the next button?!? (as you see this is not my prefer display style)

In general, I conclude that:

• Help should be expanded.
• The search GUI should be reorganized to avoid mixing things, no?

[simonharrer]

I suggest to make it simpler by

• removing incremental search
• make float the default search and hide the other options
• bring caseSensitive and isRegex to the front as they have an impact on the search results

I do not have good suggestions on scope and the dialog option, as they are intertwined. A global search always opens up in a dialog.

[mlep]

Currently, the various possibilities take 6 lines. Let's try to keep it as compact, or even smaller
Here is the design I suggest:

• Floating | Filter | New window
  (a dropdown menu with the 3 possibilities, which displays the selected one)
• Local | Global
  (and selecting global automatically selects New window and invalidates the possibility of selecting Floating or Filter)
• RegEx (on/off)
• Case sensitive (on/off)
• Parameters
  ("Parameters" is always displayed)
  • Autocomplete (on/off)
  • Highlight (on/off)

Only 5 lines, and still explicit about the (important) choices

BTW, why not to contact our GUI specialist?

[koppor]

Minor comment: pressing ctrl+f when the focus is on the search field, the type of the search changes. I would vote to remove this functionality and just highlight the searched word as Firefox does.

[simonharrer]

Ahhh, instead of 103 what I should have written in the commit message I wrote 104. What a mess.

[simonharrer]

I think this is related to #162

[simonharrer]

In #162, there is also the "live" option which does everything after each keystroke.

[simonharrer]

Current road map for the new search

• remove incremental search
• remove select matches option
• remove autocomplete on/off option and make this on by default
• make float search live
• handle global/local and in window/new window:

This should reduce the complexity of the search.

[tobiasdiez]

Can you please elaborate on why the incremental and filter search should be removed?
I agree that the incremental search is an edge case and probably not very often used, but the filter option is in my opinion very important. Indeed, it is my standard search mode. There are a few use cases where filter is superior to float (and not just an optical difference). For example, filtering items and then Control + A, followed by some action allows to easily apply the action just to the filtered items.

But even the incremental search has some use cases. It is a good search mode whenever the context of the other non-matched items is important (which is admittedly not very often). (This is why Control + G jumps to the given position in most text editors instead of just displaying the single line 😷)

In my opinion, the search is one of the most underdeveloped areas in JabRef and I can't see how removing search modes helps here. (Indeed, quite often I don't understand why some features should be removed. It would be ok if we try to implement something new and the old code posses a problem. Then removing the old feature is ok in my eyes. But just removing for the purpose of removing is not very profitable.)

[simonharrer]

JabRef at the moment has a few issues:

• Most of the code is untested, undocumented and contains a lot of bugs/issues.
• Over the lifetime of JabRef, a lot of features, UI elements and preferences were added. All of them are loosely fit together in the UI, but the UI lacks consistency and structure.

This makes working on JabRef interesting as in every part of the program, one can improve something. :)

JabRef 3.0 is the first effort to try to fix a lot of these issues. But with the available man-power we have at the moment, it is not feasible to keep all the existing features and fix/rewrite them so that we can maintain them again. We currently use three approaches: a) rewrite and put under test to improve quality and fix bugs, b) replace preference options with fixed values to reduce the number of available options, and c) remove features that have never worked or are extremely rarely used.

Regarding the search functionality, we wanted to apply b and c. You applied a in your PR, but without the tests. I am open to rescue the search modes within an effort to reduce the overall complexity of the search and make it more usable. If you like, we can talk via a skype call regarding this.

For me, the most annoying this regarding search are:

• local vs. global: in other applications, a local search within a file is normally completely separated from a global search. The global search is done in a separate window, see Sublime, Eclipse, IntelliJ, etc. whereas the local search is done within the file view. The results of the global search are also shown in a separate window wheres the ones in the local file are not. What is more, when having two databases open, and I issues a search query in one of them, and I switch to the other one, the search query is still displayed in the search window but not applied, creating even more confusion.
• The options regex and case sensitive are hidden, but they are extremely relevant as the three elements (query, regex, case sensitive) decide which entries match and which do not. Hence, they should be always visible so that the user can easily "debug" why the results are shown this way. This is typical for IDEs as well, see sublime search etc.

[tobiasdiez]

Thanks @simonharrer for the explanations. They helped a lot in understanding your/the teams reasoning. You should add a few of these sentences to the wiki!
I just want to add that one of the big selling points of Jabref is its customizability. There is probably no other reference manager with the same amount of preference options :).

Regarding the search options: all the (main) open issues are ui-problems, right? So wouldn't it be a better strategy to wait with further modifications of the search until we have a new ui concept for Jabref?

[simonharrer]

Hm, good points. Will do that.

Regarding customizability, this is an interesting point. We should discuss this in the next dev-call as well.

Regarding the search options: yes, you are right, but we do not know how long the port to JavaFX will take. So we have to decide in that trade-off. Something for the dev-call, maybe.

Thank you for the comment.

[simonharrer]

@tobiasdiez have a look at the current results of the search-improvements branch. I adapted your code and created a search ui per tab, making it local to each database with an option to do a global search as well.

[tobiasdiez]

Good work! A few remarks:

• now in filter and float mode the search happens after every text change. This should work in most cases and is an useful default. Did you tried it also with very large databases? I could imagine that in such cases the search is too slow to trigger it after with every text change.
• all the icons are wrong (probably wrong font?)
• the search settings popup is not connected to the button
• do you really think that all this control buttons for regex / case sensitive are really so important to be shown that dominantly? I never changed these options and would trust Jabref with sensible default values. The same applies essentially to all of the controls you added. For me, most of these different possibilities are nice-to-have but i rarely change or need them (e.g. global search and results in dialog). Most of the times I do Ctrl + F -> type author or keyword -> look at results. But maybe this is just me.
  So for the UI, I'm an advocate of clean and minimalistic interfaces. But since this is a UI change, I stop to have strong opinions about this for now and begin arguing again when we discuss UI issues next year *promise :) *
• Ok, on UI thing: could you please set the background of the new search toolbar to white?

[matthiasgeiger]

Help! I cannot close the "settings" pop up 😢

You removed the "toggle search bar" option completely - so it should not be possible to close the search bar?

Apart from this: Awesome!

@tobiasdiez Simon already posted an explanation regarding case sensitivity and regex above:

The options regex and case sensitive are hidden, but they are extremely relevant as the three elements (query, regex, case sensitive) decide which entries match and which do not. Hence, they should be always visible so that the user can easily "debug" why the results are shown this way. This is typical for IDEs as well, see sublime search etc.

See the following screenshots:

In this examples it is directly visible which settings affected the search.

[matthiasgeiger]

... as I see the screenshot from IntelliJ now: The red marking and the "x" to clear the search are also cool features I'd like to have in JabRef 😜

[tobiasdiez]

I'm not so sure that we should take developer text editors as a guide. Microsoft Office, Google, Windows, Firefox as well as all music and reference library manager I looked at just show a search field without any settings buttons. If we focus on power users than it is ok to show these buttons (since then the target audience should be similar to the one of code editors). But if we want to provide a reference manager for everybody (not even necessarily Latex users), then we should orient ourselves at the usual office programs. But this is a discussion which we should have before changing ui things...

At least I would like to have an option to show/hide all these buttons. I also welcome an option to toggle between my minimalistic and your more elaborate approach. (regarding "we have to many configuration options", you may have a look at the motivation for creating the Vivaldi browser)

+1 for the little "x"

[matthiasgeiger]

At least Firefox has a "case sensitive" option ;-)

I see your point, but the difference between the MS Office and the other searches is: MS Office only provides a "dumb" feature which is not configurable - if you provide some configurations, the settings affecting the search result should be displayed - and if shown as "toggle buttons" it is also easy to change them afterwards without the need of opening a popup menu.

I also welcome an option to toggle between my minimalistic and your more elaborate approach.

This would be a valid option yes!

However, I think we should use our time for more crucial discussions ;-)

[simonharrer]

Implemented your suggestions except the X within the search field - this is quite complicated to do with a lot of UI hacks. I could offer a clear button if this is really required.

[simonharrer]

Ok, please have a look at the current version of #332 which is good to go from my point of view.

[ajbelle]

@simonharrer and @tobiasdiez commented on Nov 11 2015 about

remove incremental search

I was running an older JabRef version that had search in the LHS panel, but now it is in the Tab and I can't find where to turn off incremental search. This is a major PIA, because I have a very large .bib file and the incremental search messes up typing in the search field because of the lag as it incrementally searches 45Mb.

Am I not seeing the setting, or has it VERY UNFORTUNATELY been removed as the post seem to say? Should I request it be reinstated as a feature request? Incremental ON makes searching very frustrating. Can I set in manually OFF in a config file?

[tobiasdiez]

Yes, as far as I know the incremental search was removed.
However, I think, you mean something different. Incremental was a search mode, which jumpened from one hit to the next one, similar to how the search feature works in mayor browsers. On the other hand, your problems seems to be that JabRef searches as soon as the input in the search field is varied. I am not aware of an option to disable this automatic search but can understand that it might be a problem for very big databases. Can you please open an new issue for it. Thanks