#76 Entry editor : cancel and validate buttons

[fdar]

In the version 1.5 of JabRef, the "Close window" button
acts like a validate button. If I change a field and
then want to cancel, I have to validate the entry and
then undo the edition.

What do the other users (and the programmers...) think
about a "Cancel" button in the Entry editor?

[Morten Omholt Alver]

Logged In: YES
user_id=704995

Are you referring to the bibtex source editor? If not, note that when you
change multiple fields in the other tabs, the entry is updated for each field,
not only if you leave the entry or close the editor. This, in my opinion, would
make the effect of a Cancel button seem very ambiguos.

[fdar]

Logged In: YES
user_id=1098807

Sorry, my description was not accurate enough. In fact, I
was referring to all the changes I could make in the
different tabs of the Entry Editor, not just the BibTex
source tab.

In my mind, the cancel button will close the Editor and
discard the changes done in the entry. The validate button
will close the editor and save the changes done in the entry.

I think this idea came to my mind because it is not usual to
me to have to save the entry and to use undo when I just
want to cancel.

I am not sure this idea worth to be implemented, but I hope
you understand it now...

[Morten Omholt Alver]

Logged In: YES
user_id=704995

I understand. The problem is that the Cancel button is not very compatible with
the way the entry editor currently works. IMO, a Cancel button should always
cancel changes that have been specified, but *not* applied. The entry editor
applies changes immediately on a per-field basis. If a Cancel button reverts
these changes, it takes on Undo functionality, which is wrong from a usability
perspective.

For a Cancel button to have a logical function, we'd have to change the entry
editor so that changes are applied only batch-wise, e.g. with a Store or
Validate button. This is possible, and makes for simpler code than the current
scheme, but I am not convinced it is more practical for the user - especially if
it leads to an extra keystroke or button to click. We'd also need to prepare for
conflicts between edits in the source panel vs. the other ones, and this could
be tricky (say you edit the "year" to 2001 in Required fields, and to 2000 in the
source panel. We have no way of knowing which is correct, but with the
current scheme, the last change will always stand).

[Morten Omholt Alver]

Logged In: YES
user_id=704995

A further thought: the situation where you need to cancel what you are
currently writing, can maybe be improved using a Cancel button that only
cancels/reverts the current field? This would not cause any of the other
concerns I mentioned.

[fdar]

Logged In: YES
user_id=1098807

Thank you for the explanation. As a matter of fact, I did
not understand each field change was applied directly.

Since my feature request implies to much changes, may be you
should simply drop it.