Version: unknown (using KDE 3.2.0 RC1, compiled sources) Compiler: gcc version 3.3.2 (Debian) OS: Linux (i686) release 2.6.0-test11 The "examples" link says that rdp:/megan will connect to an rdp server on megan, but actually you need to type rdp://megan or the connect button will still be disabled. IMHO you shouldn't have to type either rdp:// or vnc:// (although I do appreciate the ability to link to rdp:// or vnc:// urls, that's pretty sweet). If a computer name is given with no VNC display number after it, I think KRDC should try the first VNC display first, then RDP.
This is fixed in CVS. I'll backport this as well, so it'll be in KDE 3.2.1.
On a similar note, it seems that the following should work, but doesn't: rdp://server:port - for when RDP is not running on its default port of 3389. For comparison, Windows XP and Server 2003 use this notation (previous versions don't let you change the port): server:port Of course, here that would clash with 'guessing' VNC. In fact, I get confusing behaviour: if I type in localhost:3400 and there is RDP listening on that, krdc tries to connect to it using the VNC protocol, I get a 'Authenticating' progress bar and it hangs for a minute or so, or until I hit Cancel. May I put forward an alternative way of going about this? Guessing the protocol could cause as many usability problems as it solves. How about a drop-down menu placed on a line of its own with heading 'Remote system:' and options 'VNC (Linux and other servers', 'RDP (Windows Remote Desktop)'. One more option on the default page may seem bad, but you would need less explanation text - and if it remembers the users last choice, they'll probably only need it once. In short: adding one more option would make the behaviour more predictable, and it would be possible to use RDP without clicking the Examples link and without typing in a protocol. Failing that, when the user gets a 'connect failed' error, perhaps you could make it clear what protocol you tried connecting on, so the user has a better chance of spotting the problem. (This is not perfect though; if you connect to the wrong port on a firewalled box, the traffic might be silently dropped and you'll get a connect timeout, not so informative.) OK I've said enough! :)
Running more than 100 VNC displays is going to be extremely rare, and running RDP on a port less than 100 is also going to be rare. If those cases ever come up, KRDC can always try connecting both ways. If you have a really pathological case of a firewall silently dropping traffic, then fully qualified URLs can still be used to disambiguate. Guessing the protocol is convenient and can work in almost every case even with the RDP port syntax.