Community
Participate
Working Groups
We already have some of this code in the GitHub code base. https://github.com/eclipse/egit-github/blob/master/org.eclipse.mylyn.github.ui/src/org/eclipse/mylyn/github/ui/internal/AvatarStore.java See Avatar* related classes. It would be nice to have something in the Mylyn Commons UI code base to do this work.
I created a general purpose Gravatar Eclipse plug-in last month: https://github.com/kevinsawicki/eclipse-avatar I would be more than happy to contribute it to Eclipse/Mylyn. It supports gravatar lookup by id or e-mail address and maintains a persistent store of cached images.
Chirs, Kevin: That sounds great. Chris' blog post on the GitHub editor reminded me that we had shelved this for too long, and that Gravatar now seems to be enough of a clear winer with open source portals to use their service for identitiy. We can then make API so that third parties can plug in their own identitiy services, or use an ALM server's identity service. Fyi, we have some related itentity work happening on the Reviews side, which will also provide API to commons. Kevin: So you're willing to contribute this to Mylyn Commons? If so, Steffen can coordinate with you on the contribution. Steffen: Is it still feasible to take contributions for Indigo? I think this would be nice to have for Indigo and seems quite straightforward to integrate.
Yes, I'm willing to contribute this to Mylyn Commons.
I would take some time to think about how the UI should be displayed. Should it be like what is done with the GitHub related tooling? Or should we have a hover popup when hovering over someone's name via a PopupDialog? There are a few approaches, not sure which one would be the cleanest yet.
Chris: We discussed this briefly on today's Mylyn call. My sense is that what we can do immediately is to place a person's image on the upper-right of the task editor like with GitHub, since we have real-estate available. I think we should avoid doing the left for now as many connectors use that for priority or other status icons. Then we can consider where else in the UI we can leverage this. The tooltips that you suggest are a good candidate, and prevent turning the task editor into a visually-overloaded TweetDeck. Comments tend to have some free horizontal space on wider displays, so we may actually get away with showing an image on every unfolded comment. Or we could add a list of images to the Collaborators/CC list, along the lines of Outlook 2010 (http://www.grouppolicy.biz/wp-content/uploads/2010/02/Outlook2010_PeopleView_thumb.jpg) though this may imply creating more API, as that part of the UI is often customized by connectors. Kevin: Great to hear that you're willing to contribute. Steffen should be able to do some of the task editor pieces. I looked at your implementation and given the conciseness of the implementation, it looks like we can get away without doing a CQ for this if you submit a few 250 line patches and we wire up the pieces after the fact. If you're interested in ongoing contributions of this sort this would also help move you on the way of commit rights to Mylyn Commons. So whose image should we show on the upper-right? In email tools it always seems to be the "from" person. But on a task/bug/issue, there's a question of whether the assignee is more appropriate than the Reporter.
Should I just post the patches to commons.ui plug-in in a new package?
Yes, that sounds good. Steffen may have some additional feedback on how we name the package. I'm thinking org.eclipse.commons.mylyn.identity as the API package and org.eclipse.mylyn.commons.identity.gravatar as the integration. We will probably want to use org.eclipse.mylyn.commons.repositories so that we get all the nice UI for storing and managing credentials.
Created attachment 193920 [details] Gravatar model class Adding first patch
Created attachment 193921 [details] Utilities and constants Adding second patch
Created attachment 193922 [details] Interfaces Adding third patch
Created attachment 193923 [details] Interfaces Second interfaces patch.
Created attachment 193924 [details] messages and properties Adding fourth patch
Created attachment 193925 [details] Gravatar model class
Created attachment 193926 [details] Utilities and constants
Created attachment 193927 [details] Interfaces
Created attachment 193928 [details] Gravatar store
I have attached 5 patches to be applied in the following order: * Gravatar model class * Utilities and constants * Interfaces * messages and properties * Gravatar store
Created attachment 193940 [details] UI patch with image and display callback Adding UI patch
Kevin: Apologies, I just realized that Steffen has started vacation. Rob: If you can give this a quick review please go ahead, otherwise let's wait until Steffen is back on Monday.
Nice work! Things to consider: * Connectors may pass back gravatar hashes in their data model, so the API should support retrieving images by the email address and alternatively the Gravatar hash, depending on what's available * The patches grab the default Gravatar image size, and resize it on the client. Gravatar supports requesting a specific image size, so we may want to consider passing the image size in when requesting the image data.
Great patches, Kevin! I have applied the core portion (o.e.m.commons.identity) to cvs head and created bug 345826 to track the UI integration for the task editor.
Created attachment 195674 [details] screenshot
Excellent, great stuff guys!
