[SDL] SDL_OpenURL proposal

[Alexey Petruchik]

Hi, I'm currently porting qfusion engine to SDL2. It has it's own kinda-sdl
- a bunch of C functions with platform specific implementations. Most of
them are easily replaced by sdl analogues. But there is one function that
does not have analogue - Sys_OpenURLInBrowser. What do you think about
adding such function to SDL?

Regards, Alexey.

[Alex Barry]

Why not a third-party lib, SDL_OpenURL? It would easily be recognizable as
an SDL utility lib, and could even be promoted on the website.

I just don't see the vast majority of SDL applications using an open url
function, but maybe I'm wrong.

-Alex

On Thu, Oct 30, 2014 at 12:02 PM, Alexey Petruchik <

Post by Alexey Petruchik
Hi, I'm currently porting qfusion engine to SDL2. It has it's own
kinda-sdl - a bunch of C functions with platform specific implementations.
Most of them are easily replaced by sdl analogues. But there is one
function that does not have analogue - Sys_OpenURLInBrowser. What do you
think about adding such function to SDL?
Regards, Alexey.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Daniel Gibson]

One needs this every now and then (games linking to websites ingame
aren't that uncommon), so it makes sense to me.
I'm not even sure if this needs to be URL-specific or if it could be
something that can also open files, like xdg-open on Linux (OSX also has
something similar).

Cheers,
Daniel

Post by Alexey Petruchik
Hi, I'm currently porting qfusion engine to SDL2. It has it's own
kinda-sdl - a bunch of C functions with platform specific
implementations. Most of them are easily replaced by sdl analogues. But
there is one function that does not have analogue
- Sys_OpenURLInBrowser. What do you think about adding such function to SDL?
Regards, Alexey.

[Dmitry Rekman]

Just to chime in with more support: a function to open URLs (or README
files for that matter) is IMHO basic enough to warrant including in the
base library.

Regards,
Dmitry

One needs this every now and then (games linking to websites ingame aren't
that uncommon), so it makes sense to me.
I'm not even sure if this needs to be URL-specific or if it could be
something that can also open files, like xdg-open on Linux (OSX also has
something similar).
Cheers,
Daniel
Hi, I'm currently porting qfusion engine to SDL2. It has it's own

Post by Alexey Petruchik
kinda-sdl - a bunch of C functions with platform specific
implementations. Most of them are easily replaced by sdl analogues. But
there is one function that does not have analogue
- Sys_OpenURLInBrowser. What do you think about adding such function to SDL?
Regards, Alexey.

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Sik the hedgehog]

