Add "Do not ask again" for empty entry confirmation in JabRef

[ruoyu-qian]

Following up on #8096

• add checkbox for do not ask for this kind of issue again for empty entry confirmations

Originally posted by @ThiloteE in #8096 (comment)

[ThiloteE]

@ruoyu-qian. If this is ticked, will Jabref remember the action (delete/no delete) that was chosen in the checkbox and do the same thing whenever Jabref will be closed, or will it just cancel the dialogue box from ever emerging again?

[ruoyu-qian]

@ThiloteE Sorry, you were right! My previous implementation would not remember user's choice. I made some changes. It now should remember the action (delete/keep) that was chosen when the user checked "do not ask again".

[ThiloteE]

I was just curious, but thaaaaaaanks 😁

[LIM0000]

Hi, I am interested to fix the issues that have been mentioned in #8296 and #8297.

Solution for #8296:
I am planning to change the use of showCustomButtonDialogAndWait() to showConfirmationDialogWithOptOutAndWait() so that we could add a checkbox for do not ask for this kind of issue again. if user has ticked on the checkbox, Jabref will have to remember this action and no longer display this dialog to user.

I am planning to look into issue in #8297 that causes a tab not to close properly once feature added for #8296.

[Siedlerchr]

Thanks for the interest, that sounds good.
The value of the checkbox is stored in the preferences, see Preferences Service
@calixtus which sub preferences should be used here?

[calixtus]

Dunno... Maybe EntryEditorPreferences?

[LIM0000]

Hi, I am working on issues #8297 about tab unable to close if a dialog box has been closed/cancelled.
The reason for this issue is that a tab can only be closed once. If close request has been sent to dialog box, the dialog box will close. However, event.consume() could prevent a tab from closing. Once this event has been triggered, the tab has assumed that it has been closed and no longer allow user to close the tab.

 libraryTab.setOnCloseRequest(event -> {
            closeTab(libraryTab);
            libraryTab.getDataLoadingTask().cancel();
            event.consume();
        });

Questions

1. Is it possible to reassign the same event to the tab?
2. I have tried to create a new tab with previous contents and remove the previous tab. However, new tab introduces new issue that causes tab next to it unclickable.

[ThiloteE]

@LIM0000 thank you for the research and amount of thought you have put into this. I would ask you to open a pull request so that the technical details can be discussed over there.

• Issues should be about issues and what people desire.
• Pull requests should contain discussion about the actual code and technical solution.

There are some reasons for this:

1. People that open issues may not necessarily know about the coding aspect.
2. Pull requests can sometimes be hundreds of lines of code long. There can be huge discussions.
3. Sometimes there are multiple pull-requests that try to solve the same problem but are incompatible with each other. Discussing coding details in the same thread can be very confusing. In that case I would suggest, only the discussion about "PR 1 is better than PR 2" should happen in the thread with the initial issue.

[Siedlerchr]

@LIM0000 Thanks again for the investigation. Tricky thing. So I guess the EventHandler is no longer called when you click again because the tab is assumed to be closed?
Can you refire the event or is that the buton cannot be clicked anylonger?
https://github.com/openjdk/jfx/blob/e24eeceb28741f4a044ea2cb0cb23a1174b27c66/modules/javafx.controls/src/main/java/javafx/scene/control/Tab.java#L719

[koppor]

@ThiloteE @Siedlerchr We discussed in the last dev call. Should we change the requirement to remove the dialog completely and just always delete empty entries? Empty entries only have the entry type as information. I think, the information "Oh, I wanted to create an artcile" is not really helpful for a user, is it?

[calixtus]

I wouldn't manipulate the bib without asking the user. There is always an edge case.

[koppor]

This is supersed by the decsion #8645 (comment). We a) add a checker and b) genreated the FIXME BibTeX key.