Skip to content

Refine default preview#7093

Merged
Siedlerchr merged 1 commit into
masterfrom
refine-default-preview
Nov 19, 2020
Merged

Refine default preview#7093
Siedlerchr merged 1 commit into
masterfrom
refine-default-preview

Conversation

@koppor

@koppor koppor commented Nov 10, 2020

Copy link
Copy Markdown
Member

This applies the quick fix proposed at #7083. To implement the full functionality a longer thought on previews is requried.

I think, the first proposal is a good step towards a better preview: Show the full names of authors and editors, to list the editor only if no author is present, have the year ealier.

I disliked the default preview style, but could not make any (good) proposal. We need to keep the custom preview, because humanities have special requirements not met by CSL (especially displaying the comments field, ...)

  • Change in CHANGELOG.md described (if applicable)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

@AtrusRiven

Copy link
Copy Markdown

Thanks very much for the quick reaction! 🥇

@AtrusRiven

Copy link
Copy Markdown

You are absolutely right, comments are very necessary in the preview for they provide a quick overview of the relevance, the scope, the very own opinion about a literature. I suppose with this approach, the preview is getting clearly longer (I myself let the preview display my custom manual citation of every entry, too. Usually there's an abstract for every entry, too).

Are there already considerations to be able to place the entry editor with the preview beside the table of entries (to its right) in order to get more vertical space? The lines of the preview or metadata are often so short that a vertical arrangement would provide more clarity.

@AtrusRiven

Copy link
Copy Markdown

I'd like to contribute to the development of the preview. I'm no programmer but could modify the preview style (although It's not very userfriendly, as you, @koppor, have mentioned) and could finalize entrytype-sensitivity and other requirements.

@Siedlerchr

Copy link
Copy Markdown
Member

We have to be careful that we don't hit the character limit of the registry value in Windows. Currently the preview is stored in the registry on windows.
https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-element-size-limits

16,383 characters
The ideal solution would be to store the path to the file in the registry.

@AtrusRiven

AtrusRiven commented Nov 12, 2020

Copy link
Copy Markdown

Wasn't there somewhere a mentioning of outsourcing the preview "code" in a text file? Or this is about the storage of the whole preview output?

@calixtus

calixtus commented Nov 12, 2020

Copy link
Copy Markdown
Member

We have to be careful that we don't hit the character limit of the registry value in Windows. Currently the preview is stored in the registry on windows.
docs.microsoft.com/en-us/windows/win32/sysinfo/registry-element-size-limits

16,383 characters
The ideal solution would be to store the path to the file in the registry.

The changes in this PR seem to make the pref settings smaller than before, so I would say that this PR is fine.
So I would approve this.

But I agree. in future this should be changed to a text file in .jabref in the user folder.

@AtrusRiven

Copy link
Copy Markdown

I overhauled entry preview in Documentation and created pull request (JabRef/user-documentation#329)

@Siedlerchr Siedlerchr added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Nov 14, 2020
@Siedlerchr Siedlerchr merged commit 0412684 into master Nov 19, 2020
@Siedlerchr Siedlerchr deleted the refine-default-preview branch November 19, 2020 11:04
@koppor

koppor commented Nov 22, 2020

Copy link
Copy Markdown
Member Author

I'd like to contribute to the development of the preview. I'm no programmer but could modify the preview style (although It's not very userfriendly, as you, @koppor, have mentioned) and could finalize entrytype-sensitivity and other requirements.

Looking forward to this. Will work on Linux at least. For Windows, we have to think about work-arounds then. For instance the "memory stick mode" see https://docs.jabref.org/installation#portable-version.

@Siedlerchr

Copy link
Copy Markdown
Member

Memory stick mode is a bit misleading, it still acesses and writes to the registry, but just addtionally serializes the preferences to an xml file.

@AtrusRiven

Copy link
Copy Markdown

At the moment, I'm working on some minor improvements to the entry previews default customized preview style. In df1a6fa where @koppor included my first changes, every line of the code for the entry preview ends with __NEWLINE__" although the style code itself contains <BR> where a line break is intended and although not every line break in the code represents a line break in the display output (in the entry preview itself). So, how does __NEWLINE__" relate to <BR>? Thanks for an explanation.

@koppor

koppor commented Nov 29, 2020

Copy link
Copy Markdown
Member Author

I was not that sure how to deal with ___NEWLINE___. It is replaced by a hard line break at the output.

If I understand you correctly, a simple <BR> also works? Then, it is fully OK to continue with BR instead of NEWLINE.

Think, this is an old relict of the different UI technology we used a few years ago.

@AtrusRiven

Copy link
Copy Markdown

It appears to me that ___NEWLINE___ is to be ignored when adjusting the entry preview style because when adjusting the entry preview style code inside JabRef it completely works without ___NEWLINE___. So is it necessary to add a ___NEWLINE___ in the code when the styling in the first place works without ___NEWLINE___?

@AtrusRiven

AtrusRiven commented Dec 13, 2020

Copy link
Copy Markdown

Implemented some corrections which have not been considered in my first draft that @koppor kindly commited.

Siedlerchr pushed a commit that referenced this pull request Dec 19, 2020
…on to #7093) (#7185)

* Update JabRefPreferences.java

Modifications in Entry Preview (7093 and 7083)

* Update JabRefPreferences.java

Minor Correction

* Additions for #7185

"=" deleted
Siedlerchr added a commit that referenced this pull request Dec 21, 2020
* upstream/master: (33 commits)
  Bump archunit-junit5-api from 0.14.1 to 0.15.0 (#7220)
  Bump unoloader from 7.0.3 to 7.0.4 (#7214)
  Bump guava from 30.0-jre to 30.1-jre (#7218)
  Bump xmpbox from 2.0.21 to 2.0.22 (#7217)
  Bump classgraph from 4.8.94 to 4.8.97 (#7211)
  Bump byte-buddy-parent from 1.10.18 to 1.10.19 (#7216)
  Bump archunit-junit5-engine from 0.14.1 to 0.15.0 (#7215)
  Bump org.beryx.jlink from 2.22.3 to 2.23.0 (#7212)
  Add missing author
  Remove field check for journal abbrev in entry editor (#7208)
  Improvements for Entry Preview (in the context of #7083 and in addition to #7093) (#7185)
  Fix pdf content importer exception if DOI is empty (#7207)
  New translations JabRef_en.properties (Turkish) (#7204)
  New Crowdin updates (#7198)
  New Crowdin updates (#7192)
  Added missing test
  Changed tests to parameterized tests
  Extraction of Globals.prefs.put and .get (#7121)
  Fix newly added entry not synced to db (#7178)
  Bump org.eclipse.jgit from 5.9.0.202009080501-r to 5.10.0.202012080955-r (#7187)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

4 participants