xpra://....
xpras://....
(inc win32 changes)
See also:
We should support more transport types using a more generic scheme:
xpra://
for TCP
xpra+ssl://
for SSL
xpra+ssh://
for SSH
xpra+ws://
for websockets
xpra+wss://
for secure websockets
Related: Web-based protocol handlers can be used to register protocols with the browser.
As per rfc2396 appendix A: the scheme should start with a letter and can contain letters, numbers, "+", "-" and "." But it looks like there are compatibility issues with badly written scheme parsers and the "+" character..
Once this is finished, we should register them here: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.
Done in r19856 and tested on:
/usr/bin/update-mime-database /usr/bin/update-desktop-database
We still validate the desktop file during rpmbuild. Yet nothing happens, no warnings, no errors, nothing. But the URL mapping doesn't take:
$ xdg-open xpra+tcp://192.168.1.7:10000/ gio: xpra+tcp://192.168.1.7:10000/: The specified location is not supported
The "legacy" one still does though:
xdg-open xpras://192.168.1.7:10000/
What on earth do we need to do to get the system to update the mapping? (and for the record, I've tried "xpratcp", "xpra-tcp" and "xpra+tcp" as schemes - no difference, none get registered) There will not be a "year of the Linux desktop", it's an endless waste of time.
@smo: please help.
So xdg-open just delegates opening URLs and files to other utilities, depending on what OS and DE is running.
In the case of gnome3 that's "gio" which is part of "glib2". Turning on all debugging with:
G_DBUS_DEBUG=all xdg-open xpra+tcp://host:port/
We get tons of dbus calls, it seems to query org.gtk.vfs.Daemon
.
And also org.gtk.vfs.MountTracker
ListMountableInfo
.
Other scheme types fail in different ways, equally undecipherable.
Well, that's interesting: this problem doesn't occur on any other test systems, only my main development one. PITA.
No amount of running update-desktop-database
or update-mime-database
does any good.
r20271 fixes URL scheme patching, this will do.
@maxmylyn: the URL in the ticket description should fire xpra on all platforms (with the correct transport type). ie:
xdg-open xpra+ssl://192.168.1.6:10000/
Noted and closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1894