[Announce] qgvdial: Google Voice client for Qt platforms - Page 8 - maemo.org

Active Topics

U-Boot for Nokia RX-51 with BootMenu (updated version 2012.10-rc3-1) (842)
to Alternatives by Maemish - 2 hrs, 25 mins ago
List of well performing apps on Leste (34)
to Maemo 7 / Leste by biketool - 23 hrs, 36 mins ago
Maemo repository (5)
to Community by dredlok706 - 2 days, 18 hrs ago
Re-commissioning N9 in 2018 (127)
to MeeGo / Harmattan by smatkovi - 2 days, 21 hrs ago
Porting apps to Leste (41)
to Maemo 7 / Leste by Arno_11 - 3 days, 14 hrs ago
N900 is not recognizable on any of my devices (windows 10,7, xp) What can I do? (1)
to Nokia N900 by nieldk - 5 days, 3 hrs ago
more...

Page 8 of 70

Thread Tools

	fcrochik	2010-08-09 , 22:20
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#71

Originally Posted by uvatbc

Thanks!
Is there any way I can pull my google contacts into the phone without using MfE? Or do I have to write that app myself?

What is mfe? (EDIT: Just saw on a different topic: Microsoft For Exchange)?

You can use MyContacts to get any contact from the contacts database. The contacts database will include "google contacts" only if TOR is installed (and active?).

Felipe

__________________

My maemo work:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
For Harmattan:
GeePS - native UI around google maps - GApp - access to optimized mobile "google apps".
Shutdown - shutdown and reboot with one click - QuickCall - one click call, skypeout and google voice integration using dial tones.
WakeOnLan - wake computers on your local network.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
For Maemo/N900:
GApp - access to optimized mobile "google apps". - MobWebMail: browser optimized to access multiple gmail accounts
MyContacts: 75 Contacts on your desktop, ring tones per group and more - GeePS: native front-end for google maps
Macuco2 : web browser to access web sites optimized for the iphone - WakeOnLan: wake up computers on your local network
dbBrowser: Simple application to browse sqlite databases

Last edited by fcrochik; 2010-08-09 at 22:31.

Quote & Reply |

	fcrochik	2010-08-09 , 22:50
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#72

Originally Posted by epage

Something I look forward to is QtMobility is going to have support for pluggable contact engines. This expands the Maemo5 behavior of pulling contacts from eds and telepathy. I imagine it would be easier to write contact engines rather than sync engines but maybe I haven't research sync enough.

Sadly when I looked at the product support Symbian was supported but not Harmattan. I am unsure when n900-like meego devices will have it.

We can create a new "contact engine" for QtMobility as it is. I had to play a little bit with the "maemo5" backend and end up creating an "alternative version" of it to be able to use the latest code from the repository. I think would be pretty simple to start with the code that you created for TOR and create a QtMobility Contacts backend for google contacts.

Allowing to merge these contacts with a different engine (or the local contacts database would be a different issue all together).

Off topic:
I wonder why we still don't have a qt mobility backend based on sqllite. If we could have a "database" that would cache/aggregate contacts information from different backends it would be easier to deal with syncing/merging. I guess that is the idea with the current "contacts database" but I would prefer a cross platform implementation where we could create backends that deal with the data (sql) directly.

Quote & Reply |

uvatbc	2010-08-09 , 23:18
Posts: 1,048 \| Thanked: 979 times \| Joined on Mar 2008 @ SF Bay Area	#73

Originally Posted by fcrochik

We can create a new "contact engine" for QtMobility as it is. I had to play a little bit with the "maemo5" backend and end up creating an "alternative version" of it to be able to use the latest code from the repository. I think would be pretty simple to start with the code that you created for TOR and create a QtMobility Contacts backend for google contacts.

Allowing to merge these contacts with a different engine (or the local contacts database would be a different issue all together).

Off topic:
I wonder why we still don't have a qt mobility backend based on sqllite. If we could have a "database" that would cache/aggregate contacts information from different backends it would be easier to deal with syncing/merging. I guess that is the idea with the current "contacts database" but I would prefer a cross platform implementation where we could create backends that deal with the data (sql) directly.

Some additional input to this idea: I already have the QT code to pull and parse Google contacts in qgvdial. I started looking at the qtmobility QtContacts* classes and it seems it will be fairly trivial to pull from google contacts and store into the n900's default contacts backend.

Creating a sqlite backend sounds like a really good idea - it might reduce the amount of time it takes to load and search through contacts - and if it is good enough, we can try pushing for it to be the default in the n900.

What would be really cool is if we could get newer QT versions supported on older maemos as well so that these improvements get back ported.

So many possibilities!

