Resolve crossrefs and strings in main table

[oscargus]

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.

• Change in CHANGELOG.md described
• Manually tested changed features in running JabRef

[ilippert]

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.

[oscargus]

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.

[oscargus]

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.

[koppor]

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)

[oscargus]

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.

[koppor]

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.

[oscargus]

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).
resolvedatabase.txt

[koppor]

I checked it with normal JabRef config. The "background color for resolved fields" doesn't seem to have any effect, but it should.

normal operation

resolved

[oscargus]

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...

[oscargus]

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.

[koppor]

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.

[oscargus]

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?

[koppor]

Remove this line - the next line contains the same information (and more)

[oscargus]

Not to mention the grammatical error in the next line... I would like to blame union merge. ;-)

[koppor]

Shouldn't it be singular? "Color code for resolved fields"?

[oscargus]

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.

[koppor]

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.

[oscargus]

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).

[oscargus]

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?

[oscargus]

I added automatic enabling for those three cases...

[DesBw]

Here is one suggestion about the Crossref:
It would be nice if the BookTitle could be displayed, rather than the Title

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:
crossrefered

https://snag.gy/JEk4dC.jpg

[ilippert]

@Dellu
it might be the case that you can achieve the desired effect by setting in the jabref preferences|Entry table columns| a field name to e.g. title/booktitle/chapter.
The effect is that if available the first, and if not available the second field name (and so on) content for the field is shown.

[ilippert]

sorry, yes, now I see more clearly. My fault for commenting too swiftly.