I think the problem here is that SDL doesn't have any networking
functionality whatsoever. So far if you wanted networking you used
SDL_net instead (was that one updated for SDL2? I never used the
satellite libraries so I don't really know their situation)

[Alex Szpakowski]

Opening URLs/URIs in the system’s designated program for that URI scheme doesn’t really have to do with networking (directly, at least.)

Here’s the code we use in the LÖVE game framework to do that: https://bitbucket.org/rude/love/src/tip/src/modules/system/System.cpp?at=default

It works fine for filepaths too, if you prefix the filepath argument with “file://“.

Post by Sik the hedgehog
I think the problem here is that SDL doesn't have any networking
functionality whatsoever. So far if you wanted networking you used
SDL_net instead (was that one updated for SDL2? I never used the
satellite libraries so I don't really know their situation)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Leon Moctezuma]

I like the idea, a lot of games send you to open a browser, a similirar
function for calling webservices would be very helpful

Opening URLs/URIs in the system’s designated program for that URI scheme
doesn’t really have to do with networking (directly, at least.)
https://bitbucket.org/rude/love/src/tip/src/modules/system/System.cpp?at=default
It works fine for filepaths too, if you prefix the filepath argument with “
file://“.
I think the problem here is that SDL doesn't have any networking
functionality whatsoever. So far if you wanted networking you used
SDL_net instead (was that one updated for SDL2? I never used the
satellite libraries so I don't really know their situation)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alexey Petruchik]

Btw LÖVE code is very similar to what I have here in qfusion. So I think it
can be used as a reference.

Post by Leon Moctezuma
I like the idea, a lot of games send you to open a browser, a similirar
function for calling webservices would be very helpful
Opening URLs/URIs in the system’s designated program for that URI scheme

doesn’t really have to do with networking (directly, at least.)
https://bitbucket.org/rude/love/src/tip/src/modules/system/System.cpp?at=default
It works fine for filepaths too, if you prefix the filepath argument with
“file://“.
I think the problem here is that SDL doesn't have any networking
functionality whatsoever. So far if you wanted networking you used
SDL_net instead (was that one updated for SDL2? I never used the
satellite libraries so I don't really know their situation)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Jeffrey Carpenter]

Heyya,

Out of curiosity, does Windows have anything similar to OS X 'open' or Linux xdg-open? It reminds me of a quick batch script I wrote -- 'open.bat' -- for my Windows system that provides a similar experience to those tools when using it to open up the GUI file manager pointing to a particular dir, i.e.: "open .".

Cheers,
Jeffrey Carpenter
<***@gmail.com>

[Joël Thieffry]

Post by Jeffrey Carpenter
Heyya,
Out of curiosity, does Windows have anything similar to OS X 'open' or Linux xdg-open? It reminds me of a quick batch script I wrote -- 'open.bat' -- for my Windows system that provides a similar experience to those tools when using it to open up the GUI file manager pointing to a particular dir, i.e.: "open .".

Yes, it is the "start" command.

Post by Jeffrey Carpenter
Cheers,
Jeffrey Carpenter
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Daniel Gibson]

Couldn't it minimize the game?
At least that's what I as both a player and developer would expect to
happen.

Cheers,
Daniel

I think the main reason this functionality hasn't been added is because
it doesn't work with fullscreen games.

Post by Jeffrey Carpenter
Heyya,
Out of curiosity, does Windows have anything similar to OS X 'open' or Linux xdg-open? It reminds me of a quick batch script I wrote -- 'open.bat' -- for my Windows system that provides a similar experience to those tools when using it to open up the GUI file manager pointing to a particular dir, i.e.: "open .".

Yes, it is the "start" command.

Post by Jeffrey Carpenter
Cheers,
Jeffrey Carpenter
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Sik the hedgehog]

I think the main reason this functionality hasn't been added is because it
doesn't work with fullscreen games.

How many games even do it?

Also huh now I see what's the deal, people want to open a program, not
to load data from an URL (this also means the suggested name is
wrong). Well, that's a whole different issue then. I don't think that
fullscreen is much of an issue (the current window will lose focus,
thereby behaving as usual), the fact that sandboxed platforms don't
allow is a much bigger barrier in my opinion.

PS: to anybody wanting to just call system(), remember that on Windows
that only works with ASCII strings and you'll need _wsystem() if you
want non-ASCII characters (including conversion to UTF-16, ugh - and
no, it's not UCS-2, Windows XP introduced surrogate support).

[Jeffrey Carpenter]

This post might be inappropriate. Click to display it.

[Jonas Kulla]

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not
necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start
shuddering in horror at the whole idea. From a UX stand point, (especially)
when my game is full screen, the **last** thing I want to see happen is to
lose focus of the game window -- this completely ruins the experience of
immersion. I'd much prefer copy and paste of the URL to open a web browser
or what not explicitly. I cannot think of any use case off the top of my
head where I find the lose of focus appropriate, other than (of course)
OS-level events. In other words, I strongly prefer being in control of
explicit focus changes of my game.
I see the counter argument being made where **not** having the game
auto-minimize or what not and open the program automatically could be seen
as less user-friendly here. I'd love to hear your own opinion regarding
this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so (minimize
/ lose focus of the game to do another task), perhaps because the
underlying platform is fundamentally different, and/or I don't have 15+
years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of UX
issues -- hopefully without inciting a flame war! :-)

You haven't really named a single reason why this function shouldn't be
implemented in SDL,
you only elaborated on why you personally wouldn't use such a function.

[Jeffrey Carpenter]

<nods> What I meant by "...do not necessarily justify anything" in my opening statement was that my comments were not intended whatsoever for justifying whether or not this feature should be implemented. (I realize that my comments are a matter of taste / preference and certainly should not be used to dismiss the proposal).

My true intentions were really to see how other people feel about UX issues associated with this sort of feature, and is arguably somewhat off-topic! :-)

Cheers,
Jeffrey Carpenter

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start shuddering in horror at the whole idea. From a UX stand point, (especially) when my game is full screen, the **last** thing I want to see happen is to lose focus of the game window -- this completely ruins the experience of immersion. I'd much prefer copy and paste of the URL to open a web browser or what not explicitly. I cannot think of any use case off the top of my head where I find the lose of focus appropriate, other than (of course) OS-level events. In other words, I strongly prefer being in control of explicit focus changes of my game.
I see the counter argument being made where **not** having the game auto-minimize or what not and open the program automatically could be seen as less user-friendly here. I'd love to hear your own opinion regarding this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so (minimize / lose focus of the game to do another task), perhaps because the underlying platform is fundamentally different, and/or I don't have 15+ years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of UX issues -- hopefully without inciting a flame war! :-)
You haven't really named a single reason why this function shouldn't be implemented in SDL,
you only elaborated on why you personally wouldn't use such a function.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Jorge Rodriguez]

Sdl is a library of tools that abstract os specific details, not a library
of UX design tools. It should provide easy to access functionality and let
the developer decide how to assemble them. I agree that opening a window
from inside a full screen desktop game is awful but it's up to the
developer to avoid that situation and up to the user not to use
applications that exhibit that behavior.

Post by Jeffrey Carpenter
<nods> What I meant by "...do not necessarily justify anything" in my
opening statement was that my comments were not intended whatsoever for
justifying whether or not this feature should be implemented. (I realize
that my comments are a matter of taste / preference and certainly should
not be used to dismiss the proposal).
My true intentions were really to see how other people feel about UX
issues associated with this sort of feature, and is arguably somewhat
off-topic! :-)
Cheers,
Jeffrey Carpenter

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not

necessarily justify anything. And so with that out of the way...

Post by Jeffrey Carpenter
As soon as I reading things like "..minimizing the game", I start

shuddering in horror at the whole idea. From a UX stand point, (especially)
when my game is full screen, the **last** thing I want to see happen is to
lose focus of the game window -- this completely ruins the experience of
immersion. I'd much prefer copy and paste of the URL to open a web browser
or what not explicitly. I cannot think of any use case off the top of my
head where I find the lose of focus appropriate, other than (of course)
OS-level events. In other words, I strongly prefer being in control of
explicit focus changes of my game.

Post by Jeffrey Carpenter
I see the counter argument being made where **not** having the game

auto-minimize or what not and open the program automatically could be seen
as less user-friendly here. I'd love to hear your own opinion regarding
this? (Am I the only one that feels strongly about auto-focus lose?)

