Use GtkFileChooserNative for opening files on Windows and macOS

[techee]

This is an experiment to use GtkFileChooserNative on Windows and macOS to address issues like

geany/geany-osx#14

where the GTK dialogs don't offer the best user experience.

I kept using GtkFileChooser on Linux because it adds extra widgets to the dialog like file encoding and filetype selection and these aren't supported when using native dialogs. To me at least this isn't the most important thing and using native dialogs under Windows and macOS is more important IMO.

This leads to a few ifdefs in the code but I'd say the result isn't too bad (GtkFileChooser is a GtkWidget while GtkFileChooserNative isn't so some things have to differ). Before continuing with the save dialog and project open dialog, my question is whether something like that would be acceptable for Geany - @b4n @eht16 what do you think?

@eht16 Do the native dialogs work correctly on Windows with this patch? It seems to work alright on macOS.

[eht16]

I'm curious though as I only use Linux, it won't change anything for me :D.
But I'll give it a try on Windows, this will take a few days though.

[elextr]

Somebody who has Windows 11 and can build Geany with this needs to test as well.

[elextr]

Also I presume the native dialogs are themed by the platform, not by GTK themes, so they may look totally different to the rest of Geany. @techee for Macos and whoever tests on Windows 11 need to try.

[eht16]

Somebody who has Windows 11 and can build Geany with this needs to test as well.

No need to build yourself, a full installer with the changes can be downloaded from the CI builds: https://github.com/geany/geany/actions/runs/8869590862 Windows 10/11 feedback would be great, I can only test on Windows 7 which is unsupported and not representative.

[rdipardo]

Windows 10/11 feedback would be great

So far so good on a stock Win 10 (22H2) VM with native dark mode active (i.e. AppsUseLightTheme == 0):^1.

Also I presume the native dialogs are themed by the platform, not by GTK themes

The screen capture and Registry values below confirm as much.

At least it's not launching the XP-era file dialogue that caused #3209

---

^1.

$ reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize" /se #

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize
    ColorPrevalence    REG_DWORD    0x0
    EnableTransparency    REG_DWORD    0x0
    AppsUseLightTheme    REG_DWORD    0x0
    SystemUsesLightTheme    REG_DWORD    0x0

[techee]

No need to build yourself, a full installer with the changes can be
downloaded from
the CI builds: https://github.com/geany/geany/actions/runs/8869590862

Nice, I didn't know about that.

The screenshot below comes from Windows 11, Geany on the left, Notepad++ on the right. The only difference I see is the file type selection that Notepad++ offers. I ifdef'ed that out in this patch thinking it wouldn't work but maybe it does - I'll try that.

[techee]

File filters work both on Windows and macOS:

[elextr]

@rdipardo @techee thanks for testing, so apart from the inconsistent theming issue it seems to work.

@techee you said in the OP "where the GTK dialogs don't offer the best user experience.". Can you expand on that and why " using native dialogs under Windows and macOS is more important IMO."?

[kugel-]

Didn't we have native dialogs a while ago, at least on Windows? So this brings that back, basically?

To me at least this isn't the most important thing and using native dialogs under Windows and macOS is more important IMO.

You hard-coded the native dialogs. As they don't offer all the features of our dialog (renaming a file, for example) you should be able to use the Geany dialogs. IMO a pref (like we had before) is required. I can also imagine not everyone likes an "alien" dialog in a GTK application (it's native to Windows but alien Geany).

[elextr]

Since I can't try either of the native dialogs, the reason I (politely) asked what the advantages of the native dialogs are is because as they are hard coded at compile time (AFAICT) users on Windows and Macos are gonna be stuck with them. So its important to know what the advantages are vs the disadvantages.

Edit: The old Windows native dialogs could be selected by preference IIRC.

[techee]

@techee you said in the OP "where the GTK dialogs don't offer the best user experience.". Can you expand on that and why " using native dialogs under Windows and macOS is more important IMO."?

It's pretty much this: geany/geany-osx#14 (comment). Basically the GTK keyboard shortcuts don't work on macOS and even if they worked, users don't know this because they are used to normal macOS behavior. Then it's the matter of favorite folders in the sidebar which one can normally define once and then they arte used in all the dialogs - that doesn't work with the GTK dialog. Finally, when using the native dialog, on macOS at least, the operating system automatically grants read/write "protected folder" file access without additional permission popup - this doesn't happen for GTK dialogs because they are "some foreign code" and the system doesn't know it was the user's explicit file selection.

[techee]

Didn't we have native dialogs a while ago, at least on Windows? So this brings that back, basically?

Yes, but I think the problem wasn't the dialogs themselves (apart from the fact they were some "old" open dialogs), but rather the fact they were implemented using Windows API that nobody understood well. The API of GtkFileChooserNative is pretty much like GtkFileChooser except it isn't a widget and you cannot put custom widgets inside it.

You hard-coded the native dialogs.

This isn't meant to be the final implementation - as said in the PR description, I asked whether using them would be acceptable in Geany and implemented it only for the open dialog for some testing. I don't want to spend much time on something that nobody likes so here I just wanted some initial feedback. Making this feature optional is surely an option but if it's done that way, I'd lean towards using the native dialogs by default.

As they don't offer all the features of our dialog (renaming a file, for example)

I didn't even know it was possible to rename a file using the Open dialog - how does one do that? I was talking about these options:

