forked from JabRef/jabref
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/main'
# Conflicts: # src/main/java/org/jabref/gui/entryeditor/DeprecatedFieldsTab.java # src/main/java/org/jabref/gui/entryeditor/EntryEditor.java # src/main/java/org/jabref/gui/entryeditor/RequiredFieldsTab.java # src/main/java/org/jabref/gui/entryeditor/UserDefinedFieldsTab.java # src/main/java/org/jabref/preferences/JabRefPreferences.java # src/main/java/org/jabref/preferences/PreferencesService.java # src/main/resources/l10n/JabRef_en.properties
- Loading branch information
Showing
89 changed files
with
3,595 additions
and
40 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,61 @@ | ||
| --- | ||
| nav_order: 0031 | ||
| parent: Decision Records | ||
| --- | ||
| <!-- markdownlint-disable-next-line MD025 --> | ||
| # Store chats alongside database | ||
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| Chats with AI should be stored somewhere. But where and how? | ||
|
|
||
| ## Considered Options | ||
|
|
||
| * Inside `.bib` file | ||
| * In local user folder | ||
| * Alongside `.bib` file | ||
|
|
||
| ## Decision Outcome | ||
|
|
||
| Chosen option: "Alongside `.bib` file", because | ||
| simple to implement and gives the user the ability to share or not to share the chats. | ||
|
|
||
| ### Positive Consequences | ||
|
|
||
| * Simple implementation | ||
| * The user can send the chats file alongside the `.bib` file if they want to share the chats. If users do not want | ||
| to share the messages, then they can omit the chats file | ||
| * `.bib` files is kept clean | ||
|
|
||
| ### Negative Consequences | ||
|
|
||
| * User may not expect that a new file will be created alongside their `.bib` (or other LaTeX-related) files | ||
| * It may be not convenient to share both files (`.bib` file and chats file) in order to share chat history. | ||
| * If `.bib` files are edited externally (meaning, not inside the JabRef), then chats file will not be updated correspondingly | ||
| * If user moves `.bib` file, they should move the chats file too | ||
|
|
||
| ## Pros and Cons of the Options | ||
|
|
||
| ### Inside `.bib` file | ||
|
|
||
| * Good, because we already have a machinery for managing the fields and other information of BIB entries | ||
| * Good, because chats are stored inside one file, and if the `.bib` file is moved, the chat history is preserved | ||
| * Bad, because there may be lots of chats and messages and `.bib` file become too cluttered and too big which slows down the processing of `.bib` file | ||
| * Bad, because if user shares a `.bib` file, they will also share chat messages, but chats are not ideal, so user may not | ||
| want to share them | ||
|
|
||
| ### In local user folder | ||
|
|
||
| One can use `%APPDATA%`, where JabRef stores the Lucene index and other information. | ||
| See `org.jabref.gui.desktop.os.NativeDesktop#getFulltextIndexBaseDirectory` for use in JabRef and | ||
| <https://github.com/harawata/appdirs> for general information. | ||
|
|
||
| * Good, because `.bib` file is kept clean | ||
| * Good, because chat messages are saved locally | ||
| * Neutral, because may be a little harder to implement | ||
| * Bad, because chat messages cannot be easily shared | ||
| * Bad, because when path of a `.bib` file is changed, the chats are lost | ||
|
|
||
| ### Alongside `.bib` file | ||
|
|
||
| Refer to positive and negative consequences of the decision outcome. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| --- | ||
| nav_order: 0032 | ||
| parent: Decision Records | ||
| --- | ||
| # Store chats in MVStore | ||
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| This is a follow-up to [ADR-031](0031-store-chats-alongside-database.md). | ||
|
|
||
| The chats with AI should be saved on exit from JabRef and retrieved on launch. We need to decide the format of | ||
| the serialized messages. | ||
|
|
||
| ## Decision Drivers | ||
|
|
||
| * Easy to implement and maintain | ||
| * Memory-efficient (because JabRef is said to consume much memory) | ||
|
|
||
| ## Considered Options | ||
|
|
||
| * JSON | ||
| * MVStore | ||
| * Custom format | ||
|
|
||
| ## Decision Outcome | ||
|
|
||
| Chosen option: "MVStore", because it is simple and memory-efficient. | ||
|
|
||
| ## Pros and Cons of the Options | ||
|
|
||
| ### JSON | ||
|
|
||
| * Good, because allows for easy storing and loading of chats | ||
| * Good, because cross-platform | ||
| * Good, because widely used and accepted, so there are lots of libraries for JSON format | ||
| * Good, because it is even possible to reuse the chats file for other purposes | ||
| * Bad, because too verbose (meaning the file size could be much smaller) | ||
|
|
||
| ### MVStore | ||
|
|
||
| * Good, because automatic loading and saving to disk | ||
| * Good, because memory-efficient | ||
| * Bad, because the order of messages need to be "hand-crafted" (e.g., by mapping from an Integer to the concrete message) | ||
|
|
||
| ### Custom format | ||
|
|
||
| * Good, because we have the full control | ||
| * Bad, because involves writing our own language and parser | ||
| * Bad, because we need to implement optimizations found in databases on our own (storing some data in RAM, other on disk) |
69 changes: 69 additions & 0 deletions
69
docs/decisions/0033-use-citation-key-for-grouping-chat-messages.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| --- | ||
| nav_order: 0033 | ||
| parent: Decision Records | ||
| --- | ||
| <!-- markdownlint-disable-next-line MD025 --> | ||
| # Use citation key for grouping chat messages | ||
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| Because we store chat messages not inside a BIB entry in `.bib` filecc, the chats file is represented as a map to | ||
| BIB entry and a list of messages. We need to specify the key of this map. Turns out, it is not that easy. | ||
|
|
||
| ## Decision Drivers | ||
|
|
||
| * The key should exist for every BIB entry | ||
| * The key should be unique along other BIB entries in one library file | ||
| * The key should not change at run-time, between launches of JabRef, and should be cross-platform (most important) | ||
|
|
||
| ## Considered Options | ||
|
|
||
| * `BibEntry` Java object | ||
| * `BibEntry` ID | ||
| * Citation key | ||
| * Use `ShareId` | ||
|
|
||
| ## Decision Outcome | ||
|
|
||
| Chosen option: "Citation key", because this is the only choice that complains to the third point in Decision Drivers. | ||
|
|
||
| ### Positive Consequences | ||
|
|
||
| * Easy to implement | ||
| * Cross-platform | ||
|
|
||
| ### Negative Consequences | ||
|
|
||
| * If the citation key is changed externally, then the chats file becomes out-of-sync | ||
| * Additional user interaction in order to make the citation key complain the first and second points of Decision Drivers | ||
|
|
||
| ## Pros and Cons of the Options | ||
|
|
||
| ### `BibEntry` Java object | ||
|
|
||
| Very bad, because it works only at run-time and is not stable. | ||
|
|
||
| ### `BibEntry` ID | ||
|
|
||
| JabRef stores a unique identifier for each BibEntry. | ||
| This identifier is created on each load of a library (and not stored permanently). | ||
|
|
||
| Very bad, for the same reasons as `BibEntry` Java object. | ||
|
|
||
| ### Citation key | ||
|
|
||
| * Good, because it is cross-platform, stable (meaning stays the same across launches of JabRef) | ||
| * Bad, because it is not guaranteed that citation key exists on BIB entry, and that it is unique across other | ||
| BIB entries in the library | ||
|
|
||
| ### Use `ShareId` | ||
|
|
||
| [ADR-0027](0027-synchronization.md) describes the procedure of synchronization of a Bib(La)TeX library with a server. | ||
| Thereby, also local and remote entries need to be kept consistent. | ||
| The solution chosen there is that the **server** creates a UUID for each entry. | ||
|
|
||
| This approach cannot be used here, because there is no server running which we can ask for an UUID of an entry. | ||
|
|
||
| ## More Information | ||
|
|
||
| Refer to [issue #160](https://github.com/JabRef/jabref/issues/160) in JabRef main repository |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| --- | ||
| nav_order: 0034 | ||
| parent: Decision Records | ||
| --- | ||
| <!-- markdownlint-disable-next-line MD025 --> | ||
| # Use TextArea for chat message content | ||
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| This decision record concerns the UI component that is used for rendering the content of chat messages. | ||
|
|
||
| ## Decision Drivers | ||
|
|
||
| * Looks good (renders Markdown) | ||
| * Can select and copy text | ||
| * Have good performance | ||
|
|
||
| ## Considered Options | ||
|
|
||
| * Use TextArea | ||
| * Use a [third-party package](https://github.com/JPro-one/jpro-platform) | ||
| * Use a Markdown parser and convert AST nodes to JavaFX TextFlow elements | ||
| * Use a Markdown parser to convert content into HTML and use a WebView for one message | ||
| * Use a Markdown parser and WebView for the whole chat history | ||
|
|
||
| ## Decision Outcome | ||
|
|
||
| Chosen option: "Use TextArea". | ||
| All other options require some time to implement. | ||
| Some of the options doesn't support text selection and copying, | ||
| which for now we value better than Markdown rendering. | ||
|
|
||
| ## Pros and Cons of the Options | ||
|
|
||
| ### Use TextArea | ||
|
|
||
| * Good, because it is easy to implement | ||
| * Good, because it supports text selection and copying | ||
| * Bad, because it cannot render Markdown | ||
| * Bad, because default JavaFX's `TextArea` shrinks | ||
|
|
||
| ### Use a third-party package | ||
|
|
||
| There seems to be only one package for JavaFX that provides a ready-to-use UI node for Markdown rendering. | ||
|
|
||
| * Good, because it is easy to implement | ||
| * Good, because it renders Markdown | ||
| * Good, because it renders Markdown to JavaFX nodes (does not use a `WebView`) | ||
| * Good, because complex elements from Markdown are supported (tables, code blocks, etc.) | ||
| * Bad, because it has very strange issues and architectural flaws with styling | ||
| * Bad, because it does not support text selection and copying (because of underlying JavaFX `Text` nodes) | ||
|
|
||
| ### Use a Markdown parser and convert AST nodes to JavaFX TextFlow elements | ||
|
|
||
| * Good, because we will support Markdown | ||
| * Good, because no need to write a Markdown parser from scratch | ||
| * Good, because does not use a WebView | ||
| * Good, because easy styling | ||
| * Bad, because we need some time to implement Markdown AST -> JavaFX nodes converter | ||
| * Bad, because rendering tables and code blocks may be hard | ||
| * Bad, because it will not support text selection and copying | ||
|
|
||
| ### Use a Markdown parser to convert content into HTML and use a WebView for one message | ||
|
|
||
| * Good, because there are libraries to convert Markdown to HTML | ||
| * Good, because may be easier to implement than other choices (except `TextArea`) | ||
| * Good, because it supports text selection and copying | ||
| * Bad, because it may be a problem to connect JavaFX CSS to `WebView` | ||
| * Bad, because one `WebView` for one message is resourceful | ||
|
|
||
| ### Use a Markdown parser and WebView for the whole chat history | ||
|
|
||
| * Good, because there are libraries to convert Markdown to HTML | ||
| * Good, because it supports text selection and copying | ||
| * Bad, because it may be a problem to connect JavaFX CSS to `WebView` | ||
| * Bad, because it may be a problem to correctly communicate with Java code and `WebView` to add new messages | ||
|
|
||
| ## More Information | ||
|
|
||
| Actually we used an `ExpandingTextArea` from `GemsFX` package so the content can occupy | ||
| as much space as it needs in the `ScrollPane`. | ||
|
|
||
| About the selection and copying, this goes down to fundamental issue from JavaFX. | ||
| `Text` and `Label` cannot be selected by any means. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.