Support Application Uri in OpenUrl API call

[taooceros]

Fallback to direct process open when uri is not started with http/https

[JohnTheGr8]

Maybe add a different overload that accepts a Uri for such cases? Having the inPrivate parameter there when this might not run in browser is awkward.

[taooceros]

Maybe add a different overload that accepts a Uri for such cases? Having the inPrivate parameter there when this might not run in browser is awkward.

Hm if that's the case, I would doubt whether we should include a new public api because it is simply a helper function.

[JohnTheGr8]

Hm if that's the case, I would doubt whether we should include a new public api because it is simply a helper function.

nothing about this suggests that you can pass an application Uri and it will be started as a process:

Flow.Launcher/Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs

Lines 230 to 233 in b64dd27

	/// <summary>
	/// Opens the url. The browser and mode used is based on what's configured in Flow's default browser settings.
	/// </summary>
	public void OpenUrl(string url, bool? inPrivate = null);

[jjw24]

please update

[jjw24]

Hm if that's the case, I would doubt whether we should include a new public api because it is simply a helper function.

nothing about this suggests that you can pass an application Uri and it will be started as a process:

Flow.Launcher/Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs

Lines 230 to 233 in b64dd27

	/// <summary>
	/// Opens the url. The browser and mode used is based on what's configured in Flow's default browser settings.
	/// </summary>
	public void OpenUrl(string url, bool? inPrivate = null);

resolved.

[jjw24]

@taooceros i dont think the logic prior to my change is correct. Can you give me an App URI example you were testing with.

[jjw24]

@taooceros sorry, my mistake. This is now fixed in PR1002