GNOME Bugzilla – Bug 628342
Quick open on File menu deleted if failed
Last modified: 2018-06-29 22:43:53 UTC
After opening a connection it is remembered as a shortcut on the File menu. When opening this the next time and it fails this is removed (without asking). This behaviour is not helpful. If using a network connection or mysql connection and it fails in that moment it loses all the information despite the real connection being valid. It would either be useful to request if the user wants to lose this information, or to have a clear history in the settings. Simply removing it can be quite annoying where this might happen from time to time.
Agreed that the entries shouldn't be deleted just like that. I have fixed that in svn revisions r20540 (unstable) and r20542 (2.4 branch). I don't think it's worth adding a dialog to ask the user or a setting to clear the history for this. The history is only 10 entries long. Older entries get popped off this list when new entries are added. So if an entry is really obsolete, it will eventually disappear automatically.
However, this means if the file has indeed be intentionally removed, its entry will keep appearing in the file menu history even though it went away (potentially long ago). I saw some value in this rule to have it removed immediately.
I appreciate your view on this request. There is now indeed a new scenario where an intentionally deleted file will remain in the file menu history. But this wasn't the only case this happened. I can imagine several scenarios where a deleted file would remain in the history list: - Suppose you have two files, and always use double-click in the file manager to open them, instead of opening the application from the menu. The file you clicked will always be added/moved to the top of the history list. So if you delete one file in the file manager and then use double-click to open the other file, the deleted one will stay in the list. - Suppose you start experimenting with GnuCash in a test file. Once you are happy with it, you create a new file (or copy your test) to become a production file. You open the production file to be sure everything is as you like it. This file is now on top of the history list. Once you verified the file is good, you delete your test file via the file-manager (this file is mentioned secondly in the history list). If you now restart GnuCash, it will automatically open the production file, but never again touch the second entry in the history list, so this one will never be removed. Also I don't see any other application remove history entries that it doesn't find (tried with Gimp and OpenOffice). And finally I personally prefer to prevent unintentionally deleting an entry because it's temporarily available over automatically deleting an entry for a file that was deliberately removed. Now, having said all that I'm still open for improvements. Do you have a proposal to deal with this in a more elegant way ?
I agree there probably isn't an elegant solution that covers all cases you and we have discussed now. I agree your solution is probably the better choice for now, so let's stick to what you've committed now. Thanks!
See also bug 388500 which apparently was the reason why this feature was first implemented.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=628342. Please update any external references or bookmarks.