-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Resolve crossrefs and strings in main table #1644
Conversation
Am not sure what counts as a large database. My database has currently 9883 entries, out of which 591 use crossref information. I do not perceive any slowdown in daily use. |
Thanks @ilippert! I'd say that it counts as a large database here, especially considering the amount of crossref entries. I've updated the code a bit and added a CHANGELOG entry describing the change. |
3c47e07
to
ddd0bef
Compare
e7d8e2b
to
080517e
Compare
OK, I thought it would make sense if one could see which fields are resolved (if nothing else to not confuse some users), so I added that as well. This is a different setting since I think there are different things to want to see required and optional fields and which field that are resolved. At the moment resolved field have precedence if both are enabled. Good thing is that the check for optional/required/resolved is now only done if any of the flags are enabled, and, hence, the rendering should be slightly faster compared to before when not enabled. |
3f43fd6
to
0912d94
Compare
|
||
Non-ASCII_encoded_character_found= | ||
|
||
Background_color_for_resolved_fields= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would just add the lines of the language strings you added. The other lines should come in in different ways (other PR, via master branch). Otherwise, we will have duplicate lines (refs #1719)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is probably the reason of not having union merge. However, normally I check these things and unless it takes very long time to merge the PR it doesn't happen that much.
Could you add an example bib file (maybe artificially generated) to show the effects of your change. I see your screenshot, but I want to try it for myself. -- Up to now, I did not use resolved fields at all as it seems that bibtex/biblatex resolves them differently and I don't know, how far JabRef follows this. Moreover, copy and paste does not work intuitively, but this is addressed at #1677. |
Here is a bib-file to show a bit (must use extension .txt for GitHub). Make sure you show year, date, and month (this also shows that we should try to normalize the month display based on database type, I think). |
214fa46
to
f4db19e
Compare
You mean it should be enabled by default or that enabling it doesn't lead to any changes? There should be a light-gray background... |
f4db19e
to
92df80f
Compare
OK, I think I understand what you meant. Either way, I fixed a problem related to that now. Which leads to another question: how should we deal with marking mandatory fields if there are, say, "author/editor" and exactly one of them is mandatory, both are mandatory, or it is mandatory to have one of them? Now, the column name is simply compared with the list of mandatory fields, so it only works for single field columns. |
92df80f
to
46a4415
Compare
46a4415
to
10f033f
Compare
The "Background color for resolved fields" seems to have no effect here: Regarding "author/editor" -> Why not splitting the name using "/" and then checking each of them during the column name comparison? I know, we should use some cool data structures. Since we are aiming for JavaFX, this can be that dirty IMHO. |
You need to tick "Color codes for resolved fields". The splitting can be easily done. The question is just what the logic should be? Say that a column shows "author/doi", "author" is a mandatory field, but only the "doi" is present. Color? |
@@ -28,6 +28,8 @@ We refer to [GitHub issues](https://github.com/JabRef/jabref/issues) by using `# | |||
- Added ISBN integrity checker | |||
- Added filter to not show selected integrity checks | |||
- The contents of `crossref` and `related` will be automatically updated if a linked entry changes key | |||
- The information shown in the main table now resolves crossrefs and strings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this line - the next line contains the same information (and more)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to mention the grammatical error in the next line... I would like to blame union merge. ;-)
@@ -1680,3 +1680,5 @@ You_must_enter_at_least_one_field_name= | |||
Non-ASCII_encoded_character_found= | |||
|
|||
Toggle_web_search_interface= | |||
Background_color_for_resolved_fields= | |||
Color_codes_for_resolved_fields= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it be singular? "Color code for resolved fields"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are probably right. I thought about it when I wrote it, think of consistency and "fields", but you are correct, there is only one color. I'll fix it tomorrow.
Is it possible to enable "Color codes for resolved fields" as soon as one changes the color for resolved fields? Color: If (at least) one mandatory field is missing: Color it red. Otherwise, normal color. In your example, the field would be red: Some content is there, but not the mandatory one. |
Currently, only the number is colored red, so I do not think that is actually the answer. There may, for example, be another column with "editor" which is present and the entry is a book. I know it sounds complicated (and made up examples), but I thought about it and I do not really see what logic should be used for marking required and optional fields when there are multiple fields in one column. Maybe the easiest way is to just enable the resolved entry marking by default? While it is possible, with the current code structure it will be quite hacky (since the buttons are initialized in one loop, I will have to single it out, etc, now, since it is the last one, at the moment, it is quite reasonable, but not really a nice solution). |
For consistency one should in that case also do the same thing for the other color codes (required/optional) and grid lines. Maybe one can pass a JCheckButton to the ColorButton as an extra argument, passing null for all other cases? |
I added automatic enabling for those three cases... |
* master: Fix imports Rename NewFileDialog -> FileDialog Also cancel duplicate finder workflow on close button Removed/moved preferences which are constants implements JabRef#1767: Add Help Button to access new help page Fixed BibTeXMLImporter Set more default file filters in dialogs JabRef#1763 Resolve crossrefs and strings in main table (JabRef#1644) Rewrite bibtexml importer with JAXB parser (JabRef#1666) Moved a few more initialization to GUIGlobals.init() (JabRef#1756) Added program to generate a table of all characters and fixed some characters (JabRef#1766) Improve focus of the maintable after a sidepane gets closed (JabRef#1741) Table row height adjusts on Windows as the font scales with the menu (JabRef#1623) Added more characters to converters (JabRef#1761)
* Resolve crossrefs and strings in main table * Improved code and added CHANGELOG entry * Added special background color for resolved fields * Fixed comments * Fixed mandatory field coloring * Fixed CHANGELOG entry * Changed wording and made resolved coloring default * Added automatic enabling of color codes and grid lines on editing color
Here is one suggestion about the Crossref: That, is when the parent entry has only BookTitle (not the title--due to the problems of Bibtex; we cannot use the Title unless we migrate to BibLatex). Here is a Proceeding with the Booktitle: Collection Look at the following link: the Booktitle is not visible: |
@Dellu |
sorry, yes, now I see more clearly. My fault for commenting too swiftly. |
Based on a discussion in the forum, this is a quick hack to show the possibilities. Can be downloaded and tested from http://builds.jabref.org/resolvedfieldsinmaintable
It would be especially interesting for people with large databases with many strings to test it for performance. A better implementation can be done if this will make it to the released version. At least removing the commented out lines.