Help Required Regarding Qt (UI opening problem in method)
 

Hi

I am creating an application for Nokia N9 and stuck into a problem with UI opening. In my application, my requirement is to open UI when click the feeditem on home screen. For this i have defined following in main() something like that

int main()
{
QApplication app ();
QDeclarativeView view;

MyApplication application(&view);

registering DBus etc.
return app.exec();
}

In MyApplication, i have a method openFeed() that opens UI when a feeditem is clicked on homescree

void MyApplication::openFeed()
{
here i am loading UI ap like

QString mainQmlFile =
qApp->applicationDirPath() + "/../qml/main.qml";

QDeclarativeComponent component(m_View->engine(),
QUrl::fromLocalFile(mainQmlFile));

if (component.status() == QDeclarativeComponent::Error) {
qDebug() << "Error(s): " << component.errors();
return;
}

QObject * object = component.create();

m_MainItem = qobject_cast<QDeclarativeItem*>(object);

if (m_MainItem == NULL) {
qDebug() << "MainItem is NULL";
return;
}

m_View->scene()->addItem(m_MainItem);

m_View->setGeometry(QApplication::desktop()->screenGeometry());
m_View->showFullScreen();

}

the problem is that when i click the feed item on home screen, 1st time it opens very fast and load my UI. When i close the UI and click someother feeditem, UI takes a long time to load like 15-20sec which is not acceptable.

Can you please help me out of this problem? I will be highly thankful to you.

Re: Help Required Regarding Qt (UI opening problem in method)
 

Hmm. My first concern when I see my code performing a task the second time much worse than the first time, is that something that I did the first time is still around and messing things up. Usually, this means I haven't cleaned up some objects after the first call. I don't see anything in the code fragment that would cause this problem, though.

The Qt docs also mention that mixing QWidgets and QML can lead to performance degradation. I doubt it could lead to this much performance degradation, but it's something to check. :)

Re: Help Required Regarding Qt (UI opening problem in method)
 

what will be your recommendations in this case. Actually when i close the feeditem UI 1st time, it causes crashing the DBus service as QDeclarativeView quits the applications when UI is closed and then service registers automatically, application starts again and so on which explain the delay for 2nd time.

Why QDeclarativeView dont work if defined in someother method instead of main() method. Like if i define QDeclarativeView in openFeed(), UI is not loaded when clicking the feeditem.

Re: Help Required Regarding Qt (UI opening problem in method)
 

Aha, yeah that would explain the delay. :)

I really don't use QML myself (I do pretty much all my Qt with straight up QWidgets), but I'll take a crack at it here. :) Lets see... The QDeclarativeView is one way of loading QML components from a C++ object; its benefit is that it loads the QML directly into a QGraphicsView. (The QGraphicsView / QGraphicsScene is a QWidget mechanism used for displaying complex graphics.) There shouldn't be any need to tie QGraphicsView or QDeclarativeView to the main() method, so presumably there's something about how it's being used outside of the main() routine that is going wrong.

Hmm. You're declaring your QDeclarativeView as an "automatic" variable; this only works as long as you don't set a parent for it. Qt always wants to take ownership of child QObject itself, so that it can call their destructors at an appropriate time. If you are setting a parent, you'll want to construct it on the heap instead:

Actually, before going any deeper into this, I should ask: for what purpose are you trying to combine C++ and QML? (Could you implement your program just using one or the other? It might make things simpler, and possibly provide better performance as well...)

Re: Help Required Regarding Qt (UI opening problem in method)
 

The only purpose of combining C++ and QML is to load my custom UI when a feeditem is clicked. But the problem now is that quitting the UI quits my application. My requirement is that closing the UI should not quit my application. Is there a way to fix it?

Re: Help Required Regarding Qt (UI opening problem in method)
 

Well, in your main() routine, you're creating a QApplication object, and then calling "app.exec()" on it as the last command in that routine. (Which is how the Qt SDK normally sets up the default main() routine for a Qt Widgets app.) The QApplication object creates an "event loop" to handle the user interface, and when the user closes the UI, the event loop ends, and the "exec()" routine returns. Therefore, since the main routine ends when "exec()" returns, the application quits.

If you want your program to continue to run, you will either need to ensure that the event loop does not exit when your UI is closed, or not exit the main() routine when "app.exec()" returns, or something like that.

I guess what you're aiming at here is a program that sits and listens for DBUS requests, popping up the QML UI whenever it receives one?

Re: Help Required Regarding Qt (UI opening problem in method)
 

"I guess what you're aiming at here is a program that sits and listens for DBUS requests, popping up the QML UI whenever it receives one?"

Yes this is the exact requirement of my application. If i don't put "app.exec()" at end of main method, application don't load at all. I am unable to figure out any alternative way.

Re: Help Required Regarding Qt (UI opening problem in method)
 

Well, let's step back a moment here. In C and C++, the function main() is used as the basis to create an executable program. The program begins by executing the first statement within main(), and ends when it finishes the last statement within main().

There's no need for the call to app.exec() to be that last statement. For example, if you've got your own custom DBUS handler, you could have something like:

This would create a new Qt UI every time a new DBUS request comes in.

On the other hand, if you're using Qt itself to process DBUS requests, you could use two event loops, the outer one to catch the requests, and the inner one to display the user interface.

Even better, just have Qt "hide" the UI when the user is done with it, rather than close the event loop entirely. It's a real pain to completely shut down and then completely recreate a GUI interface; it'd be nicer to leave the UI up and running if you're expecting the user to come back to it frequently. This way, you only need to use one event loop; just have Qt "show" the UI again when another DBUS signal comes in...

I'm not sure if it's feasible or useful doing here, you can register a url mime type in ur UI's .desktop file. Then you could pass that url mime in feeditem's urls. Doing that would invoke your UI automatically whenever items are clicked, along with the url as argument to ur exec specified in that desktop file

And probably you need to separate your UI and daemon. Daemon should be running in back, UI should open and close but not access backend tasks as long as daemon is running.

Not sure if there is an way to synchronise the resources loaded by daemon to make UI startup faster (was it booster's purpose?) , but I think I read it somewhere.

Re: Help Required Regarding Qt (UI opening problem in method)
 

The problem is that QDesktopServices::setUrlHandler() never worked for me. Now if i use Bibek approach, i will be having two main methods, one to register DBus service and other one to handle the Url.

int Main()
{
QApplication app();
DBus Service regiteration
return app.exec();
}

int main()
{
QDeclarativeView view;
MyHandler object(&view);
QDesktopServices::setUrlHandler("myscheme", &object, "openUrl")
return app.exec()
}

in my desktop file

[Desktop Entry]
Type=Application
Name=My Application
MimeType=x-maemo-urischeme/myscheme;
Exec=/opt/myapplication/bin/myapplication %U
OnlyShowIn=X-MeeGo;

when i click the feeditem, openurl() is never executed.

Re: Help Required Regarding Qt (UI opening problem in method)
 

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. :)

Re: Help Required Regarding Qt (UI opening problem in method)
 

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

Re: Help Required Regarding Qt (UI opening problem in method)
 

@ 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

Re: Help Required Regarding Qt (UI opening problem in method)
 

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)

Re: Help Required Regarding Qt (UI opening problem in method)
 

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).

Re: Help Required Regarding Qt (UI opening problem in method)
 

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