Closed kenny3794 closed 9 years ago
Hi,
Did you previously have the entire list of contacts or only the 75 ones with the proper names? Previously I was discarding the contacts for who I don't have a full name. This was a bad idea, and people where having issues with it. For those contacts, I am now only showing the jabber id.
I will look in the other fields of the vcard if I can find meaningful information to display rather than the jabber id.
As for the speed, I changed my way of dealing with images: now, it not the headless but the view who is dealing with it. This should have decrease the load of the headless and hopefully solved the memory leaks.
I was looking at the code and I see the change you're referencing regarding the jabber ID. Previously I had all my contacts, so I'm a bit perplexed.
I was looking at Hg10Service and I see that line 608 of XMPPService.cpp calls the SetFullName function with the Jabber ID, but I don't see where it changes the full name from the Jabber ID to the full name received from the jabber service. I'm suspecting I'm just missing it...
This one have a different purpose, it is for the case of a contact which do not have a google email address. For example, a yahoo one. In that case, I saw that I get information about the presence of the contact, but the roaster did not provide any information about the contact.
So in the headless, same file, line 503, if I get the information about the presence of a contact for which I do not have a vcard, then I create an empty one with just the jabber id. And that is what you can see line 608.
But I think I should have a look in the view (Hg10), file XMPPService, lines 511-517. There, I am defining the name of the contact that you will list in the contact list based on the availability of a full name, or a nickname. If none is available, then I set the name as the jabber id. I should probably look at the other fields.
But I need to check former version of the code to check what I did. Because I am not sure that I ever used the other fields than fullname and nickname.
Alternatively, I can see there is no mutex around it, so if I try to write an empty vcard and a non-empty one at the same time, I will run into trouble. That could be another explanation...
Hi again,
Could you try this one: https://github.com/amonchakai/Hg10/releases/tag/1.3
See if this help?
Thanks.
I apologize for taking a day to respond. I still see the same issue. I did an update to .169, then I cleared stored contact information. Upon a contact list refresh, the results are the same.
Hi,
In this last version I added the mutex to avoid conflict when writing the vcard, and I also tried to look at the other field. But apparently, that is not it...
Could you try this one: https://github.com/amonchakai/Hg10/releases/tag/1.3
And with this new version, if you hit "refresh list" and restart the UI, it may improve the loading of the contacts info.
Thanks
Thanks. This appeared to have fixed it for all but 3 contacts. Those 3 contacts might be individuals who are no longer in the system, but I haven't removed yet. As a note, it did take a while for the full list of individual names to populate.
Hi,
I am glad it is solved! Apparently it was because I was receiving information about the status of the contacts before even getting the list of contacts. And I did not anticipated such case.
Regarding the performance issue, I am afraid I cannot do much about it. You have a really long list of contact. I will see if I can think of something to improve that, but cannot really promise anything.
The initial list load time is not a concern. Once loaded, it should be good to go. Much Thanks!
For many of my contacts, the user's name is not loading. I use this with Google Apps for Business and have over 200 colleagues as contacts. For most contacts, Hg10 only shows an obscure email address for example: 3p8arraqzf0hc2qx0tivla8y54@public.talk.google.com
About 75 of my contacts have proper names. On a side note, previously, to load the contact list took forever and had regular disconnects with the Hg10 headless server. I no longer see this, so that is a noticeable improvement.