Fixed by r16077 for GnuCash 2.1.2.  Thanks for the report!

I disagree that this is the right solution..  In particular it shouldn't do it at startup, and it DEFINITELY shouldn't do it automatically.  Think about the case where your datafile is mounted on an encrypted partition, or a network share, that requires manual intervention to mount.  If you start gnucash before you mount your filesystem it will just silently discard your datafile history.

If you can't be bothered to edit your history in gconf directly, I'd rather see an option to delete entries from the history.  a "File not found" is not sufficient cause to automatically remove it.

I've reopened this bug because I think the current fix is wrong.  I haven't, yet, reverted r16077 but I will if we don't get a better answer to this "problem".

Please see the thread on gnucash-devel:

  https://lists.gnucash.org/pipermail/gnucash-devel/2007-May/020562.html

Actually, r16077 did change more than requested and we probably agree now that the history list should not be changed on a typical startup, i.e. without a given file name, loading the last used file.

One open question, at least for me, is whether we really need yet another confirmation dialog whether history entries should be removed if the files cannot be loaded after the user has clicked their names in the File menu.

Maybe something akin to "clear private data" in Firefox.  Like a "clear remembered data" dialog box that lets you clear the settings for file history, 'always do this and don't ask again' settings, default preferences, etc.  Firefox's method is  nice, too, in that you can clear any or all of the data (selected with checkboxes) and you can cancel it if you change your mind...

I found this bug report by chance. In 2010 there was another bug report that in essence requested to drop the automatic history removal again altogether (Bug #628342), which I did in 2011.

The discussion in this bug (bug 388500) and the mailing list discussion referred to above, suggest three possible solutions, which I'll repeat here so they don't get lost:
- a context menu to selectively delete history entries from the menu
- a dialog similar to firefox' "clear private data"
- a checkbox in the error dialog box that when ticked will delete the menu entry

I'm not sure if it is even possible to define a context menu on top of a menu item. A quick search in the gtk documentation didn't reveal how to do this. Also, I don't remember a gnome application that does have a context menu for its menus. So I would not consider this a very intuitive or user friendly solution. It does give fine-grained control, but that's about the only advantage of this option. 

Regarding the "clear private data" option, I personally don't consider firefox a good model application to compare with here. Firefox deals with internet stuff and caches lots of information. It is not a productivity/office tool. So the needs are different there. Also, most GnuCash users are not interested in deleting the complete history, only those entries whose files have been removed. The "clear private data" option doesn't allow such fine-grained control.

I'm more interested in how other applications in that area deal with this. How does OpenOffice remove items from the "most recently used" (MRU) list ? How does gimp do it ? I haven't found a way in either application.

The last option seems to most elegant from a user perspective, though for technical reasons, I'd propose a slightly different setup: don't use a checkbox, but rather ask a question. If the file not found is in the MRU, present an error dialog that 
a. tells the file is not found (like now already) AND
b. inform the user that the file is still in the history list
c. ask if the file can be removed from there

If the user tried tried to open a file that has never existed (which can happen when starting gnucash from the command line with a wrong path), simply continue to display the file not found message only (as it always has been).

What do others think ?

Just tried a test with LibreOffice.  It warns about file "does not exist" but does not remove it from the recently used list.  I can't find any way to remove items either.

Okular (the linux pdf viewer) *does* silently remove a not found file from the list.  It also has a "clear list" item at the bottom of the list.

Created attachment 347750 [details] [review]
Patch to allow files to be removed from history list

Patch to allow if a file is opened from the history list and does not exist the dialog advises of this and asks if it should be removed from the list. If a file is opened from the command line and does not exist, the normal dialog is used.

Bob

Created attachment 347819 [details] [review]
Patch to allow files to be removed from history list

Slight change to patch.

Review of attachment 347819 [details] [review]:

Thanks for this patch Bob.

A few remarks.

The way the file_from_history boolean is handled bothers me a bit from a design point of view. I'd make it a parameter of gnc_file_open_file instead of tracking in in the history code because the code that really cares about this is in gnc-file.c (to generate a separate error message), but you have the history plugin manage that. This also makes the gnc_history_test_for_file a bit confusing. Looking strictly from the history plugin, why is a file in history only if file_from_history is true ? (I understand why, but I'm trying to convey why this is not the best design choice IMO). So I think this tracking would better happen in gnc-file, by tracking the file_from_history parameter in there and making the test for which error to display
if (file_from_history && gnc_history_test_for_file (displayname)).

That is, if you want to make a distinction between a file not found while opened from the command line or from history. What's the motivation to do so ? If the file is in history does it really matter whether the user actually specified it on the command line or it was retrieved from history ? If the real file isn't found and the name is still in history, I would think the user should be offered in both cases whether or not to keep the name in history. I imagine the case where the file name is in history but the user specified it on the command line also is less common. But for example a user may want to try and open a database directly from the command line, and only realize upon startup he had moved his databases to a new server.

Then a small code optimization (though not really important in this case, I just noticed it). In gnc_history_test_for_file you loop through all history entries and continue this loop even when a valid history entry is found. If you move the g_free up to right after the only line you use it on, you can add a break to the successful test. Saves a few cycles, though admittedly not much in the short history list. Just a programming habit.

Geert,

I think I got confused about the command line and the distinction is probably not required, will have a think but you are probably right which makes all of this much simpler.

I see you have added the patch all ready, do you want me to patch the current master or are you going to remove it ?

Bob

(In reply to Bob from comment #10)
> I see you have added the patch all ready, do you want me to patch the
> current master or are you going to remove it ?
> 
Oops, the patch unintentionally slipped through when I pushed my own work to master. As it's there now, you can just as well work directly on the current master to improve it.

Created attachment 348575 [details] [review]
Patch to allow files to be removed from history list

This patch should be applied to master on top of the previous patch to simplify it so it does not care where the file is opened from. If the file to be opened is in the history list and does not exist, the dialog advises of this and asks if it should be removed from the list other wise the dialog displays file not found.

Also modified the gnc_history_test_for_file with suggested optimisation.

When I first looked at this I did think of adding a parameter to file open but the number of places to change seemed quite large for it's use and then started with file_from_history in file.c but moved it. Any way with this simplified version it does not matter.  

Bob

Review of attachment 348575 [details] [review]:

Thanks for the update. Pushed to master.

Review of attachment 347819 [details] [review]:

Although I had asked for changes, I accidentally already had pushed this commit to master. So just marking it as such...

Bob, just one final nit for future patches: I don't know which tool you use to generate the patches. However is it possible to add a space between "Bug" and the bug number in the patch title ? With a space git bz recognized the patches as belonging to a certain bug, but without it it doesn't. Thanks!

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=388500. Please update any external references or bookmarks.