which are a custom widget inserted to the open dialog and which I personally have never used (I just tend to open the file and modify what's needed afterwards in Geany - especially with file encoding one cannot be sure before seeing how the file displays).

[techee]

I didn't even know it was possible to rename a file using the Open dialog - how does one do that?

OK, I guess you meant the Save as dialog where the Rename button is the added widget, which, indeed, won't be present in the native dialogs.

[elextr]

Yes, but I think the problem wasn't the dialogs themselves (apart from the fact they were some "old" open dialogs), but rather the fact they were implemented using Windows API that nobody understood well.

And #3209 crash.

But one thing positive they did was that they automounted remote servers IIRC, @techee @rdipardo do you have a configuration to check that on windows with the new native filechooser?

Like @Kugel, I didn't understand that this was WIP (label added) and would be selectable by the user in the final PR, not compiled in. In that case its less of a problem that there are functionality and theme differences, the user can choose. It will need to be explained properly in the manual why this happens with a section head that I can link to and close the issue when users complain 😈

[eht16]

The native file dialog on Windows 7 works very well after some testing.
Non-ASCII path and file names seem to work well, too.

I don't know how to set up "automounted remote servers", so can't test it.
But what the native dialog offers is access to network drives, I tested it with a file on a network drive added via the RDP client (I think this uses SMB under the hood) and this works fine while the GTK dialog does not see those drives.

To me it seems fine to use those dialogs since it seems to work well and if it goes the same for "Save As" and maybe "Open Folder". Making it configurable is a good idea, I don't mind about the default.
Most of the infrastructure for the setting we already had (see #3219 and #3791) which could be revived.

[techee]

To me it seems fine to use those dialogs since it seems to work well and if it goes the same for "Save As" and maybe "Open Folder". Making it configurable is a good idea, I don't mind about the default.

Good to hear. I'll try to prepare the patches (after finishing the boring task of writing documentation for the lsp plugin, sigh).

Maybe one more question - should the open dialog show hidden files by default? This is configurable using the custom widget on GTK but we won't be able to add it so we should decide either to show hidden files or not. On macOS hidden files can be shown using some keyboard shortcut for the dialog so it wouldn't be completely necessary to always show hidden files, I'm not sure if it's possible on Windows too though (on the other hand Windows hidden files aren't so important I think because it's not those beginning with . like .gitignore that typical developer needs to edit).

[b4n]

If there's an option for it, sure (I didn't understand that was something you would be happy about). And I don't mind the default on non-Linux either, whatever people like best on those platforms.
It would be nice to have this available on Linux as well (but off by default) for the sandboxing caps -- although I'm not really sure whether "sandboxing" an editor/IDE really makes much sense, but well, it has been mentioned quite a few times.

File filters work both on Windows and macOS

That's nice. And indeed, the documentation lead me to think it wouldn't work with out patterns, but custom filters are actually something else.

[eht16]

Maybe one more question - should the open dialog show hidden files by default? [...]
I'm not sure if it's possible on Windows too though (on the other hand Windows hidden files aren't so important I think because it's not those beginning with . like .gitignore that typical developer needs to edit).

I don't think it's necessary because as you said, hidden files on Windows are usually less relevant and have stronger means than on Linux.
The dialog in the current configuration shows files like .gitignore and this is good, I think.

[techee]

Alright, I made the suggested changes:

1. I made GtkFileChooserNative configurable, by default enabled on macOS and Windows, disabled on Linux.
2. I went through all GtkFileChooser occurrences in Geany and added the native variant
3. Not sure if intentional or if it's some left-over but ui_utils.c still contains native win32 dialogs:

   geany/src/ui_utils.c

   Line 2012 in 11b4a00

   utf8_path = win32_show_folder_dialog(ui_widgets.prefs_dialog, title, path);

   I replaced those with GtkFileChooserNative and eliminated the native code in win32.c.
4. For now I didn't modify plugins which also contain some GtkFileChooser code but I could do the same for them too if desired.

[eht16]

Alright, I made the suggested changes:

1. I made GtkFileChooserNative configurable, by default enabled on macOS and Windows, disabled on Linux.

Sweet, works perfectly.

3. Not sure if intentional or if it's some left-over but `ui_utils.c` still contains native win32 dialogs: https://github.com/geany/geany/blob/11b4a00a3020b1c9ace3d3ae65aa5ec7d5ff84e0/src/ui_utils.c#L2012
    I replaced those with GtkFileChooserNative and eliminated the native code in win32.c.

I guess it's some sort of left-over because it wasn't as buggy as the full file dialogs and so they were out of my focus.
Thanks for cleaning up my dirt :D.

4. For now I didn't modify plugins which also contain some GtkFileChooser code but I could do the same for them too if desired.

I think this improve the overall user experience. Though maybe this can be done later as well and maybe also by the respective plugin maintainers (at least for those plugins which still have an active maintainer).

[techee]

I guess it's some sort of left-over because it wasn't as buggy as the full file dialogs and so they were out of my focus.
Thanks for cleaning up my dirt :D.

By the way, there's also native message dialog on Windows (win32_message_dialog()) called at several places inside dialog.c (hard-coded, not configurable) - is this one useful for something? Unlike open file dialogs, this is just a simple popup and doesn't bring any benefits and could be removed too IMO (it could actually be quite distracting if someone uses dark Windows theme and Geany is in light theme and the dark popup appears).

I think this improve the overall user experience. Though maybe this can be done later as well and maybe also by the respective plugin maintainers (at least for those plugins which still have an active maintainer).

I meant the built in plugins here - notably saveactions and export use GtkFileChooser now. I can update those to use native dialogs too. For geany-plugins it's up to the plugin maintainers I think.