Geany v2 file open dialog (Windows)

[Darklyter]

I just recently went to v2 from v1.36 (I believe), and I just realized that there's not an option any longer to allow filtering of files based on filename. So if you're in a directory with thousands of files, and misc filenames, you need to scroll through to find the correct file instead of just typing file in the box as was previously available. Is this expected or did I disable something in the switchover?

Also I just realized that there is a "bookmarks" section in the file open dialog. If it's been there I've just never noticed it since I have 25 drive/Windows links above it. Is it possible to move that bookmarks pane to the top of the list instead of hidden below the bottom of the window?

[b4n]

I just recently went to v2 from v1.36 (I believe), and I just realized that there's not an option any longer to allow filtering of files based on filename. So if you're in a directory with thousands of files, and misc filenames, you need to scroll through to find the correct file instead of just typing file in the box as was previously available. Is this expected or did I disable something in the switchover?

Not sure what the exact difference is between those versions from the to of my head, but you can still do that: if the entry isn't visible, just hit Ctrl+L.

Also I just realized that there is a "bookmarks" section in the file open dialog. If it's been there I've just never noticed it since I have 25 drive/Windows links above it. Is it possible to move that bookmarks pane to the top of the list instead of hidden below the bottom of the window?

I don't think so. It's the stock GTK file choose, so I might to know a detail about it, but I believe the order here is fixed.

[Darklyter]

Ctrl-L lets you type in a path, but it won't accept wildcards like *. So again, I was able to type *file* to show all files in the current path that contain "file" in the filename.

(sorry, didn't realize that my original message had formatted the wildcards out)

[b4n]

Ah, ok, wildcards, indeed I didn't see that. However, although I didn't know about the feature (thanks 🙂 ) it does work for me: if I type *file it shows me a list of suggestions matching that (and the wildcard acts as one). It's not a filter as it doesn't change what the directory listing shows, but it opens a dropdown of suggestions matching what I typed. I'm on Linux, but I assume it would be the same on Windows, yet I could be wrong and the Windows version doesn't support that, yet I'd be a tad surprised.

Anyway, maybe you were using the Windows native file chooser dialog? This was removed in 2.0, see #3219.

[Darklyter]

That's probably it. But with the new browser when I hit *, my system just goes "Bong" with an error sound

[b4n]

But with the new browser when I hit *, my system just goes "Bong" with an error sound

After using Ctrl+L? There are actually 2 ways to search/filer:

• Ctrl+L: location entry, e.g. you can type a file path, and it should provide completion
• Ctrl+F (or just typehead, e.g. start typing in the file list) : search recursively for file names in the current directory (using a substring search, e.g. can match any part of the filename)

In either case I don't know why you'd get a bong ¹, but maybe the search features suites you better?

Footnotes

1. again, I'm not very knowledgeable about Windows behavior, so if there are differences between Linux and Windows here (which is possible given it's interacting with the OS) I am likely to miss them. ↩

[Darklyter]

Ctrl-F works to do it, thank you! Btw, any other shortcuts that aren't listed apart from those two?

[b4n]

There are others, but I'm not aware of a proper documentation on this… quick search yields https://winaero.com/gtk-open-save-file-dialog-keyboard-shortcuts/ which isn't canonical but seems to list at least most of it.

[Darklyter]

Thank you!

[Darklyter]

Oh, as a follow up, apparently it's not possible to open up a network location without first mapping the drive in Windows. Typically you can just go to "\192.168.0.xxx\share" in the dialog, however not any longer. Also "smb://192.168.0.xxx" doesn't work with Ctrl-L (it will not accept the colon), and if you try to map it with "Connect to Server" in the File Open dialog won't allow it either. The hint text lists:

Server addresses are made up of a protocol prefix and an address.  Examples:
smb://gnome.org, ssh://192.168.0.1, ftp://[2001:db8::1]

And the list of "Available Protocols" and "Prefix"es is blank.

I'm sure there was a reason to remove the native file browser, but wow I really wish they hadn't done it.

[b4n]

Oh, as a follow up, apparently it's not possible to open up a network location without first mapping the drive in Windows. […] And the list of "Available Protocols" and "Prefix"es is blank.

It might be that there are extensions that are not packaged with Geany (like some GVFS handlers). If that's the case and the solution it identified, it could probably be distributed with Geany.

I'm sure there was a reason to remove the native file browser, but wow I really wish they hadn't done it.

The PR I linked mentions at least:

• bugs in the implementation leading to Geany crashing sometimes
• maintenance hassle (most Geany developers don't use Windows themselves, and as a consequence most hardly know the Windows-specific APIs for fixing weird bugs)
• optimistic guess that as other platforms are happy with the GTK dialog, Windows users would as well. Maybe that wasn't true though.

If you feel it's a large enough regression to warrant it, we could possibly try and provide a GtkFileChooserNative alternative implementation. It has some restrictions on what Geany can adjust in it, but would probably be easy enough to implement that we could maintain it on the longer run -- and it's likely less buggy than what we had, as well as supporting other platform's native dialogs as well.

[Darklyter]

Oh no, not a bit. Just because it's a pain for me doesn't mean that it's not perfectly fine for everyone else using the system. I went out after I wrote that and read through the PR, I saw where the dev mentioned the buggy and changed api for Windows calls.

If it's an easy add, it would be great. But if I'm the first person to bring it up since the release of v2.0 then I can't imagine it's that big of a problem to take any real time with it

[elextr]

Its probable that other users of file servers have them mounted (or whatever the Windows word is) so they access by something like //server/foo/file.blah.