Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to use portals, and fall back on GTK #112

Open
iTrooz opened this issue Nov 16, 2023 · 3 comments
Open

Try to use portals, and fall back on GTK #112

iTrooz opened this issue Nov 16, 2023 · 3 comments

Comments

@iTrooz
Copy link
Contributor

iTrooz commented Nov 16, 2023

Hey !

Portals can be quite difficult to setup for users, which make it difficult for us to use it, but the native feeling is great for those who want it

Would it be possible to add a "build option" (or idk) to compile both portals and GTK implementations, and first try to use portals, and fallback on GTK popups ?

I'd be ready to help with that
Thanks !

@btzy
Copy link
Owner

btzy commented Nov 17, 2023

Just to be sure I'm understanding you correctly, you want to have a check at runtime to decide whether to open a Portal or GTK dialog?

@iTrooz
Copy link
Contributor Author

iTrooz commented Nov 17, 2023

Yes. Sorry, re-reading myself, I realize that this was pretty badly written

The functions could be implemented on your side with something like this:
(pseudocode, I know your API isn't exactly like that)

nfdresult_t NFD::openFile(NFD::UniquePathU8 outPath) {
	result = NFD::Portal::openFile(outPath)
	if (result == NFD_ERROR) {
		return NFD::GTK::openFile(outPath)
	} else return result;
}

But It'd also be fine for me if NFD::Portal::openFile() and NFD::GTK::openFile() were simply exposed to us, and we had the responsibility to implement the fallback (right now we have to choose between them at compile time with NFD_PORTAL)

@btzy
Copy link
Owner

btzy commented Nov 17, 2023

Thanks for the clarification.

It's a nice feature to have, and I'd be happy to accept a PR for such a feature (as long as it is possible at build time to select just a single implementation).

There's a different but related question, about whether it should be a hard loader error if the loader cannot find libdbus or libgtk at runtime. Your current proposal will be a hard error at load time, which I'm not sure is ideal. Preventing a hard loader error is usually achieved using dlopen() (as mentioned in mlabbe/nativefiledialog#42 and mlabbe/nativefiledialog#102), but it can probably be done more nicely on Linux by importing the functions from shared libraries as weak symbols (with #pragma weak or some attribute). This will allow you to run your binary even if one of libdbus or libgtk is missing. I'm not too sure whether such a distribution exists in practice though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants