Skip to content
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

@String handling seems broken #12174

Open
2 tasks
jspitz opened this issue Nov 11, 2024 · 9 comments
Open
2 tasks

@String handling seems broken #12174

jspitz opened this issue Nov 11, 2024 · 9 comments

Comments

@jspitz
Copy link

jspitz commented Nov 11, 2024

JabRef version

5.15 (latest release)

Operating system

GNU / Linux

Details on version and operating system

JabRef 5.15--2024-07-10--1eb3493
Linux 6.11.6-2-default amd64
Java 21.0.2
JavaFX 22.0.1+7

Checked with the latest development build (copy version output from About dialog)

  • I made a backup of my libraries before testing the latest development version.
  • I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

Trying to use @String constants with JabRef I am facing multiple challenges:

  1. Trying to enter a new string I follow the docs and use the string editor. However, whatever I do, any string name I enter is reset to "NewString" as soon as I leave the widget, and any value reset to empty. So I end up with @String{NewString = {}}
  2. After having fixed this in a text editor (let's say to @String{ffm = {Frankfurt a.\,M.}}) the string is correctly listed in the string editor. But if I want to use it in the location field as advised, namely #ffm#, JabRef wrongly writes location = {#ffm#}, (rather than location = ffm,)
  3. Now if I fix this in the code editor, the location widget keeps on displaying #ffm#; fine. But as soon as I change anything in this entry (say, fill in the langid field), the source changes back to location = {#ffm#}, (and the output is broken)

Unless I have missed something, it looks like this feature is completely broken in this version.

@jspitz
Copy link
Author

jspitz commented Nov 11, 2024

Ad 3. I have just learned that the fields that keep string constants need to be defined in prefs these days. Adding location there solves this issue, although I think this definitely needs to be documented

The string editor problem persists.

@Siedlerchr
Copy link
Member

@jspitz Try hitting enter after you enter the new String.

@jspitz
Copy link
Author

jspitz commented Nov 11, 2024

@jspitz Try hitting enter after you enter the new String.

Tried that, didn't work

@Siedlerchr
Copy link
Member

Before you leave the field (after you entered the text), you have to hit enter

@jspitz
Copy link
Author

jspitz commented Nov 11, 2024

Hm, trying again, it does work. Don't know why I failed in the first place. So it's really all about documentation.

@jspitz
Copy link
Author

jspitz commented Nov 11, 2024

(or maybe make the UI a bit more accessible)

@Siedlerchr
Copy link
Member

Glad it worked! Unfortunately we cannot fix this "commit cell value on enter" as it's a javafx problem but we will try to improve the UI and the docs

@koppor
Copy link
Member

koppor commented Nov 11, 2024

Glad it worked! Unfortunately we cannot fix this "commit cell value on enter" as it's a javafx problem but we will try to improve the UI and the docs

https://github.com/xzel23/utility/blob/main/utility-fx-controls/src/main/java/com/dua3/utility/fx/controls/TableCellAutoCommit.java ?

Refs https://github.com/JabRef/jabref-issue-melting-pot/issues/683

@jspitz
Copy link
Author

jspitz commented Nov 12, 2024

I don't know javafx well, but you can you add two line edit widgets (for key and value, respectively) and an Add button on top of the table? That's what I would go for, most probably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants