Marble can open Geo URIs using the --geo-uri parameter. This task shall extend the GeoUriParser class to also handle worldwind URIs.

• Extend the parse() method of GeoUriParser to check if the given string starts with "worldwind". If so, create a QUrl from the string. If it is valid, extract the coordinates from the URL parameters as described in http://www.worldwindcentral.com/wiki/World_Wind_Uri. If the string does not start with "worldwind", the usual Geo URI parsing should happen.
• Test your implementation with some sample worldwind URLs. Register a protocol handler for worldwind similar to the existing marble.protocol handler for the geo protocol. Check if multiple [Protocol] sections can be used in one file, otherwise rename marble.protocol to marble-geo.protocol and create a marble-worldwind.protocol file. For testing, either install to /usr or copy the .protocol file(s) to ~/.kde/share/kde4/services. A geo: or worldwind:// link clicked in a browser should then open Marble at the given location
• Extend the GeoUriParser by a method Planet planet() const. It should return the planet (default: Planet( "earth" )) corresponding to the geo uri / worldwind url. It should be extracted with a heuristic iterating over Planet::planetList and doing a case insensitive substring match of the planet name with the crs (geo uri) or world parameter (worldwind url), if present.
• Change Marble KDE and Qt to query the extracted Planet as well and, in case it differs from the currently shown planet, switches to a map theme from that planet. You can use ControlView::mapThemeManager() and its 

  MapThemeManager::mapThemeIds() method to determine a suitable map theme (using a string based comparison heuristic again. The id scheme is "$planet/$name/$name.dgml"). It might make sense to move the parsing code to ControlView in order to avoid code redundancy in between Marble Qt and KDE.

• Extend the GeoUriParserTest unit test to cover some worldwind URLs as well
• Create a review request