D-Bus is an IPC Mechanism in Linux.
D-Bus allows applications to expose internal API to the outside world by means of remotely callable interfaces.
These APIs can then be accessed at run-time via the D-Bus protocol using command line applications or D-Bus libraries and bindings themselves.
http://www.tune2wizard.com/linux-qt-signals-and-slots-qt-d-bus/
Defintion from others:
D-Bus is a service daemon that runs in the background. We use bus daemons to interact with applications and their functionalities. The bus daemon forwards and receives messages to and from applications. There are two types of bus daemons: SessionBus and SystemBus.
Before start doing any code, there is some terms that one should be familiar with:
http://linoxide.com/how-tos/d-bus-ipc-mechanism-linux/
http://www.linuxjournal.com/article/10455?page=0,1
Q) is This The Best Way?
Using QDBusMessage directly in this way to invoke remote D-Bus methods is not the easiest, best or even recommend way of doing things.
We will now look at the more convenient QDBusInterface class and then look at accessing remote D-Bus interfaces as if they were local methods using proxy classes auto-generated from XML.
https://techbase.kde.org/Development/Tutorials/D-Bus/Accessing_Interfaces
Note:
//Server/Application1 who will expose its function test() which can be invoked from other application2/client
#. Suppose a application(call server or daemon) willing to expose a function named "test()" in its mainwindow.h to other applications.
#. server app will generate a xml file with mainwindow.cpp containg the function to be exposed.
Command line was: qdbuscpp2xml mainwindow.h -o mainwindow.xml
#. server app will generate adapter .cpp and .h (when remote/client another app calls test of server function in adapter is also called.)
Command line was: qdbusxml2cpp -a test_adap mainwindow.xml
#. Server will create a session/sytem d-bus connection and register "service name" and "object name".(client app must mention these in proxy class object)
new MainWindowAdaptor(&w);
QDBusConnection connection = QDBusConnection::sessionBus();
connection.registerService("manoj.test.service.name");
connection.registerObject("/manojobjectpathname", &w);
//test() can be called from client app by mentioning above service name and object name
LocalMainWindowInterface *m_window = new LocalMainWindowInterface("manoj.test.service.name",
"/manojobjectpathname",
QDBusConnection::sessionBus(),
0);
qDebug() << "Result from 1# " << m_window->test("via setParent");
#. Servie name: Service is program started by server/daemon to provide some functionality to other program. e.g. "manoj.test.service.name".
#. Object path name: "/manojobjectpathname"
#. Interface: are classes(p.v.f. or abstract class). that contain mehods and signals. Object name "/manojobjectpathname" has the interface "local.MainWindow" having interface class name as "LocalMainWindowInterface" which have method "Test()".
//Client or application2 who want to use function test() of server/daemon/application1
$. Suppose client/app2 wants to use the function test() exposed by the server/daemon/application1.
$. client application will generate proxy/interface files test_interface.cpp and test_interface.h using the mainwindow.xml of server application.
$. proxy files contains the proxy/remote class name "LocalMainWindowInterface" of server/daemon/app2 which contain the exposed function test().
$. From client app1, test() of server app2 can be called by creating object of proxy/remote class "LocalMainWindowInterface" already created in client app by mentioning the "service name" and "object path name".
LocalMainWindowInterface *m_window = new LocalMainWindowInterface("manoj.test.service.name",
"/manojobjectpathname",
QDBusConnection::sessionBus(),
0);
m_window->test("via setParent");
Download the source code from
https://github.com/manozsahu/dbusDemo1.git
https://github.com/manozsahu/dbusDemo2.git
You may also like
No comments:
Post a Comment