DBus interface

Bug #1562673 reported by Alexander Wolf
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Stellarium
Invalid
Wishlist
Unassigned

Bug Description

Inter-operability between KStars and Stellarium through DBus.

Copy of email from maillist (https://sourceforge.net/p/stellarium/mailman/message/34798862/):
KStars is beginning to expose a lot of functionality through D-Bus, the inter-process communication bus on Linuxy operating systems. I'm not sure how portable it is to Windows, but maybe it is, because the bus itself seems to be fairly lightweight. In any case, it can be made optional.

The advantage that Stellarium as well as KStars have with respect to D-Bus is that Qt makes it really easy to expose functionality on DBus. Qt has a qdbusxml2cpp compiler that turns XML descriptions of a DBus interface into appropriate C++ code seamlessly. Examples of how to create DBus interfaces with Qt are available on, for example, the KDE technical wiki:
https://techbase.kde.org/Development/Tutorials/D-Bus/Creating_Interfaces
https://techbase.kde.org/Development/Tutorials/D-Bus

The advantage of exposing functionality over DBus is that one can build very powerful scripts in standard scripting languages that combine the abilities of our planetarium software with that of general scripting. For example, in a shell script, these DBus interfaces may be accessed using the qdbus program. Here is an example using qdbus to get KStars to do various things:
https://kstars.wordpress.com/2014/01/02/astro-scripting-using-kstars-d-bus-interface/
and here's Jasem's tutorial on how to use python to interface with KStars/INDI through DBus:
http://www.indilib.org/support/tutorials/148-dbus-scripting-with-kstars-python.html
In fact, with a month of efforts, I was able to create this project that relies heavily on KStars DBus interfaces to produce this:
http://bas.org.in/~akarsh/Logbook-Project/

Our previous attempts at inter-operability on this mailing list seemed to center around harder tasks / projects, such as trying to share a code-base, or trying to share a data format or the like. These are more involved tasks, probably why we never got around to them. However, if Stellarium and KStars implement D-Bus methods that are designed to share functionality across the two software, we will be able to provide some amount of inter-operability with minimal code changes and ease.

Immediate examples would be to choose objects from Stellarium and center them in KStars, or vice versa; transfer date/time/geographic location settings across the software; etc. Eventually, we may start exposing the ability to use features that are implemented in one software in the other, reducing effort duplication the easy way. For example, one may eventually be able to invoke KStars' star-hopper in Stellarium, so that a power user could use Stellarium's wonderful interface with KStars' unique backends.

It would be good to eventually have Cartes du Ciel interoperability as well. Cartes exposes functionality through a TCP/IP server. One glue program that translates DBus calls to this TCP/IP server will then allow both KStars and Stellarium to interface with Cartes.

Maybe we should all eventually agree on some standard DBus methods for common functionality such as centering, setting zoom, setting time etc. I am happy to improve DBus interfaces in KStars to enable better interoperability with Stellarium.

The idea at the end of the day is to unite the open source astronomy projects so that we can hope to provide a completely open source astronomy solution for almost all needs. This is especially important for Linux users, who have little access to proprietary software.

Regards
Akarsh

Tags: kstars
Changed in stellarium:
importance: Undecided → Wishlist
tags: added: kstars
Revision history for this message
gzotti (georg-zotti) wrote :

Sounds interesting, e.g. printing KStars maps with detailed object lists typeset in LaTeX for Stellarium screens? Or running parallel tours of the heavens shows with the 3 different programs? There is dbus apparently also for Windows.

Note that much control functionality will soon be available via http interface by the RemoteControl plugin (finishing in the socis2015 branch), but the interoperability of programs will open other possibilities.

Changed in stellarium:
status: New → Confirmed
Revision history for this message
Alexander Wolf (alexwolf) wrote :
Revision history for this message
gzotti (georg-zotti) wrote :

Set to invalid here because it will be handled now via Github.

Changed in stellarium:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.