[Meego-handset] MeeGo 1.2 DE for N900 - UX Response Time measurements (wk17)

2011-05-02 Thread Anssi.Takku
Hi,

we have started to ran weekly basis small response time set to track possible 
performance improvements or regressions for DE for N900.

Results can be found from here:
http://wiki.meego.com/ARM/N900/QA/Performance

As a basis we measured response times with MeeGo 1.1 release and will continue 
to track these with weekly releases.

This week's highlights (release 1.1.99.4.20110427.5.DE.2011-04-29.1):
- compared to Alpha (wk15) release all response times have got worse (e.g. 
browser start-up time is now 15s more than with Alpha release)
- due to bugs shutdown time, incoming call, and camera opening times couldn't 
be measured

Br,
Anssi (zotte)
___
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

2011-05-02 Thread Arun Ravindran

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


[Meego-handset] [PATCH] Patch:Fix for unable to see alert dialog for MT call Signed-off-by: Arun Ravindran ext-arun.1.ravind...@nokia.com

2011-05-02 Thread ext-arun . 1 . ravindran
From: Arun Ravindran ext-arun.1.ravind...@nokia.com

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();
+
 QString path = in0.path();
 
 qDebug()  QString(CallAdded: \%1\).arg(path);
diff --git a/src/callmanager.h b/src/callmanager.h
index 8f14c33..8fb7491 100644
--- a/src/callmanager.h
+++ b/src/callmanager.h
@@ -92,6 +92,7 @@ Q_SIGNALS:
 void connected();
 void disconnected();
 void onlyEmergencyCalls();
+void prepareViews();
 
 private Q_SLOTS:
 void updateCallItems();
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);
+}
+
 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()));
+
 }
 
 void DialerApplication::callManagerDisconnected()
diff --git a/src/dialerapplication.h b/src/dialerapplication.h
index 5a3b57f..f3e9f5d 100644
--- a/src/dialerapplication.h
+++ b/src/dialerapplication.h
@@ -65,6 +65,7 @@ private Q_SLOTS:
 void switchPageNow(int id);
 void connectAll();
 void handleCallsChanged();
+void releasePreStart();
 
 private:
 void init();
-- 
1.7.0.4

___
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

2011-05-02 Thread Arun Ravindran

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] Patch:Fix for unable to see alert dialog for MT call Signed-off-by: Arun Ravindran ext-arun.1.ravind...@nokia.com

2011-05-02 Thread Shane Bryan
On Mon,  2 May 2011 13:37:15 +0300
ext-arun.1.ravind...@nokia.com wrote:

 From: Arun Ravindran ext-arun.1.ravind...@nokia.com
 
 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.

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.

 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?

  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.

Shane...

[1]http://mxr.meego.com/meego.gitorious.org/source/meego-handset-dialer/src/dialerapplication.cpp#60
___
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset


[Meego-handset] Dialer Project meeting - Agenda for Tuesday 5/3

2011-05-02 Thread Shane Bryan

Agenda for the Dialer Project meeting - Tuesday, May 3rd, 2011

* General information/business (Shane)
  - applifed vs. xdg-autostart?
  - QML Dialer architecture discussion:
* meego-qml-launcher vs. libmeegoqmllauncher vs. QApplication w/
  QDeclarativeView(s)?

* Bug, patch and merge-request status (Shane)
  Bugs:
  - We'll review what folks want to review.  Send me hot ones you want
to discuss, or have them ready when we get to this topic

* Any Other Business

-- 
Shane...
___
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset