Hi Shane,
This patch emits a signal from callmanager, when a call is added to
prepare the UI. The signal is handled in dialer application to
release the ui from prestart state. ---
src/callmanager.cpp | 3 +++
src/callmanager.h | 1 +
src/dialerapplication.cpp | 11 +++++++++++
src/dialerapplication.h | 1 +
4 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/callmanager.cpp b/src/callmanager.cpp
index 8ff4c8c..37431ec 100644
--- a/src/callmanager.cpp
+++ b/src/callmanager.cpp
@@ -600,6 +600,9 @@ void CallManager::callAdded(const QDBusObjectPath
&in0,const QVariantMap&in1) Q_UNUSED(in1)
TRACE
+ //prepare ui to handle the added call
+ emit prepareViews();
I really don't want to start re-introducing UI logic back into non-UI
classes. So even though this signal doesn't make CallManager handle
UIs, it does make it implicitly UI aware.
Yes, agree. Let me try another method where i can handle this in UI itself.
We already have the callsChanged signal, that is only emitted based on
acquiring the "incoming" call resource (proceedIncomingCall()). If we
don't get the permission from libresource to continue with the incoming
call, we should not be emitting any signals about incoming calls.
Disagree. We do emit incomingCall and callsChanged() even if there is no
permission. deniedIncomingCall and proceedIncomingCall are the same.
The issue here is, the alert dialog is shown for the signal
incomingCall(), and not callsChanged(). But before that the prestart
must be released, otherwise the dialog will not be shown.
Thats the reason why there is emit prepareViews(). The incomingCall()
signal is connected to the main window's handleIncomingCall(). To know
the prestart state we need to make a set of public access functions in
DialerApplication, to know and set the prestart state from MainWindow. I
felt that is unnecessary and emiting a singnal to prepare the views from
backend seemed a simple solution.
diff --git a/src/dialerapplication.cpp b/src/dialerapplication.cpp
index bfe2f7e..c789eb3 100644
--- a/src/dialerapplication.cpp
+++ b/src/dialerapplication.cpp
@@ -116,6 +116,13 @@ void DialerApplication::connectAll()
SLOT(messagesWaitingChanged()));
}
+void DialerApplication::releasePreStart()
+{
+ TRACE
+ if(isPrestarted())
+ setPrestarted(false);
+}
+
We already have this defined in master[1]... why are you adding another?
What we have is the function to activate the widgets. This is to bring
the app out of prestart so that those functions can be called to
activate the views.
Yes, the function name can be changed.
bool DialerApplication::isConnected()
{
TRACE
@@ -260,6 +267,10 @@ void DialerApplication::callManagerConnected()
qDebug()<< QString("Connect resource unavailable");
connect(m_callManager, SIGNAL(callResourceLost(const QString)),
m_mainWindow, SLOT(handleResourceUnavailability(const QString)));
+
+ qDebug()<< QString("Connect ensure UI prepared");
+ connect(m_callManager, SIGNAL(prepareViews()),this,
SLOT(releasePreStart()));
+
I think we'd be better off handling this in
DialerApplication::handleCallsChanged(), checking for incoming call
being defined in the CallManager.
Cannot be done, as explained above. But let me try a different method.
Still we cannot have these 2 signals one after another handled befoe the
prestart is released.
Regards
Arun
_______________________________________________
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset
