Refine default preview

[koppor]

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]

Thanks very much for the quick reaction! 🥇

[AtrusRiven]

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]

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]

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]

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]

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]

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

[koppor]

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]

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]

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]

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]

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]

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