Split tunneling support for flatpaks

[v4u6h4n]

Is your feature request related to a problem? Please describe.
Split tunnelling does not work with flatpaks.

Describe the solution you'd like
I want to be able to use split tunnelling with flatpaks.

Describe alternatives you've considered
N/A

Additional context
I just paid for my first month with Windscribe, because I want to switch to a VPN that provides static IPs, but the lack of flatpak support for split tunnelling is a considerable issue for me, and it is available in mullvad, which is what I was using before migrating to Windscribe.

[jaxu]

Split tunneling should already work for flatpaks with the following caveats:

• There must be a desktop file in $XDG_DATA_DIRS (Flatpak may put it in e.g. /var/lib/flatpak/exports, but we don't check in here). You can always copy it to ~/.local/share/applications and the app will see it.
• The Exec= line in the above will specify --command=X, that X must be the same as the actual binary being run. Firefox is for example notoriously bad at this: although --command=firefox, this is a shell script that will actually run firefox-bin. Since the name does not match, we don't split tunnel firefox-bin, and it would seem not to work. However, it works fine for e.g. chrome.

[v4u6h4n]

Hey, thanks for responding, and for the explanation of the issue.

So if I'm understanding correctly, the firefox flatpak isn't supported due to this binary issue? If that is the case, I'm requesting that support be added for firefox, or perhaps to be more specific support for those kind of binary edge cases.

If it weren't firefox that isn't supported, I would not be so picky about this, but it is one of the two major browsers on linux desktops, and browsers are ultimately one of the major types of applications that most users will want to be split tunnelling, so I think this would be a welcome feature for plenty of other users.

[jaxu]

I'll see what I can improve here, it's likely we can match against a flatpak app id instead of the binary name directly, which should improve this situation. I've put something on our board, but this will likely be in the 2.23.x timeframe.

[v4u6h4n]

Much appreciated :-)