I agree we need this function. This is good idea.

There are official APIs for opening a URL on Mac, iOS, Android, and Windows. I don't know about Linux except for the command line xdg-open.

Mac
NSURL the_url =  [NSURL URLWithString:@"http://www.apple.com"];
[[NSWorkspace sharedWorkspace] openURL:the_url];

iOS
NSURL the_url =  [NSURL URLWithString:@"http://www.apple.com"];
[[UIApplication sharedApplication] openURL:the_url];

Windows:
LONG r = ShellExecute(NULL, "open", "http://www.microsoft.com", NULL, NULL, SW_SHOWNORMAL);
(maybe that should be ShellExecuteA)


I forgot the details of Android, but you use Intents.
http://stackoverflow.com/questions/3004515/android-sending-an-intent-to-browser-to-open-specific-url
String url = "http://www.example.com";
Intent i = new Intent(Intent.ACTION_VIEW);
i.setData(Uri.parse(url));
startActivity(i);

Now please don't limit URLs to just http://. It is very common on Mac, iOS, and Android to use custom URLs to launch specific apps. Sometimes they are for popular protocols so people spontaneously conform their apps to URL schemes that get documented so their apps can handle them too, say like twitter:// (The OS may have an arbitration system if multiple apps handle the same URL scheme.)
http://wiki.akosma.com/IPhone_URL_Schemes


Particularly in mobile games, I've seen a lot of developers cross-promote their apps, where one app can launch another and maybe you win points or something for doing so.

The Mac and iOS code will just work for that case. I think Windows may work too. Android is a little more involved if I remember and you may have to add more cases, but I've totally forgotten the details of how it works.



Also, there is a counterpart system to this. It is also handy to know when you've been launched via OpenURL. And you need to be able to parse the URL string for information that was passed. For example, most text editors on the Mac respond to URL schemes (even MacVim) and you can tell it to open a specific file at a specific line number. Or in the cross-promotional example above, you want to know which app launched you. The receiving app needs a notification that OpenURL was invoked with a particular string. Also, keep in mind that the app may or may not have been already running when this even happened.

Created attachment 2021 [details]
patch SDL_OpenURL : Android + Unix

Here's a first version of "SDL_OpenURL" function for Android and Unix.

It works with URLs, and probably with directories and files.

It would be nice if someone could add MacOSX, IOS, Windows, etc.

Created attachment 2022 [details]
patch SDL_OpenURL : Android + Unix (v2)

Update the patch so that it uses "execl()", instead of "system()", to run "xdg-open url". The argument is then protected.

Not sure if it solves the problem mentioned by Gerry JJ of browser blocking/not_blocking.

Created attachment 2025 [details]
patch SDL_OpenURL : Android + Unix + MacOSX + IOS (v3)

Add MacOSX, IOS part 
Changed "fork" to "vfork"
Changed "exit" to "_exit"

Notice that IOS part is in "src/power" because there is no "filesystem" directory. I would have needed to modify the xcode project to have one.

Created attachment 2027 [details]
patch SDL_OpenURL : Android + Unix + MacOSX + IOS + double-forking (v4)

As suggested, I have updated the patch to fork twice so the application cannot be blocked.

Notice that the return code does not say anything about the success/failure of xdg-open, but now, is about the success/failure of the launcher of xdg-open.


I have used "vfork()" since it is said to be more efficient for this very case.

Created attachment 2032 [details]
patch SDL_OpenURL : Android + Unix + MacOSX + IOS + double-forking (v5)

Update fork/vfork : use first fork(), then vfork().
Instead of "execl", use "execlp".

I think one fork() is enough. Calling setsid() before execlp() should fix the zombie-problems (if not, try a pumpgun).

ok, nevermind, setsid() doesn't seem to work like I thought it does. so probably double-fork is the way to go, even though it seems hacky to me

There was a detailled discussion on the mailing-list about the double-fork issue and SDL_OpenURL.
And this solution was adviced.

Indeed, the code is not really readable and a cleaner solution would be better. 

I don't really know about "setsid()", but post to the mailing, I sure you'll get positive feedback about it.

Created attachment 2207 [details]
patch SDL_OpenURL : Windows platform

It works with URLs,directories,files and executable.
I have tested it with windowed as well as full screen mode.

In case of full screen mode, SDL window will be minimized and browser(default) will be launched. Later on SDL window can be restored to previous state(full screen) by (ALT+TAB) or clicking the SDL app from task bar

I have tried the patch for windows on windows 10.

The patch looks correct according to documentation but it doesn't work on my side!

On Windows 10 / x64 : it fails with error code 31 which means that "open" action and "url" are not registered together. But they are, in the register.

On Windows 10 / arm (mobile) : it compiles but app fails to start because of missing .dll ... (it should be included automatically I think).

On windows 10, a way to open a link is:

auto uri = ref new Windows::Foundation::Uri("http://www.libsdl.org");
Windows::System::Launcher::LaunchUriAsync(uri);

For Android, added: 
int SDL_AndroidOpenURL(const char *url);
( https://hg.libsdl.org/SDL/rev/0c20003a6df7 )

let's close it since Ryan add all the back-end !

https://hg.libsdl.org/SDL/rev/7d7a72e4f9b6 and following commits .