Post by Jeffrey Carpenter
I do, however, feel that it is OK for a mobile platform to do so

(minimize / lose focus of the game to do another task), perhaps because the
underlying platform is fundamentally different, and/or I don't have 15+
years of habits formed using the platform?

Post by Jeffrey Carpenter
In short, I'd love to hear about your feelings regarding these sorts of

UX issues -- hopefully without inciting a flame war! :-)

Post by Jeffrey Carpenter
You haven't really named a single reason why this function shouldn't be

implemented in SDL,

Post by Jeffrey Carpenter
you only elaborated on why you personally wouldn't use such a function.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Luke Groeninger]

I tend to agree that directing a user to a website is a fairly specific high level task that is probably best left up to the application developer to decide how they want to handle it. Not only would it be terrible UX to kick the user outside of an application, but given things like Steam and Origin have overlays specifically designed to display webpages without the application losing focus, it’s a lot more complicated than simply throwing a URL at an OS call. It is far better to simply not try to tackle that problem inside SDL than it is to implement a half assed solution for SDL.

THAT SAID. The idea of having an API that calls out to start/open/xdg-open/whatever is not actually a bad one. It would fall in line with functions like SDL_strncmp and SDL_malloc as a wrapper for common operating system functionality, and ultimately would leave it up to the developer as to what URI they pass to the system and up to the operating system what would happen with it.

But, that’s not SDL_OpenURL - that’s SDL_open or SDL_launch or similar. Implementing a wrapper for a common OS call is a very different story than trying to cram a high level task into a low level library.

-Luke

Post by Jeffrey Carpenter
<nods> What I meant by "...do not necessarily justify anything" in my opening statement was that my comments were not intended whatsoever for justifying whether or not this feature should be implemented. (I realize that my comments are a matter of taste / preference and certainly should not be used to dismiss the proposal).
My true intentions were really to see how other people feel about UX issues associated with this sort of feature, and is arguably somewhat off-topic! :-)
Cheers,
Jeffrey Carpenter

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start shuddering in horror at the whole idea. From a UX stand point, (especially) when my game is full screen, the **last** thing I want to see happen is to lose focus of the game window -- this completely ruins the experience of immersion. I'd much prefer copy and paste of the URL to open a web browser or what not explicitly. I cannot think of any use case off the top of my head where I find the lose of focus appropriate, other than (of course) OS-level events. In other words, I strongly prefer being in control of explicit focus changes of my game.
I see the counter argument being made where **not** having the game auto-minimize or what not and open the program automatically could be seen as less user-friendly here. I'd love to hear your own opinion regarding this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so (minimize / lose focus of the game to do another task), perhaps because the underlying platform is fundamentally different, and/or I don't have 15+ years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of UX issues -- hopefully without inciting a flame war! :-)
You haven't really named a single reason why this function shouldn't be implemented in SDL,
you only elaborated on why you personally wouldn't use such a function.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alexey Petruchik]

Wouldn't changing from "open URL in default browser" to more generic "open
some file in default program" make things more complicated to implement on
all platforms? Seems pretty obvious for Windows\OSX\Linux but what about
iOS\Android and others?

The Topic specifically asks for "Opening an URL in the standard browser",
but if it's really just a wrapper for some OS call what about
SDL_openOsHandle or just SDL_osHandle?
Also I don't think the UX is too terrible.
If you click on a big button "Open in Browser" the user will expect to get
kicked out of the application. Of course this should never happen without
the users consent, but that's outside the scope of SDL...
I think SDL_open could be confused with a SDL version of fopen
I tend to agree that directing a user to a website is a fairly

Post by Luke Groeninger
specific high level task that is probably best left up to the
application developer to decide how they want to handle it. Not only
would it be terrible UX to kick the user outside of an application,
but given things like Steam and Origin have overlays specifically
designed to display webpages without the application losing focus,
it’s a lot more complicated than simply throwing a URL at an OS call.
It is far better to simply not try to tackle that problem inside SDL
than it is to implement a half assed solution for SDL.
THAT SAID. The idea of having an API that calls out to
start/open/xdg-open/whatever is not actually a bad one. It would fall
in line with functions like SDL_strncmp and SDL_malloc as a wrapper
for common operating system functionality, and ultimately would leave
it up to the developer as to what URI they pass to the system and up
to the operating system what would happen with it.
But, that’s not SDL_OpenURL - that’s SDL_open or SDL_launch or
similar. Implementing a wrapper for a common OS call is a very
different story than trying to cram a high level task into a low level
library.
-Luke

Post by Jeffrey Carpenter
<nods> What I meant by "...do not necessarily justify anything" in my
opening statement was that my comments were not intended whatsoever for
justifying whether or not this feature should be implemented. (I realize
that my comments are a matter of taste / preference and certainly should
not be used to dismiss the proposal).
My true intentions were really to see how other people feel about UX
issues associated with this sort of feature, and is arguably somewhat
off-topic! :-)
Cheers,
Jeffrey Carpenter

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not
necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start
shuddering in horror at the whole idea. From a UX stand point, (especially)
when my game is full screen, the **last** thing I want to see happen is to
lose focus of the game window -- this completely ruins the experience of
immersion. I'd much prefer copy and paste of the URL to open a web browser
or what not explicitly. I cannot think of any use case off the top of my
head where I find the lose of focus appropriate, other than (of course)
OS-level events. In other words, I strongly prefer being in control of
explicit focus changes of my game.
I see the counter argument being made where **not** having the game
auto-minimize or what not and open the program automatically could be seen
as less user-friendly here. I'd love to hear your own opinion regarding
this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so
(minimize / lose focus of the game to do another task), perhaps because the
underlying platform is fundamentally different, and/or I don't have 15+
years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of
UX issues -- hopefully without inciting a flame war! :-)
You haven't really named a single reason why this function shouldn't be
implemented in SDL,
you only elaborated on why you personally wouldn't use such a function.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alex Szpakowski]