__________________
qgvdial: Google Voice client. All downloads
qgvtp: Phone integration for the n900 that dials out and sends texts using qgvdial.
mosquitto: message broker that implements the MQ Telemetry Transport protocol version 3.
qgvnotify: Google voice and contacts notifier for diablo and maemo.

If you want to thank me, click the Thanks button.
If you'd like to thank my applications, vote to move them to extras.

Quote & Reply |

	fcrochik	2010-08-09 , 23:43
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#74

Originally Posted by uvatbc

Some additional input to this idea: I already have the QT code to pull and parse Google contacts in qgvdial. I started looking at the qtmobility QtContacts* classes and it seems it will be fairly trivial to pull from google contacts and store into the n900's default contacts backend.

Creating a sqlite backend sounds like a really good idea - it might reduce the amount of time it takes to load and search through contacts - and if it is good enough, we can try pushing for it to be the default in the n900.

What would be really cool is if we could get newer QT versions supported on older maemos as well so that these improvements get back ported.

So many possibilities!

I am right there with you! I would love to have my n800 back in action and, more important, I just don't want the n900 to have the same faith.

Getting your code into a new backend is a good first step but I think for you to have this contacts integrated into the "standard contacts database" won't be as much fun. You will have to make sure to add the "google account" field (preferably as TOR would have them) and I would guess, in order to make efficient to synchronize, you will need to create a cross-reference table somewhere else.

