After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 361156 - Integrate contacts component with google maps
Integrate contacts component with google maps
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.30.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
evolution[google]
: 200040 394430 509051 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-10 14:31 UTC by Javier F. Serrador
Modified: 2013-09-13 01:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A first version of a map integration plugin (3.51 KB, application/x-gzip)
2009-09-22 14:06 UTC, Cedric Bosdonnat
  Details
Patch integrating the plugin to Evolution sources in git (16.14 KB, patch)
2009-09-25 12:59 UTC, Cedric Bosdonnat
committed Details | Review
Patch adding the Clutter-gtk checks (3.17 KB, patch)
2009-11-27 14:38 UTC, Cedric Bosdonnat
reviewed Details | Review

Description Javier F. Serrador 2006-10-10 14:31:32 UTC
Wouldn't be cool if you were able to locate an address in googlemaps just with a single mouse clic...
Comment 1 Gilles Dartiguelongue 2007-05-04 08:31:23 UTC
that would probably be more interesting than the current solution for users outside of US.
Comment 2 Gilles Dartiguelongue 2007-11-18 14:45:15 UTC
note: leopard mail app has googlemaps integration now.
Comment 3 André Klapper 2009-09-22 13:35:42 UTC
Also see http://cedric.bosdonnat.free.fr/wordpress/?p=496
Comment 4 Cedric Bosdonnat 2009-09-22 14:06:00 UTC
Created attachment 143699 [details]
A first version of a map integration plugin

The attached code isn't really clean ATM (the makefile isn't nice). It depends on Geoclue and LibChamplain (0.4 or more).

The current code is only showing a map of all the contacts of an addressbook. Some additional features could be added but may need more deeper hack of evolution like:
  * show the position of a single contact (context menu of the contact)
  * show the position of an appointement. That would need to improve the appointement location field in the core.
Comment 5 André Klapper 2009-09-22 14:43:12 UTC
Hi Cedric, thanks for sharing this!

In the xml file, can you please change 
name= to _name= and <description> to <_description> so it can get translated?
And in the C file, please also mark "Contacts map" as translatable.

It also seems that current geocoder is hardcoded to Yahoo - would probably be nice to choose Google Maps and OpenStreetMap from the "Configuration" tab of the plugin.
Comment 6 Cedric Bosdonnat 2009-09-22 15:33:07 UTC
(In reply to comment #5)
> Hi Cedric, thanks for sharing this!
> 
> In the xml file, can you please change 
> name= to _name= and <description> to <_description> so it can get translated?
> And in the C file, please also mark "Contacts map" as translatable.

I'll do it... but I think I'll set some temporary git repo: moving all the tiny changes here will be horrible.

> It also seems that current geocoder is hardcoded to Yahoo - would probably be
> nice to choose Google Maps and OpenStreetMap from the "Configuration" tab of
> the plugin.

The current Geoclue provides Yahoo or geonames geocoders. To geocode addresses, Yahoo is better (more precise) than Geonames. Regarding the Google Geocoder / options there is currently no implementation for them in geoclue and libchamplain: the blockers are mostly about licenses.

Note that I'm not an old evolution hacker: I have started with that plugin: there may be things that I haven't seen / understood.
Comment 7 Chenthill P 2009-09-22 16:28:35 UTC
Cedric, cool feature!! excites us when there are new contributors for evolution!
We can add this as an experimental plugin and once tested can be added to base plugins..

You would need to check for the presence of GeoClue and libchamplain in configure.ac and compile the plugin only when there are available. You would need to add this plugin under plugins_experimental in configure.ac.

There have been some changes made in plugin infrastructure, some part of eplug.xml and contacts-maps.c needs to be changed. For the knowing the changes that have to be made you can use http://git.gnome.org/cgit/evolution/tree/plugins/save-calendar as an example.

Will you be able to build evolution from source (from master branch) ?
Comment 8 Cedric Bosdonnat 2009-09-23 07:21:04 UTC
I'll have a look at that, but I can't promise when as I'm doing this during some nights :)

Thanks for the tips.
Comment 9 Cedric Bosdonnat 2009-09-25 12:59:50 UTC
Created attachment 143984 [details] [review]
Patch integrating the plugin to Evolution sources in git
Comment 10 Milan Crha 2009-11-26 21:07:39 UTC
I take Chen's comment #7 as a green for a new plugin, thus I tested the recent patch.

The bad news is that I cannot compile it with my system provided (ancient?) packages:
libchamplain-gtk-0.3.5
clutter-gtk-0.8.2
geoclue-0.11.1

which results in below errors during compile time:
> In file included from contacts-map.c:22:
> geo-utils.h:10:37: error: clutter-gtk/clutter-gtk.h: No such file or directory
> contacts-map.c: In function ‘show_map_general’:
> contacts-map.c:194: warning: implicit declaration of function
> ‘champlain_layer_show_all_markers’

The champlain function has a note "since 0.4", thus I removed a check for champlain-gtk-0.3 and bumped minimum version requirement to 0.4.

Seeing the clutter-gtk issue above, shouldn't the configure check also for the right clutter-gtk version, to be sure it's the version which actually has that available in sources? As that mine doesn't have such include file.

The good news is that the code seems quite fine, I only changed few minor coding style issues to better match those supposed-to-be-used in evolution, and few minor glitches (like using glib types instead of C types (double=>gdouble), and prefer also GLib functions, malloc=>g_malloc, free=>g_free). I also added new files to po/POTFILES.in for translations.

I wasn't able to test this further, so I removed plugin from the list of experimental plugins meanwhile. It's just question of putting it back as soon as the above will be fixed. I'm committing this to master sources.

It would be nice to have this sorted out before Monday release, thus it can be available for more people sooner.

One question: did I get it right that this is trying to get all contacts from an address book and show locations for all of them on some map? You know, thinking of unbrowseable LDAP or Exchange (GAL) address books, or even browseable, but large remote address books makes me wonder how the plugin handles it. It can take some time to fetch them all from a server.
Comment 11 Milan Crha 2009-11-26 21:10:04 UTC
Created commit 93b1578 in evo master (before 2.29.3, as it's disabled now)
Comment 12 Cedric Bosdonnat 2009-11-27 08:49:00 UTC
(In reply to comment #10)
> The champlain function has a note "since 0.4", thus I removed a check for
> champlain-gtk-0.3 and bumped minimum version requirement to 0.4.

Thanks for spotting that.

> Seeing the clutter-gtk issue above, shouldn't the configure check also for the
> right clutter-gtk version, to be sure it's the version which actually has that
> available in sources? As that mine doesn't have such include file.

I'm not really good at writing configure files: any help is more than welcomed.

> It would be nice to have this sorted out before Monday release, thus it can be
> available for more people sooner.

It will be hard for me to fix it before Monday, but I can try.

> One question: did I get it right that this is trying to get all contacts from
> an address book and show locations for all of them on some map? You know,
> thinking of unbrowseable LDAP or Exchange (GAL) address books, or even
> browseable, but large remote address books makes me wonder how the plugin
> handles it. It can take some time to fetch them all from a server.

You got it right. Then it may be interesting to restrict the features to the local addressbooks? (or at least to the browsable ones). What would be the recommended way to solve this issue?
Comment 13 Milan Crha 2009-11-27 10:47:35 UTC
(In reply to comment #12)
> I'm not really good at writing configure files: any help is more than welcomed.

I do not think so, you wrote the configure part quite well. One possible way to solve this is to determine since which version the clutter-gtk is providing its single include file and add a check for that version same as you did for those other new requirements. After that we can make it enabled in experimental plugins.

> > One question: did I get it right that this is trying to get all contacts from
> > an address book and show locations for all of them on some map? You know,
> > thinking of unbrowseable LDAP or Exchange (GAL) address books, or even
> > browseable, but large remote address books makes me wonder how the plugin
> > handles it. It can take some time to fetch them all from a server.
> 
> You got it right. Then it may be interesting to restrict the features to the
> local addressbooks? (or at least to the browsable ones). What would be the
> recommended way to solve this issue?

We can sort out this later. For example, it would also be usable, from my point of view, have an option to click "show me this one on the map only", which will work for contacts with necessary information filled. You can see than in the preview panel too already, but it points out to the browser, if I recall correctly. There are no binding to preview for plugins at the moment, I think.
Comment 14 Cedric Bosdonnat 2009-11-27 14:15:25 UTC
(In reply to comment #13)
> I do not think so, you wrote the configure part quite well. One possible way to
> solve this is to determine since which version the clutter-gtk is providing its
> single include file and add a check for that version same as you did for those
> other new requirements. After that we can make it enabled in experimental
> plugins.

ok, the minimum version of clutter-gtk containing that file is 0.9.0.

> We can sort out this later. For example, it would also be usable, from my point
> of view, have an option to click "show me this one on the map only", which will
> work for contacts with necessary information filled. You can see than in the
> preview panel too already, but it points out to the browser, if I recall
> correctly. There are no binding to preview for plugins at the moment, I think.

Hum... I don't understand completely what you mean here.
Comment 15 Cedric Bosdonnat 2009-11-27 14:38:12 UTC
Created attachment 148596 [details] [review]
Patch adding the Clutter-gtk checks
Comment 16 Pierre-Luc Beaudoin 2009-11-27 14:40:28 UTC
I'd rather recommend checking for clutter-gtk-0.10 as this is the stable version of the -0.9 version.  Odd version numbers in Clutter are development releases.
Comment 17 Milan Crha 2009-11-30 10:51:57 UTC
Created commit 2ffe981 in evo master (2.29.3+) based on the above patch. It isn't the same, as some things changes meanwhile [1].

[1] http://git.gnome.org/cgit/evolution/commit/?id=447a71143fe9ced006da874853bc83aba2e246da

(In reply to comment #14)
> Hum... I don't understand completely what you mean here.

I meant that there will be opened separate bugs with improvement requests and such against your new plugin in time, to not fix all the things in this bug, which I'm closing now.
Comment 18 Milan Crha 2009-11-30 10:53:33 UTC
(In reply to comment #16)
> I'd rather recommend checking for clutter-gtk-0.10 as this is the stable
> version of the -0.9 version.  Odd version numbers in Clutter are development
> releases.

I changed this too.
Comment 19 Akhil Laddha 2010-02-23 06:06:29 UTC
*** Bug 200040 has been marked as a duplicate of this bug. ***
Comment 20 Bruce Cowan 2010-02-28 17:08:15 UTC
*** Bug 509051 has been marked as a duplicate of this bug. ***
Comment 21 André Klapper 2012-01-27 17:27:43 UTC
*** Bug 394430 has been marked as a duplicate of this bug. ***