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

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

Closed
ruoyu-qian opened this issue Dec 5, 2021 · 12 comments
Closed

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

ruoyu-qian opened this issue Dec 5, 2021 · 12 comments
Labels
component: ui good first issue An issue intended for project-newcomers. Varies in difficulty.

Comments

@ruoyu-qian
Copy link
Contributor

ruoyu-qian commented Dec 5, 2021

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)

@ruoyu-qian ruoyu-qian changed the title Add "do not ask again" for Empty Entry Confirmation in JabRef Add "Do not ask again" for Empty Entry Confirmation in JabRef Dec 5, 2021
@ruoyu-qian ruoyu-qian changed the title Add "Do not ask again" for Empty Entry Confirmation in JabRef Add "do not ask again" for Empty Entry Confirmation in JabRef Dec 5, 2021
@ruoyu-qian ruoyu-qian changed the title Add "do not ask again" for Empty Entry Confirmation in JabRef Add "Do not ask again" for Empty Entry Confirmation in JabRef Dec 5, 2021
@ruoyu-qian ruoyu-qian changed the title Add "Do not ask again" for Empty Entry Confirmation in JabRef Add "Do not ask again" for empty entry confirmation in JabRef Dec 5, 2021
@ThiloteE
Copy link
Member

ThiloteE commented Dec 5, 2021

@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
Copy link
Contributor Author

@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
Copy link
Member

ThiloteE commented Dec 5, 2021

I was just curious, but thaaaaaaanks 😁

@Siedlerchr Siedlerchr added component: ui good first issue An issue intended for project-newcomers. Varies in difficulty. labels Apr 5, 2022
@LIM0000
Copy link
Contributor

LIM0000 commented May 6, 2022

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
Copy link
Member

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
Copy link
Member

calixtus commented May 6, 2022

Dunno... Maybe EntryEditorPreferences?

@LIM0000
Copy link
Contributor

LIM0000 commented May 7, 2022

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
Copy link
Member

ThiloteE commented May 7, 2022

@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
Copy link
Member

@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
Copy link
Member

koppor commented May 31, 2022

@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
Copy link
Member

calixtus commented Jun 1, 2022

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

@koppor
Copy link
Member

koppor commented Jun 6, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ui good first issue An issue intended for project-newcomers. Varies in difficulty.
Projects
Archived in project
6 participants