[desktop] Stop stripping scheme from URIs #4276

Fixes #3610.

Previously, clicking the URI on Linux produced this error:

xdg-open: file 'www.*' does not exist.

xdg-open expects URIs to start with a scheme (http:// or https://) for them to be opened in a browser, otherwise it treats them as file paths.

Was there a specific reason they were previously being stripped, other than to make the link look "cleaner"?
I'd argue that it's valuable to know if a link is using TLS before clicking on it.

I removed the stripSchemeFromURI function entirely, since it was unused elsewhere, and was not generic to any URI which isn't http(s).

I just realised that the URIs are stripped on mobile too. I personally prefer having more information even if it looks less "clean", but can understand both perspectives.
Should I attempt to unstrip the mobile URIs too, or fix the stripped desktop URIs?

Welcome to the community and thanks for your first contribution on the project 😀
We will try to review the PR soon
Can you sign your commit like explained here?

Diff looks good to me, needs DCO (which should fix the tests unless there are real errors)

@noahgitsham wrote in #4276 (comment):

Was there a specific reason they were previously being stripped, other than to make the link look "cleaner"?
I'd argue that it's valuable to know if a link is using TLS before clicking on it.

Some people might want to know it indeed, but its kind of special interest info nowadays, most people won't care and would prefer a "cleaner" url.

Is it possible to make it display a short/clean version, but resort to a full one when its clicked so that opening works?

@pastk wrote in #4276 (comment):

Is it possible to make it display a short/clean version, but resort to a full one when its clicked so that opening works?

Should be easily possible, the code already uses explicit html <a href=

label->setText(QString::fromStdString("<a href=\"" + value + "\">" + value + "</a>"));

So just strip scheme from the displayed part.

Also there might be cases where url initially comes without a scheme? (I think it could be tagged this way in OSM) Then we'll need to prepend a default https://?

Also there might be cases where url initially comes without a scheme? (I think it could be tagged this way in OSM) Then we'll need to prepend a default https://?

This probably belongs in core though

Or in the generator even.
But in fact Android and iOS apps work just fine with scheme-less urls, it seems to be an issue when its used with xdg-open only, so fixing in Qt client makes sense.