Feature: Show recently used projects in ProjectChooserButton dropdown

[jeremypw]

Fixes #1783

This avoids having to go through the FileChooser when re-opening recently used projects.

The (10) most recent projects are persisted in a setting and shown in the ProjectChooserButton listbox under a separate header. Closed projects are shown with the most recently used first. The filter works on both open and closed projects

At the moment it is assumed that the projects continue to exist. If it doesn't the menu remains open and no warning is given (except in the CLI)

[danirabbit]

Since Projects is going to be an XDG standard dir, why don't we just list all toplevel folders there instead of having a setting?

[jeremypw]

@danirabbit I created this to scratch my own itch tbh, which was to have quicker access to recently closed projects, analogous to the closed documents button on the document view. Just listing (toplevel) folders in "Projects" has these drawbacks

• Assumes the toplevel folders are projects. They could be category folders for e.g. Elementary projects, Gnome projects, Personal projects etc. They could include projects or categories related to a different application altogether.
• The number of projects/folders is open-ended
• It would take extra code to arrange them in order of how recently used (by Code) they are
• Pretty much the same functionality is already available provided the "Open Folder" button/shortcut is arranged to display the XDG Projects folder (or an override in settings for a Code projects folder)
• It imposes / assumes a workflow on the user

[jeremypw]

Another thing I realised is that we cannot pre-determine which folder opens when "Open Folder" when we use the NativeFileChooser portal anyway - I often find it is the folder I last opened not its parent because clicking on a folder does not choose it, it navigates to it in the chooser. Or it could be a completely different folder if the filechooser has been used by a different app. This makes it even more annoying to use the filechooser.

[jeremypw]

@danirabbit So are you happy for me to put more work into this? Any UX suggestions are welcome.

[danirabbit]

We do have an initial folder property in Gtk.FileDialog https://valadoc.org/gtk4/Gtk.FileDialog.initial_folder.html

I'm not opposed :)

[jeremypw]

Gtk.FileDialog appears to be an Object and it does not explicitly implement FileChooserNative interface. The functionality exists with FileChooserNative - it just doesn't work. In Gtk3 you can use Gtk.FileChooserDialog and then setting the initial folder does work - but the filechooser looks completely different (worse) and does not have the Files pathbar for example.

Anyway that issue can be revisited after the Gtk4 port.

[jeremypw]

I'll run this is my testing fork of Code for a while and see its as conventient as I think.

[danirabbit]

Gtk.FileDialog appears to be an Object

Right yeah because it's not a widget. It's an API call to the system file dialog. On elementary OS that's the file chooser portal, but it also uses native dialogs on macOS for example.

does not explicitly implement FileChooserNative

That's correct, FileChooserNative is deprecated. When an app is sandboxed, FileChooserNative shows the portal, but when it's not sandboxed it uses the Gtk.FileChooser widget. Gtk.FileDialog always uses an API call to the system whether it's sandboxed or not.

the filechooser looks completely different (worse) and does not have the Files pathbar for example

Yes because Gtk.FileChooserDialog uses the built-in GTK file chooser widget and does not use the FileChooser Portal

[jeremypw]

Looks like there is no advice against setting the initial folder when opening files/folders in the Gtk.FileDialog documentation so reason has prevailed (!)