The functions to do the former also do the latter on Mac/Windows/Linux/iOS/Android, I believe.

Wouldn't changing from "open URL in default browser" to more generic "open some file in default program" make things more complicated to implement on all platforms? Seems pretty obvious for Windows\OSX\Linux but what about iOS\Android and others?
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alexey Petruchik]

I've created feature request in bugzilla
https://bugzilla.libsdl.org/show_bug.cgi?id=2783

Post by Alex Szpakowski
The functions to do the former also do the latter on
Mac/Windows/Linux/iOS/Android, I believe.

Post by Alexey Petruchik
Wouldn't changing from "open URL in default browser" to more generic

"open some file in default program" make things more complicated to
implement on all platforms? Seems pretty obvious for Windows\OSX\Linux but
what about iOS\Android and others?

Post by Alexey Petruchik
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Eric Wing]

Sorry, I'm really late on this one too. But I have useful info I hope.

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.

Thanks,
Eric

[Sylvain Becker]

I have added 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.

see the patch:
https://bugzilla.libsdl.org/show_bug.cgi?id=2783

Post by Eric Wing
Sorry, I'm really late on this one too. But I have useful info I hope.
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
[[NSWorkspace sharedWorkspace] openURL:the_url];
iOS
[[UIApplication sharedApplication] openURL:the_url];
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.
Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Gerry JJ]

The Unix code is broken :/

- It may or may not block, depending on the browser

- It doesn't escape the URL in any way. It'll expand variables, lose
quotes, split at & and partially execute the URL, etc. Or just insert a
semicolon and run anything you want.

-g

Post by Sylvain Becker
I have added 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.
https://bugzilla.libsdl.org/show_bug.cgi?id=2783

Post by Eric Wing
Sorry, I'm really late on this one too. But I have useful info I hope.
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
[[NSWorkspace sharedWorkspace] openURL:the_url];
iOS
[[UIApplication sharedApplication] openURL:the_url];
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.
Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Sylvain Becker]

You're right !

- I am not sure about how to solve the blocking/non-blocking browser.

- The patch is updated: I changed the call to "system()", by a call to
"execl()" (and fork()) so that the URL argument is protected in a
better way.

thanks,

Sylvain

Post by Gerry JJ
The Unix code is broken :/
- It may or may not block, depending on the browser
- It doesn't escape the URL in any way. It'll expand variables, lose quotes,
split at & and partially execute the URL, etc. Or just insert a semicolon
and run anything you want.
-g

Post by Sylvain Becker
I have added 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.
https://bugzilla.libsdl.org/show_bug.cgi?id=2783

Post by Eric Wing
Sorry, I'm really late on this one too. But I have useful info I hope.
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
[[NSWorkspace sharedWorkspace] openURL:the_url];
iOS
[[UIApplication sharedApplication] openURL:the_url];
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.
Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alexander Sabourenkov]

I would recommend using vfork() instead of fork().

Blocking/non-blocking behavior depends on desktop environment, not browser.

xdg-open is just a shell script wrapper, see here -
http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in

In absense of a desktop environment it falls back to run-mailcap and
mimeopen, in that order. I have no idea if that may block (probably), if
any supported DEs' launchers may block (xfce4's does not), and if going
asynchonous (waiter thread, success/no-success message/event injected into
event queue, quite a bit of code and complexity) is in fact worth it.

Might be better to note that the function may block and leave it at that
for now.

[Alexander Sabourenkov]

Also please use _exit() instead of exit().

[Sylvain Becker]

Thanks for the explanation.
I have updated "fork" to "vfork" and "exit" to "_exit".
Just wondering if calling "posix_spawn()" wouldn't be better?

I have also added the MacOSX and IOS part.
Please can someone double-check thoses functions as I don't really
know cocoa/uikit ! (like missing memory release of objects, incudes,
...)



On Sat, Feb 7, 2015 at 6:49 PM, Alexander Sabourenkov

Post by Alexander Sabourenkov
Also please use _exit() instead of exit().
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Eirik Byrkjeflot Anonsen]

Post by Sylvain Becker
Thanks for the explanation.
I have updated "fork" to "vfork" and "exit" to "_exit".
Just wondering if calling "posix_spawn()" wouldn't be better?

Actually, fork() is usually preferred over vfork(). The semantics of
fork() are simple, while vfork() can easily get you into undefined
behaviour. ("the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used to
store the return value from vfork(), or returns from the function in
which vfork() was called, or calls any other function before
successfully calling _exit(2) or one of the exec(3) family of
functions.") And the advantages of vfork() are unlikely to be useful in
this case.

posix_spawn() would surely be a potential alternative. I don't think it
really matters which one you use.

When it comes to blocking behaviour, the problem lies in the fact that
you are waiting for the new process to end. Just remove that and you
won't have blocking behaviour any more. However, that creates a new
problem with zombie processes. You do want to wait for the process
eventually. As long as you don't really care about the new process once
you've started it, this can be solved by forking twice. Start the new
process in the grandchild and immediately exit from the child. In the
parent, you wait for the child. Since the child just forks and execs,
that completes quickly and you have no blocking. At this point the child
process is gone, so the grandchild (which is the one doing the exec())
is now orphaned. Orphaned processes are waited for by the init process
(pid 1), so that will be handled automatically.

eirik

[Alexander Sabourenkov]

Post by Eirik Byrkjeflot Anonsen

Post by Sylvain Becker
Thanks for the explanation.
I have updated "fork" to "vfork" and "exit" to "_exit".
Just wondering if calling "posix_spawn()" wouldn't be better?

Actually, fork() is usually preferred over vfork().

That might be justified if we're talking about small (address-space-wise)
throw-away processes. However, that's not that SDL is about.

Post by Eirik Byrkjeflot Anonsen
The semantics of
fork() are simple, while vfork() can easily get you into undefined
behaviour. ("the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used to
store the return value from vfork(), or returns from the function in
which vfork() was called, or calls any other function before
successfully calling _exit(2) or one of the exec(3) family of
functions.")

The case under consideration certainly shows no potential to trip up on
that.
It's a plain simple fork/exec case - the case the vfork() was designed to
be used in.

Post by Eirik Byrkjeflot Anonsen
And the advantages of vfork() are unlikely to be useful in
this case.

Please clarify.

Post by Eirik Byrkjeflot Anonsen
When it comes to blocking behaviour, the problem lies in the fact that
you are waiting for the new process to end. Just remove that and you
won't have blocking behaviour any more. However, that creates a new
problem with zombie processes. You do want to wait for the process
eventually. As long as you don't really care about the new process once
you've started it, this can be solved by forking twice. Start the new
process in the grandchild and immediately exit from the child. In the
parent, you wait for the child. Since the child just forks and execs,
that completes quickly and you have no blocking. At this point the child
process is gone, so the grandchild (which is the one doing the exec())
is now orphaned. Orphaned processes are waited for by the init process
(pid 1), so that will be handled automatically.

The problem lies not in which pid gets to wait() on spawned processes,
but in the fact that the semantics of xdg-open call are not quite defined.

Life being as it is, I think a double-fork is indeed an acceptable solution
(a setsid() wouldn't hurt either).

Now imagine several gigabytes worth of page tables copied twice over
just so that a tiny shell script can be told to tell the DE to tell a
browser to open an URL.

Doesn't it look like an unnecessary waste? Vfork to the rescue!

[Eirik Byrkjeflot Anonsen]

Post by Alexander Sabourenkov

Post by Eirik Byrkjeflot Anonsen

Post by Sylvain Becker
Thanks for the explanation.
I have updated "fork" to "vfork" and "exit" to "_exit".
Just wondering if calling "posix_spawn()" wouldn't be better?

Actually, fork() is usually preferred over vfork().

That might be justified if we're talking about small (address-space-wise)
throw-away processes. However, that's not that SDL is about.

Post by Eirik Byrkjeflot Anonsen
The semantics of
fork() are simple, while vfork() can easily get you into undefined
behaviour. ("the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used to
store the return value from vfork(), or returns from the function in
which vfork() was called, or calls any other function before
successfully calling _exit(2) or one of the exec(3) family of
functions.")

The case under consideration certainly shows no potential to trip up on
that.
It's a plain simple fork/exec case - the case the vfork() was designed to
be used in.

Sure, but code changes. Someone changing the code and not noticing the
"v" could break it. Or someone seeing the "v" might try to exploit the
shared address space effect, something that is bound to break on some
systems. Basically, what I'm saying is that vfork() is usually an
unnecessary complication, for very little gain.

That being said, I agree that the gain depends on the situation at hand,
and I'll accept that SDL might just be one case where vfork() is worth
it.

Post by Alexander Sabourenkov

Post by Eirik Byrkjeflot Anonsen
And the advantages of vfork() are unlikely to be useful in
this case.

Please clarify.

Without having tested this myself, I assume that the main advantage of
vfork() is that you might be able to spawn thousands of processes per
second rather than a handful. I don't see that as being very useful for
a user-initiated one-off action. Of course, if my intuition about the
performance of fork() is off and it can be expected to take a "long"
time (whatever that is? half a second?) then I'll happily withdraw my
objection :)

And on second thoughts, I guess if you are trying to have smoothly
animated graphics on the same thread as you are calling fork(), you
could be in trouble. (I might think that you shouldn't be trying to have
smoothly animated graphics on the same thread as arbitrary background
processing, but that's just me.)

Post by Alexander Sabourenkov

Post by Eirik Byrkjeflot Anonsen
When it comes to blocking behaviour, the problem lies in the fact that
you are waiting for the new process to end. Just remove that and you
won't have blocking behaviour any more. However, that creates a new
problem with zombie processes. You do want to wait for the process
eventually. As long as you don't really care about the new process once
you've started it, this can be solved by forking twice. Start the new
process in the grandchild and immediately exit from the child. In the
parent, you wait for the child. Since the child just forks and execs,
that completes quickly and you have no blocking. At this point the child
process is gone, so the grandchild (which is the one doing the exec())
is now orphaned. Orphaned processes are waited for by the init process
(pid 1), so that will be handled automatically.

The problem lies not in which pid gets to wait() on spawned processes,
but in the fact that the semantics of xdg-open call are not quite defined.

Not sure what you object to here. If you complain about my mentioning
pid 1, I was merely pointing out that some process will indeed be
wait()ing on the created process. Which is kind of important. (I'm sure
you agree that the blocking is precisely because the main process
wait()s synchronously for the potentially long-running child?)

Post by Alexander Sabourenkov
Life being as it is, I think a double-fork is indeed an acceptable solution
(a setsid() wouldn't hurt either).
Now imagine several gigabytes worth of page tables copied twice over
just so that a tiny shell script can be told to tell the DE to tell a
browser to open an URL.

If you have several gigabytes worth of page tables, I guess that means
you have many terabytes of allocated memory. I think at that point
the slowness of a fork() is the least of your problems :)

Post by Alexander Sabourenkov
Doesn't it look like an unnecessary waste? Vfork to the rescue!

Small wastes in non-critical code doesn't worry me. Straightforward,
"obviously correct" code is generally more important to me. And I always
have to look up the particulars of vfork() whenever I see it used to be
sure it is used correctly.

But I guess it does depend on exactly how much of an advantage vfork()
is over fork() for the use cases SDL caters for. And exactly how
critical this path really is. Objection (mostly) withdrawn :)

eirik

[Sik the hedgehog]

Post by Eirik Byrkjeflot Anonsen
And on second thoughts, I guess if you are trying to have smoothly
animated graphics on the same thread as you are calling fork(), you
could be in trouble. (I might think that you shouldn't be trying to have
smoothly animated graphics on the same thread as arbitrary background
processing, but that's just me.)

Having a separate thread may still not be useful if the operating
system is exhausting all the current CPU resources in order to spawn a
new process anyway. Yeah, nitpicking here, just don't think that you
can spawn a new process and not have a serious slow down during the
time it takes to start it :P

Post by Eirik Byrkjeflot Anonsen
If you have several gigabytes worth of page tables, I guess that means
you have many terabytes of allocated memory. I think at that point
the slowness of a fork() is the least of your problems :)

Sound like bad wording and he just meant gigabytes of pages.

Still, given that games these days demand GBs of RAM in the system
requirements, potentially needing that much copying would be an issue.
I know that Linux only copies when the memory changes, but if the
child process is blocking then that means it could be doing that for a
long time (enough to result in lots of RAM being used up for no real
reason).

[Eirik Byrkjeflot Anonsen]

Post by Sik the hedgehog

Post by Eirik Byrkjeflot Anonsen
And on second thoughts, I guess if you are trying to have smoothly
animated graphics on the same thread as you are calling fork(), you
could be in trouble. (I might think that you shouldn't be trying to have
smoothly animated graphics on the same thread as arbitrary background
processing, but that's just me.)

Having a separate thread may still not be useful if the operating
system is exhausting all the current CPU resources in order to spawn a
new process anyway. Yeah, nitpicking here, just don't think that you
can spawn a new process and not have a serious slow down during the
time it takes to start it :P

I'd still say it is useful. You'll have a lot more chance of reaching
your 16 or 33 ms deadline at degraded performance than when waiting for
a blocking call :)

Post by Sik the hedgehog

Post by Eirik Byrkjeflot Anonsen
If you have several gigabytes worth of page tables, I guess that means
you have many terabytes of allocated memory. I think at that point
the slowness of a fork() is the least of your problems :)

Sound like bad wording and he just meant gigabytes of pages.

Possibly. Which I expect would give maybe tens of megabytes of page
tables. Which should take approximately no time at all to copy.

Hmm, I see that I have an iceweasel (aka firefox) running, taking 2.2 GB
of virtual memory, 800 MB of resident memory, and 3968 kB of page
tables. (Unless I'm looking at the wrong numbers)

Post by Sik the hedgehog
Still, given that games these days demand GBs of RAM in the system
requirements, potentially needing that much copying would be an issue.
I know that Linux only copies when the memory changes, but if the
child process is blocking then that means it could be doing that for a
long time (enough to result in lots of RAM being used up for no real
reason).

Yes, I was assuming that any reasonably modern system would implement
fork() with some form of copy-on-page-required, leaving the process
state and page tables the only thing that fork() actually have to copy
(well, mostly). If SDL supports systems that requires fork() to copy the
whole process's memory space, then by all means use vfork()!

eirik

[Sik the hedgehog]

Post by Eirik Byrkjeflot Anonsen
I'd still say it is useful. You'll have a lot more chance of reaching
your 16 or 33 ms deadline at degraded performance than when waiting for
a blocking call :)

What I meant is that you would not even attempt this in a situation
where you don't need to miss the framerate mark in the first place :P
(and anyway, given the whole point of this function is to open other
program and give focus to it, framerate isn't even relevant here
really)

Post by Eirik Byrkjeflot Anonsen
Possibly. Which I expect would give maybe tens of megabytes of page
tables. Which should take approximately no time at all to copy.

But you'd still need to copy the pages themselves too, which is where
the real problem arises...

Post by Eirik Byrkjeflot Anonsen
Yes, I was assuming that any reasonably modern system would implement
fork() with some form of copy-on-page-required, leaving the process
state and page tables the only thing that fork() actually have to copy
(well, mostly). If SDL supports systems that requires fork() to copy the
whole process's memory space, then by all means use vfork()!

For that kind of stuff there's usually an #ifdef to select between
both methods. The thing is that as I mentioned the issue can even
arise with copy-on-change, if the two processes stay around for too
long (which is what's bound to happen if the call ends up being
blocking).

[Daniel Gibson]

Post by Sik the hedgehog

Post by Eirik Byrkjeflot Anonsen
I'd still say it is useful. You'll have a lot more chance of reaching
your 16 or 33 ms deadline at degraded performance than when waiting for
a blocking call :)

What I meant is that you would not even attempt this in a situation
where you don't need to miss the framerate mark in the first place :P
(and anyway, given the whole point of this function is to open other
program and give focus to it, framerate isn't even relevant here
really)

Post by Eirik Byrkjeflot Anonsen
Possibly. Which I expect would give maybe tens of megabytes of page
tables. Which should take approximately no time at all to copy.

But you'd still need to copy the pages themselves too, which is where
the real problem arises...

Post by Eirik Byrkjeflot Anonsen
Yes, I was assuming that any reasonably modern system would implement
fork() with some form of copy-on-page-required, leaving the process
state and page tables the only thing that fork() actually have to copy
(well, mostly). If SDL supports systems that requires fork() to copy the
whole process's memory space, then by all means use vfork()!

For that kind of stuff there's usually an #ifdef to select between
both methods. The thing is that as I mentioned the issue can even
arise with copy-on-change, if the two processes stay around for too
long (which is what's bound to happen if the call ends up being
blocking).

Not if the fork()ed process exec()s - after that they shouldn't share
any pages anymore.

I'd suggest stopping to discuss about fork() vs vfork() and concentrate
on how to best run that shellscript savely and reap the child later to
prevent zombies.
As this is a common enough task it shouldn't be that hard?

Cheers,
Daniel

[Sylvain Becker]

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

Notice that the return code does not say anymore something about the
success/failure of xdg-open, but now, is about the success/failure of
the *launching* of xdg-open.

PID should be collected and ended manually at the end probably ?

Post by Sik the hedgehog

Post by Eirik Byrkjeflot Anonsen
I'd still say it is useful. You'll have a lot more chance of reaching
your 16 or 33 ms deadline at degraded performance than when waiting for
a blocking call :)

