Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch colors of search icon for the two search modes #3871

Merged
merged 10 commits into from
Apr 12, 2018

Conversation

lenhard
Copy link
Member

@lenhard lenhard commented Mar 21, 2018

Fixes #3870


  • Change in CHANGELOG.md described
  • Tests created for changes
  • Manually tested changed features in running JabRef
  • Screenshots added in PR description (for bigger UI changes)
  • Ensured that the git commit message is a good one
  • Check documentation status (Issue created for outdated help page at help.jabref.org?)

@lenhard lenhard added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Mar 21, 2018
@koppor
Copy link
Member

koppor commented Mar 21, 2018

Grammar-based search is the advanced search. So, the magnifier should be cyan, when following search string is active:

author=kolb and author=kopp

Taking examples from the documentation (https://help.jabref.org/en/Search#search-modes)

All of these are advanced, but they are not recognized as such:

title|keywords = "image processing"

(author = miller or title|keywords = "image processing") and not author = brown

Following is normal mode:

progress “marine aquaculture”progress “marine aquaculture”

This is now with cyan. This is wrong.

Following is normal mode:

progress

Correctly recognized displayed as normal mode with this patch.

Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix is not in line with the intention of basic and advanced mode. basic is non-grammar-based, advanced is grammar-based

@stefan-kolb
Copy link
Member

If so, the whole detection is wrong?!

@koppor
Copy link
Member

koppor commented Mar 22, 2018

Only the beginning of the detection is somehow wrong. For complex terms it is right, but for single words, it is wrong. See the examples above. Maybe, we changed something when going from JabRef 3.6 to 3.7.

@lenhard
Copy link
Member Author

lenhard commented Mar 22, 2018

Or maybe the detection never was entirely correct. If I have a lot of time on my hands, I might have a look at the detection algorithm. Otherwise we can close this PR and / or remove the coloring of the the search icon again. After all, what is the point of changing its color if the circumstances are incorrect?

@tobiasdiez
Copy link
Member

@lenhard If you indeed have time to look at the search algorithm, please replace it completely ;-) #1975

@koppor
Copy link
Member

koppor commented Mar 22, 2018 via email

@stefan-kolb
Copy link
Member

Actually there should be tests for it then, as this is not a UI feature but the detection is logic based...

@lenhard
Copy link
Member Author

lenhard commented Mar 27, 2018

Did we update the antlr stuff after v3.6? Because the query "progress" actually is a valid grammar-based query that compiles with our antlr code. That's the reason for the "wrong" coloring.

I have now added code that checks if a query consists only of word / whitespace characters and/or digits and uses a normal contains-based query for that. Thus, grammar-based searches are only executed when special symbols are used ALTHOUGH our grammar is more powerfull than that. The terms mentioned by @koppor above are now colored as expected. @koppor: I hope this limitation is what is wanted. Please do some testing to see if this matches your expectations.

Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments. In general, it resolves the issue!

@@ -85,7 +85,7 @@ private String getLocalizedRegularExpressionDescription() {
}

public boolean isGrammarBasedSearch() {
return rule instanceof GrammarBasedSearchRule;
return rule instanceof GrammarBasedSearchRule || rule instanceof RegexBasedSearchRule;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should regex really be treated as grammar-based search? I would not treat it like that, because regex search is orthogonal to grammar-based search. One can activate it in addition.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least in the documentation: https://help.jabref.org/en/Search#search-modes they are listed under the heading of "advanced search". But I can easily change that of course.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the help accordingly to also reflect that regular expressions are orthogonal. 😇

Could you additionally add a comment there that this is the "Advanced Search" described in the help? I know, this contradicts DDD, but I think, it is OK in this place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I adapted the code accordingly.

/**
* Returns the appropriate search rule that fits best to the given parameter.
*/
public static SearchRule getSearchRuleByQuery(String query, boolean caseSensitive, boolean regex) {
if (StringUtil.isBlank(query)) {
if (isSimpleQuery(query)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reads good!

@@ -25,6 +29,10 @@ public static SearchRule getSearchRuleByQuery(String query, boolean caseSensitiv
}
}

private static boolean isSimpleQuery(String query) {
return StringUtil.isBlank(query) || simpleExpression.matcher(query).matches();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you really need both? The current regex has a star (*) at the end, which means zero (0) ore more matches. So, the empty string should match, too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, that sounds reasonable. I removed the StringUtil dependency and as far as I can see there is no difference in the search.

@koppor
Copy link
Member

koppor commented Apr 2, 2018

In general good. Minor issues - not sure whether they should be fixed separately.

j - OK:

grafik

- not OK:

grafik

Minor issue:

When I clear the field using Ctrl+A and then Delete (after an advanced search), the marker is still advanced:

grafik

Otherwise: LGTM :)

@koppor koppor added this to the v4.2 milestone Apr 3, 2018
@lenhard
Copy link
Member Author

lenhard commented Apr 6, 2018

Thanks for the comments @koppor

I fixed all the glitches you described and this PR should now be ready.

@koppor koppor merged commit be91964 into master Apr 12, 2018
@koppor koppor deleted the switch-search-mode-color branch April 12, 2018 11:53
@koppor koppor removed the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Apr 12, 2018
Siedlerchr added a commit that referenced this pull request Apr 13, 2018
* upstream/master:
  Pdf exporter - delete xmp actions in the menu bar and the cli option (#3947)
  Improve search performance (#3950)
  New Crowdin translations (#3949)
  Update dependencies for junit, mockito and checkstyle (#3951)
  Add XMP Exporter (#3895)
  Switch colors of search icon for the two search modes (#3871)

# Conflicts:
#	src/main/java/org/jabref/gui/search/GlobalSearchBar.java
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants