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 713347 - Display avatars from gnome-contacts/GOA via libfolks
Display avatars from gnome-contacts/GOA via libfolks
Status: RESOLVED DUPLICATE of bug 714160
Product: geary
Classification: Other
Component: contacts
unspecified
Other All
: High enhancement
: 0.13.0
Assigned To: Geary Maintainers
Geary Maintainers
: 738347 (view as bug list)
Depends on:
Blocks: 771642 791187
 
 
Reported: 2012-04-13 09:50 UTC by Adam Dingle
Modified: 2018-10-07 03:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0002-Possible-approach-to-libfolks-avatars.diff (4.85 KB, application/octet-stream)
2012-04-21 15:07 UTC, Geary Maintainers
Details

Description Charles Lindsay 2013-11-21 20:20:06 UTC


---- Reported by adam@yorba.org 2012-04-13 14:50:00 -0700 ----

Original Redmine bug id: 5057
Original URL: http://redmine.yorba.org/issues/5057
Searchable id: yorba-bug-5057
Original author: Adam Dingle
Original description:

None

Related issues:
related to geary - Feature #5058: display avatars from Gravatar (Fixed)



---- Additional Comments From geary-maint@gnome.bugs 2013-07-08 15:02:00 -0700 ----

### History

####

#1

Updated by Christian Dywan over 1 year ago

  * **File** 0002-Possible-approach-to-libfolks-avatars.diff added

Here's a possible approach to loading avatars from libfolks. Unfortunately
there are 2 problems: on my system I never get any avatars - I wrote the code
the way I'd expect it to make sense. And GLib.InputStream.read_all is unusable
without adding "out" in the vapi - that's why that code section's uncommented.

Maybe somebody wants to try it out. Don't mind the lambda and printfs, this is
for testing.

####

#2

Updated by Adam Dingle over 1 year ago

Christian: if that function is incorrect in the vapi file, could you file a
Vala bug for that (if there isn't one already)?

####

#3

Updated by Jim Nelson over 1 year ago

Christian -- I don't think this is a VAPI problem. read_all() doesn't return a
reference to a buffer, rather it fills the buffer supplied by the caller with
data from the stream. Thus, your code should look something like this:

`uint8[] buffer = new uint8[4096];

size_t bytes_read;

stream.read_all(buffer, out bytes_read, null);

`

I'm doing this off the top of my head, so this might require tweaking.

####

#4

Updated by Adam Dingle over 1 year ago

  * **Target version** deleted (<strike>_0.1_</strike>)

####

#5

Updated by Jim Nelson 10 months ago

  * **Category** set to _contacts_

####

#6

Updated by Jim Nelson 5 months ago

  * **Assignee** deleted (<strike>_Christian Dywan_</strike>)



--- Bug imported by chaz@yorba.org 2013-11-21 20:20 UTC  ---

This bug was previously known as _bug_ 5057 at http://redmine.yorba.org/show_bug.cgi?id=5057
Imported an attachment (id=260658)

Unknown version " in product geary. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product geary. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution 

Comment 1 Michael Gratton 2016-09-19 04:49:58 UTC
*** Bug 738347 has been marked as a duplicate of this bug. ***
Comment 2 Gautier Pelloux-Prayer 2017-02-16 21:41:08 UTC
Michael: is there any plans about this particular bug (existing work somewhere, etc.) and/or it has to be started from scratch?
Comment 3 Michael Gratton 2017-02-16 22:54:41 UTC
Aside from the patch above, there's also a folks-related patch in Bug 714160. Both are pretty old and may no longer cleanly apply, but may provide some inspiration? Similar to that bug, we would want to query for and use an avatar from folks first, then fall back to the existing Gravatar impl if none were found.

An ideal implementation of this (or 714160) would add some kind of folks service that is managed by the controller and that handles loading folks backends and providing access to them, so both this and the autocomplete can share that code.

I'd like to get this in to 0.13, since it would be good to finally improve desktop integration a bit.
Comment 4 Niels De Graef 2017-02-17 01:19:08 UTC
I once took a quick try at this some time ago, and things have changed in libfolks since then (for the better). From what I gathered at that time, this is a possible step plan:

1) Create our own Folks.Backend(s), which loads the Geary-specific contacts (i.e. those that we found as recipients or senders of emails). This would probably require some transforming of Geary.ContactStore. A Geary.Contact would then be a Folks.Persona subclass.

2) Create a BackendStore, add our own Backend(s) and enable the others we would like.

3) Add a ContactManager/ContactService/... class (whatever you want to call it), which will be used during the whole lifetime of the app.

4) In the ContactManager, initialize a Folks.IndividualAggregator (using the IndividualAggregator.dup_with_backend_store() method) and use it to list contacts where needed.

5) For searches, we can use the SearchView class.
Comment 5 Michael Gratton 2017-02-17 01:53:01 UTC
Oh, implementing our own Folks.Backend is an interesting thought. I guess it would give us a single API for querying contacts, which might be useful for Bug 714160. Looks like a lot of work though.

Since this is about loading avatars, here we only need (3), right? And that would presumably be responsible for doing (2)?

I think ideally would already be a Gravatar folks backend, if so we could simply  use the folks API for avatars as well. There's an existing bug for that (Bug 655116) but that depends on some more infrastructure work in folks (Bug 660299).
Comment 6 Michael Gratton 2018-10-07 03:11:20 UTC
Marking this as dup of bug 714160 since this will be handled under one ticket over at https://gitlab.gnome.org/GNOME/geary/issues/133

*** This bug has been marked as a duplicate of bug 714160 ***