What I meant is that you would not even attempt this in a situation
where you don't need to miss the framerate mark in the first place :P
(and anyway, given the whole point of this function is to open other
program and give focus to it, framerate isn't even relevant here
really)

Post by Eirik Byrkjeflot Anonsen
Possibly. Which I expect would give maybe tens of megabytes of page
tables. Which should take approximately no time at all to copy.

But you'd still need to copy the pages themselves too, which is where
the real problem arises...

Post by Eirik Byrkjeflot Anonsen
Yes, I was assuming that any reasonably modern system would implement
fork() with some form of copy-on-page-required, leaving the process
state and page tables the only thing that fork() actually have to copy
(well, mostly). If SDL supports systems that requires fork() to copy the
whole process's memory space, then by all means use vfork()!

For that kind of stuff there's usually an #ifdef to select between
both methods. The thing is that as I mentioned the issue can even
arise with copy-on-change, if the two processes stay around for too
long (which is what's bound to happen if the call ends up being
blocking).

Not if the fork()ed process exec()s - after that they shouldn't share any
pages anymore.
I'd suggest stopping to discuss about fork() vs vfork() and concentrate on
how to best run that shellscript savely and reap the child later to prevent
zombies.
As this is a common enough task it shouldn't be that hard?
Cheers,
Daniel
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Eirik Byrkjeflot Anonsen]

