Recent files menu doesn't seem to be working on Windows

In the 2.0 release, the Recent files menu always comes up empty on Windows for me, no matter how I open patches there (i.e., via File/Open or double-clicking a file).

This works perfectly on both Linux and Mac, so I suspect there's something going awry with the "add-recent-file" FUDI message on Windows.

On Windows with file "blah blee.pd":

<- pd add-recent-file C:\Users\SOME_USER\Desktop\blah\ blee.pd;
-> gui_recent_files "x12345678", []

On Windows with file "blah.pd":

<- pd add-recent-file C:\Users\SOME_USER\Desktop\blah.pd;
-> gui_recent_files "x12345678", []

As you can see there is also an ambiguity between escaped spaces and directory separators. But the second examples shows this isn't the source of the bug.

Just curious-- why is there a separate GUI->Pd call for adding a recent file? Can't that just happen from within Pd as a side effect of opening a file from the menu?

why is there a separate GUI->Pd call for adding a recent file?

Recent files occur in a number of different situations (not just opening, but also saving files), and I didn't want to add the bookkeeping to the binbuf reading and writing routines which might potentially be called from just about anywhere. So it seemed most appropriate to do this separately.

Anyway, quite obviously the root cause of this issue is the funky pathname encoding on Windows, so I'll have to see whether I can convert these on the fly or maybe use a dialog-safe encoding or something like that.

Looking at the FUDI communication and the code, it's quite obvious that the existence check in sys_add_recent_file() is the culprit. I'm using enquote() on the JS side there, which seems to work fine with the open and savetofile FUDI messages, but obviously doesn't with check_exists() (whose definition I just copied verbatim from g_canvas.c).

Looking at the other uses of check_exists() in g_canvas.c, it's only invoked on standard Unix pathnames there, in which case the forward slashes are converted to backslashes on the fly, so it might well be thrown off if I just pass it a proper Windows pathname instead. I don't understand why it would do that, though. Unless check_exists() is just broken anyway on Windows, that is.

About the whitespace thing: Yeah, there's an ambiguity there, but that's just FUDI and its amateur escape syntax. I hope that the other "real" backslashes in the filename do get through, don't they?

Ok, found a solution, just defunkifying the add-recent-file pathnames on the JS side before passing them to enquote() gets rid of this. Expect a merge request soon.

mentioned in merge request !75 (merged)

closed via commit ae0617c0

closed via merge request !75 (merged)