Skip to content

CSL4LibreOffice - F [Real-time switching of CSL Styles] #12472

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

Merged
merged 51 commits into from
Feb 10, 2025

Conversation

subhramit
Copy link
Member

@subhramit subhramit commented Feb 8, 2025

Real-time switching of CSL Styles

Follow-up to #11712 and #12309
Closes #12309 (comment)
Closes https://github.com/JabRef/jabref-issue-melting-pot/issues/772 (internal)

Summary

  • On selecting a new style, we no longer have to manually remove and re-cite the previously cited entries to update them. On citing the next entry, all other citations in the document will also be updated to have the currently selected style.
  • Updates work within and across both in-text and non in-text citations.
  • Multiple instances of CSLCitationOOAdapter are no longer created for each cite action. Only one instance throughout for a LibreOffice document connection.
  • Bug fix: Formatting of numeric styles with tags such as <sup>5</sup> used to be lost due to direct UNO setText calls in the number reassignment feature. Now, OOTextIntoOO.write is used, which properly parses those tags to apply formatting.
  • Better performance: CSL integration is now faster when interacting with the document. This was achieved changing the order of operations in certain methods and removing unnecessary UNO API calls/redundant interaction steps.
  • A lot of refactoring - which also led to extraction of methods for which now tests could be added.

Limitations

  • Works only for CSL styles

Mandatory checks

  • I own the copyright of the code submitted and I licence it under the MIT license
  • Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
  • Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

@subhramit
Copy link
Member Author

subhramit commented Feb 8, 2025

PR #12309 can be merged independent of this.

github-actions[bot]

This comment was marked as resolved.

@subhramit subhramit added component: libre-office dev: code-quality Issues related to code or architecture decisions labels Feb 8, 2025
@subhramit subhramit added this to the 6.0-beta milestone Feb 8, 2025
@subhramit subhramit added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Feb 8, 2025
github-actions[bot]

This comment was marked as resolved.

@subhramit
Copy link
Member Author

subhramit commented Feb 8, 2025

@calixtus Architecture violation is due to the stateManager being used in the adapter (which is inside /logic).
I make a single instance of the adapter for one libreoffice connection in OOBibBase (which is inside /gui) - so if we were to pass the collected databases down via it, the architecture wouldn't be violated, but we will have to re-establish the document connection every time we add a new library to get the latest state of databases.

One thought was instead of constructor injection for the adapter, we could obtain the databases in OOBibBase itself via a separate function call to it - but that will create a reverse-dependency of OOBibBase in the adapter (which is below it in the hierarchy). I guess that would also violate the architecture as we'd still be using the instance of a gui class inside logic.

Making a new instance of the adapter (and passing latest databases via constructor) every time we add or remove a new library would be the architecturally correct solution, but it didn't make sense.
So this was the solution I stuck to.

@Siedlerchr
Copy link
Member

You could maybe add a supplier callback to be able to get the state manager's list of database from a UI context

@calixtus
Copy link
Member

calixtus commented Feb 8, 2025

The real question is, why in logic (business logic, alternating bibentries and so on) one has to get an observable list of currently open databases? The failing architecture test is just telling us, that thre is stuff that does not belong there. I need to take a deeper look. I can probably look tomorrow at it.

@subhramit
Copy link
Member Author

The real question is, why in logic (business logic, alternating bibentries and so on) one has to get an observable list of currently open databases? The failing architecture test is just telling us, that thre is stuff that does not belong there.

That's because there is no method in /logic that gets us the freshest state of databases when called. We will need to bind it to a change listener if we want to access it indirectly while maintaining the gui/logic separation. Then, we can use this current "set" value of databases in logic.

I need to take a deeper look. I can probably look tomorrow at it.

Sure!

@HoussemNasri
Copy link
Member

@subhramit please mark the review comments that you handled as resolved.

github-actions[bot]

This comment was marked as resolved.

github-actions[bot]

This comment was marked as resolved.

Siedlerchr
Siedlerchr previously approved these changes Feb 10, 2025
calixtus
calixtus previously approved these changes Feb 10, 2025
@calixtus calixtus added this pull request to the merge queue Feb 10, 2025
@subhramit subhramit dismissed stale reviews from calixtus and Siedlerchr via defe43a February 10, 2025 20:01
@subhramit subhramit removed this pull request from the merge queue due to a manual request Feb 10, 2025
@Siedlerchr Siedlerchr enabled auto-merge February 10, 2025 20:02
github-actions[bot]

This comment was marked as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: libre-office dev: code-quality Issues related to code or architecture decisions status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants