<freemangordon>
if you receive roster contact, you may want to call osso_abook_aggregator_resolve_master_contacts() and use some properties from there (like name, avatar, $whatever)
<dsc_>
disregard, whether its a master contact or not does not matter - I just follow whatever _get_uid() returns
<dsc_>
unless you suggest to specifically find associated master contacts
<dsc_>
I think currently it is OK, _get_uid() will return the contact, it can be a master contact, or a tmp contact
<dsc_>
from the perspective of conversations its not important
<freemangordon>
right, but my point was about "contacts-change" callback
<freemangordon>
there you should check which contact do you get
<freemangordon>
and if it is roster contact, to try to find master contact for it and get avatar and name of the *master* contact
<dsc_>
alright, will do
<freemangordon>
why, you may ask? imagine, you have your mum as contact in facebook. you have it in your addressbook as 'mum' with phone number, email, etc. she sends you a message in messenger, but her facebook name is not 'mum', obviously.
<freemangordon>
so, in conversations chat you will see her facebook name, instead of 'mum'
<freemangordon>
if you use roster contact to retrieve the name that is
<freemangordon>
but, if you resolve roster contact to master contact, then you will use the correct name
<freemangordon>
same for avatar, etc
<freemangordon>
agree?
<dsc_>
yes
<freemangordon>
ok, good
<dsc_>
freemangordon: the creation of a master/roster contact, is that done through merging in address book?
<dsc_>
I tried it, but `osso_abook_contact_is_roster_contact` returns 0 on that contact
apac has joined #maemo-leste
LIERO has joined #maemo-leste
<dsc_>
I have overriden some attributes like avatar and display name through the address book, e.g. 'mum' (while the XMPP nickname is different)
<dsc_>
even though I am not resolving a master contact through `osso_abook_aggregator_resolve_master_contacts`, the attributes *are* queried properly
<freemangordon>
dsc_: so, abook already does what has to be done for you :)
<dsc_>
right
<dsc_>
ok cool
<freemangordon>
mhm
<dsc_>
and even though the abook uid changed (it now starts with pas-*), I was still able to query properly through the previous uid (as that was what was previously stored in rtcom)
<dsc_>
so seems to work fine this way
<dsc_>
when we receive the next message, this new uid will be registered in rtcom, etc.
<freemangordon>
dsc_: and I assume you shaved lots of code :)
<freemangordon>
yes
<dsc_>
yes shaving is still ongoing
<dsc_>
but I am still caching things
<freemangordon>
and also, IIRC, abook will migrate temp uids
<freemangordon>
to mater uid
<freemangordon>
but I am not 100% sure about that
<dsc_>
ok
<freemangordon>
we shall confirm
<freemangordon>
but that's easy and not really that important
pere has quit [Ping timeout: 248 seconds]
apac has quit [Ping timeout: 248 seconds]
vectis has joined #maemo-leste
apac has joined #maemo-leste
Livio_ has joined #maemo-leste
Livio has quit [Ping timeout: 272 seconds]
ceene has quit [Ping timeout: 260 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
Pali has joined #maemo-leste
_fab has quit [Quit: _fab]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
pere has joined #maemo-leste
norly_ has quit [Quit: Leaving.]
Anasko has joined #maemo-leste
norly has joined #maemo-leste
Pali has quit [Quit: Pali]
Gary_M has joined #maemo-leste
Guest58 has joined #maemo-leste
arno11 has joined #maemo-leste
Guest58 has quit [Quit: Client closed]
Livio_ has quit [Quit: leaving]
xmn has quit [Quit: Leaving]
akossh has quit [Quit: Leaving.]
vectis has quit [Ping timeout: 250 seconds]
kiva has joined #maemo-leste
<kiva>
Wizzup: yes that will be good idea to have at least some program to register as image handler..and Mihphoto at least works on N900-D4-PP, btw Mihphoto does not show up in App.Manager in PP?