Er, not quite. The Bibek approach involves two programs: one, a "daemon" application which runs continuously listening for DBus messages; and two, an application containing your UI, that is started each time a message is received and exited when the user has finished using it.

(I'm not entirely sure that you need such a complex system for this task, but it should work.)

I don't think you need a daemon at all (or even listen to DBus) if you define a mime type for your app. Your app should get called automatically whenever the user attempts to use an item corresponding to the mime type, right? You should be able to avoid using C++ at all and just use a pure QML application that way...

And if I may, let me review a few points of C programming again. In C/C++, an executable program is defined by a "main()" routine. There is exactly one "main()" routine (spelled with four letters, all lower case); it really wouldn't make much sense for more than one to exist, as the compiler then wouldn't know which one would really be the "main" main function.

I didn't read the listing, so this may be not exactly what you want but IMO the best way to launch your app from the events screen is to add a .service file to /usr/share/dbus-1/ like shown here and have a seperate app without gui to update the feed. This is done with a subdirs project.

This way you don't have an app running all the time in the background, (saves battery and resources)

Here's explanation of my method

Add this line in desktop file

MimeType=x-maemo-urischeme/randomName;

Now suppose a url, randomName:helloWorld is called, ur app in exec will be called with helloWorld as argument.

you can enter the url in browser and check, or use Qt.openUrlExternally method from qml also.
Also feeditems url, if set similarly, will invoke ur app

@ Bibek:
Actually i dont understand how the url will be passed to my application when a feeditem is clicked. Like it will come through arguments in main() method or it will be automatically passed to openUrl method of my application when i define
QDesktopServices::setUrlHandler() in my main method.

@qwazix:
I am doing the same approach to generate feeds on home screen, but the problem is that DBus service crashes when i close UI that is generated in response when a feeditem is clicked.

@Copernicus:
Yes two main methods main two applications, one for DBus service and one as daemon. Initially my approach was to have one application doing all the stuff (DBus, GUI) but quitting GUI quits the application thereby crashing the DBus service.

The arguments will come at the argc and argv arguments like plain c++ programs. You dont have to do any extra url handling. Just check the qApplication argc and argv

Don't know how this fits your usecase but I would emit a signal in the method that receives the dbus signal, connect it to the declarativeView and change the loaded qml file, or connect it directly to a qml signal to change the UI dynamically when the user clicks on the notification.

EDIT: The way I described does not require a service running to catch dbus signals. The OS searches in the dbus-1 folder and launches your application if it's not already running.

fo example if you put a .service file there that registers the service to com.qwazix.demo and has an exec=maps, if you do qdbus com.qwazix.demo / methodname 5 then maps will open, and methodname(5) will be called in the dbus adapter class (if methodname exists of course)

Thanks alot you guys. I finally resolved my issue. I am now creating a daemon application for viewing my feeds GUI. But i am having performance issues in GUI opening as it is taking long time. Can someone help me how can i resolve it. I am getting a lot of below output when my GUI is opening

libqtcontacts-tracker: engine.cpp:1591: Not cleaning up obsolete resources for nao:hasTag property since the property's range is too generic (rdfs:Resource).
libqtcontacts-tracker: engine.cpp:1591: Not cleaning up obsolete resources for nao:hasTag property since the property's range is too generic (rdfs:Resource).
libqtcontacts-tracker: engine.cpp:1591: Not cleaning up obsolete resources for nao:hasTag property since the property's range is too generic (rdfs:Resource).
libqtcontacts-tracker: engine.cpp:1591: Not cleaning up obsolete resources for nao:hasTag property since the property's range is too generic (rdfs:Resource).

Hi i finally resolved the time delay issue of my GUI. QMessageService/QMessageManager takes long time to initialize.

One more thing:
QDBusMessage::setArgument() accepts "QList<QVariant> & arguments" as its arguments. What would be the type of arguments of method receiving DBusCall when xml is input to qdbusxml2cpp. would it be "av"?

and how it would be written in xml