Support an application's own URL scheme from both the application and any web browser

[high_flyer]

Doesn't QUrl do what you need?

[agarny]

Well, I can, using my QWebView widget, retrieve the URL of the link the user wants to open, and QUrl will indeed tell me about the scheme used by the URL. From there, I can determine what do with that URL. All of that, I can do easily.

However, there remains the case where the user goes to my application's website and clicks on a link which uses my application's URL scheme. Now, how do I make sure that my application starts (if needed) and then handles the link? This is what I don't yet know how to do.

[high_flyer]

From a quick look in to the QUrl documentation I could not see that you can set the application responsible for any specific scheme.
However, you can subclass it, and check for the used scheme given in the input url.
If the scheme fits your custom scheme, call QProcess with your application and give the url as parameter.

[agarny]

I think there is a slight misunderstanding. Assuming I understood you correctly, I don't want my application to call an external application if a URL uses my custom scheme. No, in my case, there are two cases I am interested in:

1. The user starts my application and check the HTML-based help which is shipped with my application and which I display using a QWebView widget. If the user clicks on a link which URL uses my custom scheme, then I want my application to handle that URL to, say, open its about dialog box.
2. The user starts his preferred web browser, go to my application's website and then click on a link which URL uses my custom scheme (or directly enters a URL which uses my custom scheme and presses the [Enter] key). At this stage, I want the browser/system to realise that this is a URL which should be handled by my application and not by the browser itself. If my application is not already running, then it should be automatically started. Then, my application should handle the URL in the same way as case #1 above.

Case #1 is very simple for me to handle. It is case #2 which I am not sure how best to handle.

This being said, I have done some more googling and it would seem that depending on the platform you target (Windows, Linux and OS X in my case), then things are really too platform specific (see http://kb.mozillazine.org/Register_protocol).

In the end, it would seem that there is no reliable way of implementing case #2. So, I am starting to think that I should probably only focus on case #1.

[jai]

As per my understanding, you are trying to connect to your native process. that is the same you are expected to achieve through "custom url".
try with using http protocol:

provide your native application support http protocol (works as tiny http server). and from your application pages, call your local applicaiton through http get requests. this mus solve your problem.

[agarny]

Thanks, Jai, but I am not sure I am following you here. This being said, I must confess that I don't currently have time to look into it unless you were to have some sample code which I could test?... Whatever the case, I have, since my last message, implemented #1 and it works perfectly fine.

[thready]

Hi jai,

I like your solution. I'm wondering what to do though, to handle the case that a certain customer cannot have their application listening on port 80 (I must say, many won't be able to because a fair share of people run web servers, depending on the industry of customers you are selling to).

So our current issue is this: we don't want port 80, and we want to be able to detect which port our application is listening on. This brings us to "protocol handlers". Our native application registers iteslf as the handler to a specific protocol.

We can thus use: OurSpecificProtocol://some/rest/call

Our app would open and be able to respond to this. But the question is, what happens on different browsers with this type of request. Can you wrap the call in a javascript try/catch, and if your native app is not responding, fall back to something else...