The more I play/think about the current contacts database the more I like the idea of creating a new one: a "killer" one that will support all the standard features and then some. I love the n900 and the "multiple accounts/telepathy" but the "regular phone" features are, at best, just OK. Grouping contacts, ring tone by contact, multiple notes fields, custom fields, custom labels for fields, ... I want to have all the information I may want (and yet don't know I want) about some person/company in just one place.

epage: does TOR store the google contacts on the "user contacts" database? I would imagine it does because I was able to merge them with my other contacts. I assume I just don't see them when TOR is disabled, right?

Quote & Reply |

	epage	2010-08-10 , 02:38
	Posts: 1,684 \| Thanked: 1,562 times \| Joined on Jun 2008 @ Austin, TX	#75

Originally Posted by fcrochik

We can create a new "contact engine" for QtMobility as it is. I had to play a little bit with the "maemo5" backend and end up creating an "alternative version" of it to be able to use the latest code from the repository. I think would be pretty simple to start with the code that you created for TOR and create a QtMobility Contacts backend for google contacts.

Allowing to merge these contacts with a different engine (or the local contacts database would be a different issue all together).

Off topic:
I wonder why we still don't have a qt mobility backend based on sqllite. If we could have a "database" that would cache/aggregate contacts information from different backends it would be easier to deal with syncing/merging. I guess that is the idea with the current "contacts database" but I would prefer a cross platform implementation where we could create backends that deal with the data (sql) directly.

I just looked at the supported platforms page and they've added contacts to Maemo 5 since I last looked.

It sounds like right now it will present to apps the collection of results returned by each contact manager with one source being Maemo 5's contacts. I can't imagine they've already made contact support within their apps pull from this so it won't be entirely seamless but oh well.

Originally Posted by fcrochik

Getting your code into a new backend is a good first step but I think for you to have this contacts integrated into the "standard contacts database" won't be as much fun. You will have to make sure to add the "google account" field (preferably as TOR would have them) and I would guess, in order to make efficient to synchronize, you will need to create a cross-reference table somewhere else.

I agree with this sentiment. The best I would recommend is plugging into a sync framework like OpenSync, I just couldn't find good information on how to do that.

Originally Posted by fcrochik

epage: does TOR store the google contacts on the "user contacts" database? I would imagine it does because I was able to merge them with my other contacts. I assume I just don't see them when TOR is disabled, right?

The integrated contacts view pulls from multiple sources (like what QtMobility will allow). The only sources I am aware of are eds and Telepathy. Each telepathy connection manager is responsible for providing the contacts through the dbus api. The integrated contacts support I believe caches things in the database and handles the merging of contacts.

__________________
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog

Quote & Reply |

	fcrochik	2010-08-10 , 03:05
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#76

Originally Posted by epage

I just looked at the supported platforms page and they've added contacts to Maemo 5 since I last looked.

It sounds like right now it will present to apps the collection of results returned by each contact manager with one source being Maemo 5's contacts. I can't imagine they've already made contact support within their apps pull from this so it won't be entirely seamless but oh well.

MyContacts has been using Qt Mobility Contacts to get the contacts since first release and it does combine all the different backends.

Originally Posted by epage

The integrated contacts view pulls from multiple sources (like what QtMobility will allow). The only sources I am aware of are eds and Telepathy. Each telepathy connection manager is responsible for providing the contacts through the dbus api. The integrated contacts support I believe caches things in the database and handles the merging of contacts.

You are exactly right on how it works...

Quote & Reply |

	fcrochik	2010-08-10 , 13:26
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#77

@uvatbc:

I just release a new version of mycontacts that is ready to be integrated to qgvdial so the user can select a contact from the "phone" contacts database.

Install the 0.9.13 release and give a try:

Code:

dbus-send --print-reply --dest=com.crochik.MyContacts / com.crochik.MyContacts.select_phone string:qgvdial

It will show mycontacts and allow the user to select a phone. After selecting the phone mycontacts will place the call using qgvdial dbus signal. Please note that qgvdial must be running in order to work.

If you like it all that you need to do is create a new button that will send this dbus signal.

Quote & Reply |

The Following User Says Thank You to fcrochik For This Useful Post:
uvatbc

	epage	2010-08-11 , 11:41
	Posts: 1,684 \| Thanked: 1,562 times \| Joined on Jun 2008 @ Austin, TX	#78

I was curious if this discussion has led anyone else to start writing a Google QtMobility Contacts Engine?

If not, I think I'll start working on one. There is already another contact engine I want to write so it could be a good learning experience for me (C++ developer but never done Qt in C++ before). Maybe when QtMobility 1.1 comes out I'll also write a Google calendar engine (since I also have another calendar engine I want to write).

__________________
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog

Quote & Reply |

	fcrochik	2010-08-11 , 12:41
	Posts: 722 \| Thanked: 1,223 times \| Joined on Apr 2010 @ USA	#79

Originally Posted by epage

I was curious if this discussion has led anyone else to start writing a Google QtMobility Contacts Engine?

If not, I think I'll start working on one. There is already another contact engine I want to write so it could be a good learning experience for me (C++ developer but never done Qt in C++ before). Maybe when QtMobility 1.1 comes out I'll also write a Google calendar engine (since I also have another calendar engine I want to write).

Are you planing on writing the "sqllite" one or are you talking about creating one to get the google contacts?

It seems to me that if the goal is to get the google contacts that you have already accomplished that with TOR. The telepathy service is all that we really need for the n900. It seems to me that writing a "qt mobility contact backend" for this would probably create more problems than solve, writing an application to use more than one backend at the same time and have to merge them would only make matters more difficult.

If you are planing on writing the "sqllite" (or even better a generic sql one) we could try to work together.

I would say if we:

create a new sql "backend" with all the good features
create some "plugable" way of adding/editing contacts so people can create other "plugins" (e.g. synchronize with Exchange, ...)
create on plugin to get the "information" from the different "telepathy" accounts
optionally one to synchronize the information with the "current n900 address book".

we would be able to create a pretty powerful "qt" based solution to handle "contacts" - I would even go further and say that something like this IMHO should have been (and could become) the base for meego.

Quote & Reply |

	epage	2010-08-11 , 16:14
	Posts: 1,684 \| Thanked: 1,562 times \| Joined on Jun 2008 @ Austin, TX	#80

Originally Posted by fcrochik

Are you planing on writing the "sqllite" one or are you talking about creating one to get the google contacts?

It seems to me that if the goal is to get the google contacts that you have already accomplished that with TOR. The telepathy service is all that we really need for the n900. It seems to me that writing a "qt mobility contact backend" for this would probably create more problems than solve, writing an application to use more than one backend at the same time and have to merge them would only make matters more difficult.

Right now Telepathy can only let me expose contact ids. There has been talk to expose im contact information. Then the Maemo contact manager would need support added to pull from it. At this point we would maybe have full google contact support.

Also note that I have multiple contact engines I am wanting to implement.

Originally Posted by fcrochik

If you are planing on writing the "sqllite" (or even better a generic sql one) we could try to work together.

I would say if we:
create a new sql "backend" with all the good features

create some "plugable" way of adding/editing contacts so people can create other "plugins" (e.g. synchronize with Exchange, ...)

create on plugin to get the "information" from the different "telepathy" accounts

optionally one to synchronize the information with the "current n900 address book".

we would be able to create a pretty powerful "qt" based solution to handle "contacts" - I would even go further and say that something like this IMHO should have been (and could become) the base for meego.

Ehh, so you are talking about making a plugin to Qt Mobility contacts engine to create a unified front for contacts that pulls from multiple plugins? Plugins within plugins which sound like they are all meant to serve the same purpose? Sounds a bit strange to me (but I've never use the QtMobility Conctacts API). Since multiple backends are supported I would assume its better to talk to the Qt people to get issues fixed rather than creating a plugin system within their plugin system.

__________________
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog