Source tab entry duplication

[lenhard]

Adapts the source tab a little better to the new and no longer re-created entry editor. It is a fix for the problem described in this comment #3352 (comment) The remaining problems in the issue are not addressed here, so the issue should stay open when merging this and the update flow in the source tab should be reworked in further PRs.

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)
• If you changed the localization: Did you run gradle localizationUpdate?

[halirutan]

To give some feedback and to spare you unnecessary work. I had already rewritten this yesterday and I'm sorry for not saying that I look over this. When I saw that you started this too, I fetched your branch and my initial idea was, just to provide the functionality to make Ctrl+S work.

However, I believe the information flow for the EntryEditor is extremely confusing so I ended up rewriting this completely. The main idea is to make the EntryEditorimplement EntryEditorInfo that provides access for each tab. Therefore, we don't pass entries, entry-types, contexts, etc. between the editor and its tabs, instead, each tab accesses the information when it needs it. This let me through out all the methods that pass things and the tabs are only notified when they get focus or when a new entry is set by the EntryEditor. This makes things much more localized and easier to follow.

I would like to push this on a new branch and test it carefully. It will include the changes you made here. The issue with Ctrl+S can be resolved by putting this in the setupKeyBindings() for the EntryEditor where we act on (but don't consume) that save/saveAll events:

switch (keyBinding.get()) {             
    case CUT:                           
    case COPY:                          
    case PASTE:                         
    case CLOSE_ENTRY_EDITOR:            
    case DELETE_ENTRY:                  
    case SELECT_ALL:                    
    case ENTRY_EDITOR_NEXT_PANEL:       
    case ENTRY_EDITOR_NEXT_PANEL_2:     
    case ENTRY_EDITOR_PREVIOUS_PANEL:   
    case ENTRY_EDITOR_PREVIOUS_PANEL_2: 
        e.consume();                    
        break;                          
    case SAVE_ALL:                      
    case SAVE_DATABASE:                 
    case SAVE_DATABASE_AS:              
        sourceTab.saveCurrentSource();  
        break;                          
    default:                            
        //do nothing                    
}                                       

The things I tested worked but there is one complicated situation: User edited the bibtex source and made a syntax error in it. Then he clicks on a different entry in the main table. Besides that the current "let me edit my wrong code" does not work as it stands (exception is not caught), there is a deeper problem: The main table is already on a different entry and the EntryEditor has already fetched the new entry. To make a successful revert&edit we need to tell the main table to jump back to the erroneous entry and set it in EntryEditor.

@lenhard Shall I put my changes on a different branch? In this way we have a quick fix with your PR and can test things carefully.

[lenhard]

@halirutan Thanks for your input! What you write sounds reasonable and I agree that the information flow in the entry editor is crying for a larger refactoring.

I have just pushed a fix to repair the build here and when it has passed we could merge this already. You can do your changes on a different branch, then. And we can give it a thorough look and testing.

Just be aware that even more problems apart from syntax error correction might come up. The tabs are not only dependent on the entry editor, but also partly dependent on each other. E.g. if a field value changes in the source tab, it should be changed in another tab as well and vice versa (not so hard) and if I add a new optional field in the source tab, it should make the optional tab make appear (somewhat harder).

[halirutan]

The problem here is btw that you run it in a separate thread. This means, the moment storeSource starts to work, a new entry is already set and what you do is to overwrite the correct new entry with itself.

[halirutan]

@lenhard

if I add a new optional field in the source tab, it should make the optional tab make appear (somewhat harder).

yes, even this works already.

[lenhard]

Perfect! Then I'll merge this directly so that we have a quick fix to the issue and you can go ahead with your larger refactoring.