[Meego-handset] [PATCH] Fixed: BMC#17327, Unable to end the hold conference call if still exist an active call in Dialer app Signed-off-by: Arun Ravindran arun...@gmail.com
The root cause of this issue was an improper button update. where
DialerApplication::handleCallsChanged() calls, m_mainWindow-activateWindow(),
but button update happens only if the dialer was not visible previously by the
function void MainWindow::onDisplayEntered(). With this patch the update buttons
is called from DialerApplication::handleCallsChanged() if the application is not
inprestarted state, so that the keypad buttons are updated properly.
---
src/dialerapplication.cpp | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/dialerapplication.cpp b/src/dialerapplication.cpp
index ffd8d90..bbb2606 100644
--- a/src/dialerapplication.cpp
+++ b/src/dialerapplication.cpp
@@ -358,11 +358,16 @@ void DialerApplication::handleCallsChanged()
TRACE
// First release prestart if the application is
// in prestarted state.
-if(isPrestarted())
+if(isPrestarted()) {
setPrestarted(false);
-if (m_mainWindow)
-m_mainWindow-activateWindow();
+if (m_mainWindow)
+m_mainWindow-activateWindow();
+} else {
+if ((m_callManager m_callManager-isValid())
+(m_mainWindow m_mainWindow-keypad()))
+m_mainWindow-keypad()-updateButtons();
+}
}
int DialerApplication::showErrorDialog(const QString msg)
--
1.7.1
___
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] ANNOUNCING: Dialer 'headless' branch has been merged into master
Hi Shane,
With the latest dialer 0.2.1 from OBS, i could never get an incoming
call indication. There are 2 issues
1) In the new dialer.desktop file, i had to comment
X-Osso-Service=com.meego.dialer, in order to make it start from home
screen.
Hmm, I though we had solved this and/or were unable to reproduce it
here (on iCDK).
Mike can you add your recollections on that.
If nothing else, we can have separate .desktop files, one
for /etc/xdg/autostart and another for /usr/share/applications.
alterego also mentioned similar issues with launching.
Noted.
Update:
With commented X-Osso-Service=com.meego.dialer also, the UI is not shown
for the first time if the dialer is not already running.
This is correct as per the code, but is not good w.r.t user experience.
We need to create an auto start, which seems to be a good way till we
get the dialer started as part of applifed.
2) No incoming call is shown to user, probably because in
MainWindow::handleIncomingCall()
if (isOnDisplay()) {
m_alert-setCallItem(call);
m_alert-appear();
}
is never true, and so only the notification of call is shown, not
the alert dialog. i have attached a log, and there is no
releasePrestart called either.
This is expected. It relies on MNotificationManager to to the
right thing by presenting a notification to the user. Clicking
(tapping) on this will invoke the accept() dbus method on the
com.meego.dialer service. There is currently no way to decline
or ignore the call, as MNotificationView class does not support
multiple buttons.
I could never get the call accepted even by clicking on the
notification. But i will verify this once again. I also did not hear
any ring tone.
Are you sure? There are two things to remember:
1) Raising of the application still does not appear to work. You can
see from MainWindow::accept()[1] that I call showMaximized() on the
MApplicationWindow, yet it seems mcompositor/meegotouch-home are not
handling these requests as expected. You may need to explicitly switch
to the application in meegotouch-home
2) Not hearing a ringtone is a separated issue known to still exist on
N900 images AFAIK, and it affects all audio last I heard. Be sure this
is not the real problem before we narrow in on dialer being to blame
there first.
Yes, the ring tone thing seems to be a known issue.
This is a different/special behaviour, when compared to any available
dialer(android, maemo or even symbian), where the user is given a
much cleaner option.
No disagreement there, no one (least of all, me) ever said the design
was complete or fully implemented ;)
How does this work on the ring tone? The issue
here is that user will have to keep looking at the screen to know the
incoming call, which is exactly the issue we were trying to fix. If
he is ready to do that he could even start dialer manually to receive
calls.
As I mentioned above, make sure this isn't a PA or policy issue first.
In my testing on the iCDK as of Wednesday afternoon PST, this all
worked, including ringtone playback, CS voice audio and accept() on the
MNotification handler.
I don't plan to change this behavior in MTF version, but should be
addressed in the QML port going forward.
A clear dialog with many options (deflect, decline,silence, send
message etc) would be the ideal UI to have, at least we should have
place holders for it.
Agreed! I just intend to make this happen in the new QML goodness to
come, not in the MTF version, make sense? If you/we *need* it in the
MTF version, I will be happy to review/accept patches.
I will make some patches.
Regards
Arun
___
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] ANNOUNCING: Dialer 'headless' branch has been merged into master
Hi Shane, With the latest dialer 0.2.1 from OBS, i could never get an incoming call indication. There are 2 issues 1) In the new dialer.desktop file, i had to comment X-Osso-Service=com.meego.dialer, in order to make it start from home screen. Hmm, I though we had solved this and/or were unable to reproduce it here (on iCDK). Mike can you add your recollections on that. If nothing else, we can have separate .desktop files, one for /etc/xdg/autostart and another for /usr/share/applications. alterego also mentioned similar issues with launching. Noted. Update: With commented X-Osso-Service=com.meego.dialer also, the UI is not shown for the first time if the dialer is not already running. This is correct as per the code, but is not good w.r.t user experience. We need to create an auto start, which seems to be a good way till we get the dialer started as part of applifed. Just found that the auto start is already there, i needed to reboot! But yes, without commenting X-Osso-Service=com.meego.dialer in /usr/share/applications/dialer.desktop, the dialer cannot be brought to fore ground. regards Arun ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] [PATCH] Fixed: BNC#14618 Not support end whole conference call by pressing end button one time Signed-off-by: Arun Ravindran ext-arun.1.ravind...@nokia.com
Hi Shane, We can do this one of two ways: 1) I apply these as is (with the only caveat being to please make the commit message more concise and to the point) I saw your patch, and it looks better. The key merge key handling is more robust now, please apply this as is. 2) You resubmit the patch, taking into account the changes I made to yours in my add on patch. Principally, I want to be sure you capture the renaming of all instances of [Mm]ultiParty* to [Mm]ultiparty* and the change from bool based multipartyCalls() to int returning multipartyCallCount(), as described in my commit message. Regards Arun ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] [PATCH] Fixed: BNC#14618 Not support end whole conference call by pressing end button one time Signed-off-by: Arun Ravindran ext-arun.1.ravind...@nokia.com
Hi Shane, On Mon, 28 Mar 2011 14:34:42 +0300 ext-arun.1.ravind...@nokia.com wrote: From: Arun Ravindranext-arun.1.ravind...@nokia.com Added handling of multipart property in the call proxy, call item and callitem model by adding a signal to be emited for the property changes. This signal is handled in call manager now. Removed the usage of multiparty call items and call names from call manager. Also re arranged the GetCalls() and GetProperties() because When dialer starts, it creates the ofono binding objects (modem manager, call manager etc). The call manager get the current call list and calls updateCallItems() from getCallsFinished() function. The updateCallItems() in fact send the signals for handling incoming call alert in the UI. But by this time no UI component is connected for this signal. The UI components are connected after receiving the connected() signal from call manager. The connected signal is sent after GetProperties() return. But calls are updated after GetCalls(), since GetProperties() did not complete the call manager is not online. I think this has come because we initially had GetProperties() function only from call manager and no GetCalls(). Just a note that I have been reviewing this, but found a logic error in existing code this touches, trying to sort out the right solution. Hope to have it done early next week. Could you share some info on this issue?. Will the patch i mailed need changes after this is fixed? regards Arun ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] [Patch] [Dialer] Regarding BMC#14618
Hi Shane,
It would be nice if you could please send your patches inline, rather
than as an attachment?
Sure i will do so.
Also, could you start CC'ing the meego-handset mailing list so everyone
can see the development in the open? It would really help with
perceptions and possibly generate more interest and input from the
community. Thanks.
It will be good to have the wireframes too public. (may be this is an
old and repeated request).
I will work on the other points you mentioned and will mail a fresh patch.
regards
Arun
Specific patch comments in line below.
From db460626b303ab3ef514217bb3266b9a108dfc96 Mon Sep 17 00:00:00 2001
From: Arun Ravindranext-arun.1.ravind...@nokia.com
Date: Thu, 24 Mar 2011 17:34:50 +0200
Subject: [PATCH] Fix for BMC#14618
If you look at my commit history, I really preferre more details in the
commit message, and it makes it easier to track why changes are being
made at quick glance w/out having to look up BMC#'s.
In general, if you're fixing a bug the subject should be something like:
Fixed: BMC# 0 - This is the BMC Summary text
Then, if needed, the commit body can contain more details. Here's an
example from dialers git log:
Fixed: BMC# 14321 - The whole dialer UI will move down ...
Switched to using setPortraitOrientation() rather than by angle. When
combined with Orientation fixes in MTF for BMC# 13246, the orientation
related bugs like this will disappear.
Full solution depends on libmeegotouch 0.20.95 or later, or a version
of libmeegotouch that has these fixes backported to it.
Signed-off-by: Arun Ravindranext-arun.1.ravind...@nokia.com
---
src/callmanager.cpp | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/callmanager.cpp b/src/callmanager.cpp
index 0a92068..36783bb 100644
--- a/src/callmanager.cpp
+++ b/src/callmanager.cpp
@@ -30,9 +30,6 @@ CallManager::CallManager(const QStringmodemPath)
QDBusPendingReplyQVariantMap propsReply;
QDBusPendingCallWatcher *calls_watcher, *props_watcher;
-callsReply = GetCalls();
-calls_watcher = new QDBusPendingCallWatcher(callsReply);
-
// unsync, but feel relief about recursion in manager proxy.
#if 0
// Force this to be sync to ensure we have initial properties
@@ -44,12 +41,17 @@ CallManager::CallManager(const QStringmodemPath)
propsReply = GetProperties();
props_watcher = new QDBusPendingCallWatcher(propsReply);
-connect(calls_watcher,
-SIGNAL(finished(QDBusPendingCallWatcher*)),
-SLOT(getCallsFinished(QDBusPendingCallWatcher*)));
connect(props_watcher,
SIGNAL(finished(QDBusPendingCallWatcher*)),
SLOT(getPropertiesFinished(QDBusPendingCallWatcher*)));
+
+callsReply = GetCalls();
+calls_watcher = new QDBusPendingCallWatcher(callsReply);
+
+connect(calls_watcher,
+SIGNAL(finished(QDBusPendingCallWatcher*)),
+SLOT(getCallsFinished(QDBusPendingCallWatcher*)));
+
How does rearranging the order of these calls actually do anything for
us? AFAIK, there is no determinism to the return order of asyncronous
DBus calls, so I'm not certain this *solves* anything. Please explain.
connect(this,
SIGNAL(CallAdded(const QDBusObjectPath, const QVariantMap)),
SLOT(callAdded(const QDBusObjectPath, const QVariantMap)));
@@ -504,6 +506,7 @@ void CallManager::updateMultipartyCallItems()
qDebug() QString(Purging all multiparty CallItems);
foreach (CallItem *item, m_multipartyCallItems) delete item;
m_multipartyCallItems.clear();
+ emit callsChanged();
Clean up whitespace (TAB) here.
return;
}
@@ -520,6 +523,15 @@ void CallManager::updateMultipartyCallItems()
}
}
+//if there is only one call released then the list contains
+// one call as multiparty, remove it here
+if(m_multipartyCalls.size() == 1) {
+m_multipartyCalls.clear();
+}
+if(m_multipartyCallItems.size() == 1) {
+m_multipartyCallItems.clear();
+}
+
Ok, I see where you are going here... by definition, there must be at
least two calls with the Multiparty property set to True for there to
really be a multiparty call. Yet shouldn't we maybe instead by trying
to ensure we are syncing with the CallProxy on it's propertyChanged as
well (which BTW, I see we are not tracking the Multiparty property
there either, more evidence of the oFono API changing and dialer not
keeping up).
I think it might be more readable to say:
if (m_multipartyCalls.size() 2)
and
if (m_multipartyCallItems.size() 2)
And make the comment a bit more clear that one MP call == no MP call,
in better English that that though ;)
Also, can you look at what we ought to be doing in
CallProxy::propertyChanged() and
Re: [Meego-handset] [dialer] New branch pushed for headless work
Hi Shane/Michael, Hi Michael, See inline On Tue, Mar 22, 2011 at 9:50 AM, Shane Bryan shane.br...@linux.intel.com wrote: On Tue, 22 Mar 2011 17:04:04 +0200 Arun Ravindranext-arun.1.ravind...@nokia.com wrote: 1) the dialer.desktop file changes as described in the README.txt are not working. I had to comment X-Osso-Service=com.meego.dialer, to make it work from the application launcher (desk/home screen) Micheal, ideas on this? I thought you showed it was working, but maybe I didn't get all the patches merged? I do not know what the difference is here. But I need to have the X-Osso-Service=com.meego.dialer defined or it will not launch. There must be some stale bits in my netbook configuration or possibly something has changed in the new image For N900, it started launching after commenting that line. ?? 3) With pre-started dialer, i could never receive incoming call, as no alert dialog is shown. I am still investigating to see what is the issue. Michael, any comments on this one too? It was working but now I too am not getting the call notification.. However interestingly I do get the missed call status notification I think there is issue with callmanager status. it seems it is still not connected. From the logs, it looks like callManagerConnected() is never called and so no handler is available to handle incoming calls. I found that manager proxy's proxyAvail() is emitted before dialerapplication is connected to this signal and hence there is no incoming call indication. But history proxy has no such dependency and so you could see the missed call notifications. Regards Arun ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
Re: [Meego-handset] [dialer] New branch pushed for headless work
Hi Shane, Michael and Arun, others who care... I have pushed Michaels patchset to a new public branch called topic/headless, and am requesting that you guys coordinate your respective work towards the eventual merge into master on this branch. For others that have been waiting (alterego for one) this is where you can start basing future new features, espcially UI related changes, as this branch will be the most likely place what Views will begin to be teased apart from the models and controller. Depending on how drastic or dynamic any new UI work turns out to be, I *may* start a new topic branch for UI changes, stay tuned. Regards, The latest code is using applifed, and not launcher (applauncherd). Any reasons? I took the branch, but had to make a few changes to make make it work in N900. 1) the dialer.desktop file changes as described in the README.txt are not working. I had to comment X-Osso-Service=com.meego.dialer, to make it work from the application launcher (desk/home screen) 2) /etc/prestart/nokia.conf needed the following to start the dialer automatically. application name=dialer service=com.meego.dialer priority=5 / 3) With pre-started dialer, i could never receive incoming call, as no alert dialog is shown. I am still investigating to see what is the issue. regards Arun ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