Post by Sylvain Becker
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked.
Notice that the return code does not say anymore something about the
success/failure of xdg-open, but now, is about the success/failure of
the *launching* of xdg-open.
PID should be collected and ended manually at the end probably ?

Not sure which pid you are talking about here. If you are thinking about
the pid of xdg-open, you can just ignore it. That's really the point of
forking twice. Since xdg-open is now orphaned, "init" (process 1) will
reap it when it dies. I have not looked carefully at the code, only
quickly read through the unix SDL_OpenURL() code, but it looks sensible
to me.

eirik

[Sylvain Becker]

Sorry, I did not explain myself correctly.
Yes, I mean't the xdg-open pid, when xdg-open is blocking because of
the system configuration.
For instance, xdg-open is blocking and opening the url/file with no
window/shell/tty attached.
Then those xdg-open process will last forever, because of no user
interaction, even after the main sdl app has exited.

Don't know if this configuration could happen.
(this can be simulated easily, by replacing the launch of xdg-open in
SDL_OpenURL, by the launching of a script that simply does an infinite
loop).


On Tue, Feb 10, 2015 at 8:15 PM, Eirik Byrkjeflot Anonsen

Post by Eirik Byrkjeflot Anonsen

Post by Sylvain Becker
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked.
Notice that the return code does not say anymore something about the
success/failure of xdg-open, but now, is about the success/failure of
the *launching* of xdg-open.
PID should be collected and ended manually at the end probably ?

Not sure which pid you are talking about here. If you are thinking about
the pid of xdg-open, you can just ignore it. That's really the point of
forking twice. Since xdg-open is now orphaned, "init" (process 1) will
reap it when it dies. I have not looked carefully at the code, only
quickly read through the unix SDL_OpenURL() code, but it looks sensible
to me.
eirik
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Eirik Byrkjeflot Anonsen]

Post by Sylvain Becker
Sorry, I did not explain myself correctly.
Yes, I mean't the xdg-open pid, when xdg-open is blocking because of
the system configuration.
For instance, xdg-open is blocking and opening the url/file with no
window/shell/tty attached.
Then those xdg-open process will last forever, because of no user
interaction, even after the main sdl app has exited.
Don't know if this configuration could happen.
(this can be simulated easily, by replacing the launch of xdg-open in
SDL_OpenURL, by the launching of a script that simply does an infinite
loop).

I see. Yes, that is a point. However, I don't think that is a situation
you want to handle anyway. Consider what would happen if xdg-open
replaces its process with the web browser. The user would probably not
be happy if you kill their web browser.

Also, once you start doing this, you'll have to properly track the
process, which means doing some global work to wait() for the process
again. Which just gets hairy.

I think it is probably better to just assume that xdg-open is sane :)

eirik

[Gerry JJ]

Post by Sylvain Becker
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked.

I don't think you can vfork twice like that. You can call exec*, or
_exit, and that's it. Just use fork :p

Also, could you use execlp with "xdg-open" as the path instead of execl?

-g

[Sylvain Becker]

Updated patch.

Yes, you're totally right. The first forking must be done with
"fork()" because it will then try to fork again (so it calls a
function different from _exit and exec*, making "vfork()" not
recommended there).
Second forking can be done either with fork() or vfork().

(Even if it works my Linux distribution, it's seems to have some
problem with others systems).


Thanks for all comments. Also, Thanks to the original posters of this
thread Alex and Eric, because the patch is mainly of copy-paste of
their indications.

I think, now, it needs also the windows patch. Which I can't do as I
have no window platform ready for that.
Would be nice to have someone to look at it.

Post by Sylvain Becker
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked.

I don't think you can vfork twice like that. You can call exec*, or _exit,
and that's it. Just use fork :p
Also, could you use execlp with "xdg-open" as the path instead of execl?
-g
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Daniel Gibson]

It isn't unusual to have buttons that lead to the game's homepage in the
main menu (or in "about" or some other menu option), for promoting that
page, to show the user where he can find patches, addons or support.
Or maybe links to GPU vendors for updated drivers and things like that.

I think as long as this isn't called from within the game (i.e. when one
is playing and not in the menu) breaking the immersion is not a problem
(but of course it's not up to SDL to prevent the developer from breaking
the immersion anyway).

Cheers,
Daniel

Post by Jeffrey Carpenter
I second the question of what games use this sort of feature.
My comments here are going to be **strongly** opinionated, and do not necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start shuddering in horror at the whole idea. From a UX stand point, (especially) when my game is full screen, the **last** thing I want to see happen is to lose focus of the game window -- this completely ruins the experience of immersion. I'd much prefer copy and paste of the URL to open a web browser or what not explicitly. I cannot think of any use case off the top of my head where I find the lose of focus appropriate, other than (of course) OS-level events. In other words, I strongly prefer being in control of explicit focus changes of my game.
I see the counter argument being made where **not** having the game auto-minimize or what not and open the program automatically could be seen as less user-friendly here. I'd love to hear your own opinion regarding this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so (minimize / lose focus of the game to do another task), perhaps because the underlying platform is fundamentally different, and/or I don't have 15+ years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of UX issues -- hopefully without inciting a flame war! :-)
Cheers,
Jeffrey Carpenter
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Alexey Petruchik]

So... it's seems that I'm not alone here requesting this feature. Talking
about fullscreen interaction I think it's not such a big problem. We can
easily stick to default platform behaviour - almost all OSes will minimize
game for us and almost all developers know what they are doing when they
add open-url-in-browser buttons in their UI. Really looking forward to see
this function in SDL master.

Post by Daniel Gibson
It isn't unusual to have buttons that lead to the game's homepage in the
main menu (or in "about" or some other menu option), for promoting that
page, to show the user where he can find patches, addons or support.
Or maybe links to GPU vendors for updated drivers and things like that.
I think as long as this isn't called from within the game (i.e. when one
is playing and not in the menu) breaking the immersion is not a problem
(but of course it's not up to SDL to prevent the developer from breaking
the immersion anyway).
Cheers,
Daniel
I second the question of what games use this sort of feature.

Post by Jeffrey Carpenter
My comments here are going to be **strongly** opinionated, and do not
necessarily justify anything. And so with that out of the way...
As soon as I reading things like "..minimizing the game", I start
shuddering in horror at the whole idea. From a UX stand point, (especially)
when my game is full screen, the **last** thing I want to see happen is to
lose focus of the game window -- this completely ruins the experience of
immersion. I'd much prefer copy and paste of the URL to open a web browser
or what not explicitly. I cannot think of any use case off the top of my
head where I find the lose of focus appropriate, other than (of course)
OS-level events. In other words, I strongly prefer being in control of
explicit focus changes of my game.
I see the counter argument being made where **not** having the game
auto-minimize or what not and open the program automatically could be seen
as less user-friendly here. I'd love to hear your own opinion regarding
this? (Am I the only one that feels strongly about auto-focus lose?)
I do, however, feel that it is OK for a mobile platform to do so
(minimize / lose focus of the game to do another task), perhaps because the
underlying platform is fundamentally different, and/or I don't have 15+
years of habits formed using the platform?
In short, I'd love to hear about your feelings regarding these sorts of
UX issues -- hopefully without inciting a flame war! :-)
Cheers,
Jeffrey Carpenter
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Ryan C. Gordon]

I think the main reason this functionality hasn't been added is because
it doesn't work with fullscreen games.

If we were to add this, I think it's reasonable to say that fullscreen
windows will be forcibly minimized before the browser is launched.

There are other similar questions, like what happens on Android or iOS
when you open a URL and suddenly some other app is in the foreground,
etc...but I think this is solvable, if there's will to add the API.

--ryan.