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] 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
On Thu, 28 Apr 2011 18:47:51 +
wrote:
> 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.
> >
> > 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.
> 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.
It would be clearer, I know, if the wireframes were public... so
continue to vote and comment on BMC# 5303[2].
Shane...
[1]http://mxr.meego.com/meego.gitorious.org/source/meego-handset-dialer/src/mainwindow.cpp#208
[2]https://bugs.meego.com/show_bug.cgi?id=5303
___
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.
>
> 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.
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. 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.
> 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.
> Does that clear things up, or am I still missing your point?
The same is being reported in bugzilla (16436) too.
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
On Thu, 28 Apr 2011 08:26:57 +
wrote:
> 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.
>
> 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 don't plan to change this behavior in MTF version, but should be
addressed in the QML port going forward.
Does that clear things up, or am I still missing your point?
Shane...
___
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.
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.
regards
Arun
From: meego-handset-boun...@lists.meego.com
[meego-handset-boun...@lists.meego.com] on behalf of ext Shane Bryan
[shane.br...@linux.intel.com]
Sent: Friday, April 22, 2011 5:23 AM
To: meego-dev; meego-handset
Subject: [Meego-handset] ANNOUNCING: Dialer 'headless' branch has been merged
into master
Thanks to all the hard work of many contributors, we now have the
"headless" branch merged into master.
I've tagged two new versions:
version-0.1.20: Pre-headless state of the tree, in case we need to
reset due to some significant regression
version-0.2.0: Post-headless merge state, from which all new versions
will be derived.
What does this means to you?
1) Pull and/or rebase all your clones/trees.
2) All pending patches or merge requests should be rebased
and re-submitted against this new tag.
3) Discontinue any work based on the 'topic/headless' branch
4) All future QML migration work will start from version-0.2.0
Sorry if this presents any hardships for you, but it will truely
prevent many more going forward, and free up me and others to
begin working on some of the long pending significant bugs and
features.
There are still some changes needed before I can roll this into a new
package for OBS (namely, integration with meegotouch-applifed so
applifed will allow it to be "lazy" shutdown), but it should be very
soon now so stay posted...
Kind regards,
Shane...
___
MeeGo-handset mailing list
MeeGo-handset@lists.meego.com
http://lists.meego.com/listinfo/meego-handset
[meego@localhost ~]$ MClassFactory already contains MWidgetCreator for AlertDialog
Running non-meego graphics system enabled MeeGo touch, forcing native graphicssystem
Not loading meegotouch-qt-style for meegotouch app.
MComponentData: "Testability plugin /usr/lib/qt4/plugins/testability/libtestability.so load failed with error: The shared library was not found."
MAssemblyPrivate: load stylesheet from /usr/share/themes/base/meegotouch/libmeegotouchcore/style/libmeegotouchcore.css
MUniqueStringCachePrivate::fillUniqueStringCache: "Elements in cache /var/cache/meegotouch//css/no_reverse_lookup_string_cache: 1649, 6.28443% filled"
MAssemblyPrivate: load stylesheet from /usr/share/themes/meego/meegotouch/libmeegotouchcore/style/libmeegotouchcore.css
MAssemblyPrivate: load stylesheet from /usr/share/themes/base/meegotouch/dialer/style/dialer.css
MStyleSheetParserPrivate::loadBinary: "/usr/share/themes/base/meegotouch/dialer/style/overrides.css" changed. Recreating cache file
MStyleSheetParserPrivate::loadBinary: "/usr/share/themes/base/meegotouch/dialer/style/overrides.css" changed. Recreating cache file
MUniqueStringCachePrivate::fillUniqueStringCache: "Elements in cache /var/cache/meegotouch//css/reverse_lookup_string_cache: 1739, 5.0539% filled"
MUniqueStringCachePrivate::fillStringToIdCache: filling stringToIdCache for "/var/cache/meegotouch//css/reverse_lookup_string_cache"
MUniqueStringCachePrivate::fillStringToIdCache: filling stringToIdCache for "/var/cache/meegotouch//css/no_reverse_lookup_string_cache"
MStyleSheetParserPrivate::dump: "/var/cache/meegotouch/css/_.usr_.share_.themes_.base_.meegotouch_.dialer_.style_.dialer.css.tmp"
"[dialerapplication.cpp] DialerApplication(): 46"
"[dialerapplication.cpp] init(): 170"
"
==
Using modem: "/n9000"
=="
"[callmanager.cpp] CallManager(): 21"
SeasideSyncModelPriv::SeasideSyncModelPriv(SeasideSyncModel*) Engine is default
SeasideSyncModelPriv::SeasideSyncModelPriv(SeasideSyncModel*) ("tracker", "memory", "invalid")
libqtcontacts-tracker: initializing libqtcontacts-tracker 4.11.8
SeasideSyncModelPriv::SeasideSyncModelPriv(SeasideSyncModel*) Manager is "tracker"
libqtcontacts-tracker: engine.cpp:1554: Method not implemented yet: virtual bool QContactTrackerEngine::saveDetailDefinition(const QtMobility::QContactDetailDefinition&, const QString&, QtMobility::QContactManager::Error*)
void updateDefinitions(QtMobility::QContactManager*) failed to save new detail definition
SeasideSyncModelPriv::SeasideSyncModelPriv(SeasideSyncMo
[Meego-handset] ANNOUNCING: Dialer 'headless' branch has been merged into master
Thanks to all the hard work of many contributors, we now have the "headless" branch merged into master. I've tagged two new versions: version-0.1.20: Pre-headless state of the tree, in case we need to reset due to some significant regression version-0.2.0: Post-headless merge state, from which all new versions will be derived. What does this means to you? 1) Pull and/or rebase all your clones/trees. 2) All pending patches or merge requests should be rebased and re-submitted against this new tag. 3) Discontinue any work based on the 'topic/headless' branch 4) All future QML migration work will start from version-0.2.0 Sorry if this presents any hardships for you, but it will truely prevent many more going forward, and free up me and others to begin working on some of the long pending significant bugs and features. There are still some changes needed before I can roll this into a new package for OBS (namely, integration with meegotouch-applifed so applifed will allow it to be "lazy" shutdown), but it should be very soon now so stay posted... Kind regards, Shane... ___ MeeGo-handset mailing list MeeGo-handset@lists.meego.com http://lists.meego.com/listinfo/meego-handset
