Closed koppor closed 1 year ago
Implementation idea: Use UnkownField as basis
The user can be obtained from the preferences: preferencesService.getFilePreferences().getUser()
For the following explanation, userid
holds the current user name (via OwnerPreferences#getDefaultOwner())
@Misc{case1,
}
@Misc{case2,
comment = {general-comment},
}
@Misc{case3,
comment-userid = {userid's comment},
}
@Misc{case4a,
comment-userid = {userid's comment},
comment-otheruserid = {otheruserid's comment},
}
@Misc{case4b,
comment-otheruserid = {otheruserid's comment},
comment-veryotheruserid = {verotheruserid's comment},
}
@Misc{case5a,
comment = {general-comment},
comment-userid = {userid's comment},
comment-otheruserid = {otheruserid's comment},
}
@Misc{case5b,
comment = {general-comment},
comment-otheruserid = {otheruserid's comment},
comment-veryotheruserid = {verotheruserid's comment},
}
The content of the tab "Comments" needs to be modified.
This tab should list all comments. It should offer a button to add or to modify a comment:
Here, the entry already has a comment of the userid.
Here, the current user did not put any comment. Thus, "Add new comment" is displayed at the bottom". If pressed, a new comment field is added, and the focus is in the new text field
After pressing of the button:
TLDR: Try "Second Implementation Proposal" and see if it works. If not, go for "First Implementation Proposal".
The Java code needs to be extended by a class "CommentsTab". See OptionalFieldsTab.java for an example of a generic tab implementation. MathSciNetTab.java is another tab, which offers a kind of special functionality. It shows only if a MathSciNetId is present.
As a first step, one could focus on showing and editing functionality (and ignore the need for an addition. As workaround, that can then be done using the bibtex source tab).
Implement determineFieldsToShow
in the new CommentsTab
class similar to OtherFieldsTab.java. Just show user comment fields there.
The current implementation is too generic to be used.
Currently, in the preferences, the user determines that comments should be rerendered in a tab.
This is then handled at EntryEditor.java.
// General fields from preferences
for (Map.Entry<String, Set<Field>> tab : entryEditorPreferences.getEntryEditorTabList().entrySet()) {
entryEditorTabs.add(new UserDefinedFieldsTab(tab.getKey(), ...;
}
This is how the tab "Comments" appears.
Based on the knowledge gained from "Background", this generic solution could be reused. Instead of allowing fixed strings in the preferences, one could allow glob patterns. Then Comment:comment;comment-*
could be a valid entry. And JabRef "magically" collects all comments in the tab "Comments".
This, however, has the drawback that no new comment can be added. Nevertheless, during loading, there could always be an empty field comment-userid
be created. AFAIK during writing, JabRef skips empty fields. Thus, this could be the most clean solution.
Setting: As a research group, the BibTeX data is collaboratively managed. Some contributors might comment on a BibTeX entry (instead of commenting into the PDF). One might want to have tooling support to know from which contributor which comment comes from. (CloudRef offers that feature for PDF comments: https://github.com/JabRef/cloudref)
Implementation Hints
comment
fields should be donecomment
should still be displayedSide note: We have user-specific file directory, user- + host-specific
aux
file, now it's time for user-specific comment field. We should re-use the functionality to determine the usernameAlternative Implementation Possibilities
Following possibilities were discussed, but neglected: