https://bugs.kde.org/show_bug.cgi?id=437933
pa...@web.de changed:
What|Removed |Added
Status|NEEDSINFO |REPORTED
Resolution|WAITINGFORINFO |---
--- Comment #3 from pa...@web.de ---
(In reply to Stephane MANKOWSKI from comment #1)
> Hi,
>
> Just some questions to well understand your scenario and propose the better
> solution.
>
> In step 3, why did you click on another operation ? What is your intention ?
>
> If you want do modify this operation, this is normal to update the form with
> the new selection.
Yes, correct, step 3 is an error on my side. Typically in this situation I was
sidetracked by some other issue and forget, but sometimes it's just that the
click did not work for whatever reason (window wasn't active, cursor didn't
match button position, clicking was not recognized, ...)
I think it's pretty much the same as when you write a text in a text editor and
(most often accidentally) click on close before saving. Then it's usual to have
the text editor let the user confirm, that their text (modified state) would be
deleted by presenting some options to go forward. I think it's always the same
pattern with unsaved modified state, be it an HTML form or in a configuration
dialog.
Similarly when modifying an entry and forgetting to either create a new entry
or overwrite the existing on, the user would again lose modified state and
therefore Skrooge should be presenting some options to go forward (ideally
disactivable for the future).
I think this makes sense from a user friendliness point of view and would have
saved some frustration on my side (like an e-mail you have to rewrite because
it gone lost somehow during editing – it's not the sheer amount of additional
work which is frustrating, but doing the very same thing again).
--
You are receiving this mail because:
You are watching all bug changes.
