Use MIME filters for file dialogs on non-Windows systems

[JGCarroll]

Tested on Ubuntu 20.04

Pinta currently sets the filter for files in the file chooser dialogs based entirely on filenames. Instead, it is preferable to base this filter based on MIME types. This means that on Linux systems for example, there is no need to specify a file extension to be recognised as an image file. The identification of the file is left to the system, which can use more advanced heuristics, primarily, identifying the type based on the files binary header / magic number.

The observed effect is is that when filtering for images, Pinta will be capable of identifying image files without a file extension, whilst excluding other types of files, e.g ODT documents, that would be found with "All Files" filter.

It isn't strictly necessary to remove the file extensions filtering, the filter object can take both file extension filters and also MIME type filters concurrently. However it seems the more technically correct solution to only rely on one or the other IMO. However, it might be the more pragmatic solution to actually use both.

[JGCarroll]

Having just tested this on Windows, this commit isn't ready in its original form.

The native file dialog doesn't work for the "open file" action (regression since 2.0.2), and the MIME filter doesn't work at all. At a minimum it might be necessary to include both forms of filter, but I'll have to do some further testing to see if the lack of native dialog is caused by this commit or an earlier commit.

[cameronwhite]

Thanks for looking at this!

I can also confirm that it causes the GTK dialog to be used instead of the native dialog on Windows - that seems to be intended / documented behaviour mentioned on https://docs.gtk.org/gtk3/class.FileChooserNative.html :(

On macOS the mime filter also doesn't work (produces an error like Pinta[56740:2068335] dyn.agq80w5pbq7ww8nu is not a valid allowedFileType because it doesn't conform to UTTypeItem in the console). But I think that's because it doesn't like the image/* pattern - something like image/jpeg seems to be okay. However, it didn't detect jpegs that had a missing extension so I think it's just filename-based

[JGCarroll]

The Windows part of this is giving me undue issues, I can't figure out if this is a result of an incorrect build environment or something else unrelated; but for the time being I'll push it back til I have some more free time.

If the Windows version can't use MIME's, and the Mac version can't use MIME wildcards, then it probably makes sense to use the original logic for those environments and only bother with MIME's on Linux (and maybe BSD?). These environments have the least to gain anyway, since this change is particularly aimed for reconsidering the XDG Desktop Portals and the file saving issues associated with extension-less files.

if (SystemManager.GetOperatingSystem() == OS.X11) {
    ff.AddMimeType("image/*");
}

The reason I haven't actually pushed that as a commit is because of the build issues mentioned earlier. It's a trivial code change so I presume you might be willing to try it yourself, but I've spent 2 hours today wondering why it isn't working on my end and can't get a good answer for that, weirdly...

[cameronwhite]

Yeah I think leaving the behaviour as-is on Windows would be fine 👍
One possible downside with the image/* pattern is that it might include image files that Pinta doesn't support (e.g. webp, unless webp-pixbuf-loader is installed on the system), so it could be less confusing if the filter only had the supported mime types
It looks like this can be queried through Gdk.PixbufFormat which can return the mime type(s) for each of its formats, so FormatDescriptor could be populated with a list of mime types along with the list of extensions

[JGCarroll]

The new commit looks fine for me on Windows/Linux. I imagine MacOS should work fine too; though I've no idea for BSD (or whether there's any recent packages for the BSD's)

[cameronwhite]

Looks good! Just a couple small notes

I think just disabling it for Windows is fine - I'd assume the native file dialog on BSD should be similar to the situation on Linux

[cameronwhite]

Looks good, thanks for working on this!