mp107 has quit [Quit: Ping timeout (120 seconds)]
mp107 has joined #maemo-leste
xmn has quit [Ping timeout: 245 seconds]
xmn_ has joined #maemo-leste
xmn_ is now known as xmn
sixwheeledbeast has quit [Server closed connection]
sixwheeledbeast has joined #maemo-leste
xmn has quit [Ping timeout: 248 seconds]
Daanct12 has joined #maemo-leste
sicelo has quit [Server closed connection]
sicelo has joined #maemo-leste
xmn has joined #maemo-leste
_fab has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
<dsc_> small quality of life feature, show which accounts are online: https://plak.infrapuin.nl/selif/fhv3deyi.png
<freemangordon> dsc_: I think this duplicates accounts status menu item
<kittysol> dsc_: i think i would find that quite useful
<dsc_> freemangordon: it does yes
<dsc_> freemangordon: btw, I also fixed the overview table where previously it would cut-off text, in -devel
<freemangordon> dsc_: do you update status on-the-fly?
<dsc_> freemangordon: yes
<freemangordon> ok
<dsc_> kittysol: did you see my messages about Matrix? I tested it yesterday
<kittysol> oh let me see if i have them, i think my bouncer did a funny
<freemangordon> dsc_: SMS is offline?
<kittysol> ah ill need to go on my other computer to see them
<dsc_> freemangordon: hmm yes good point, ring/tel/account0 reports ✓ available
<dsc_> will investigate
<freemangordon> dsc_: I admit I am not sure its conversations job to care about accounts, but well...
<dsc_> it was easy to add and helps a lot in terms of UX
<freemangordon> ok
<freemangordon> I am just sharing my gut feeling. also, there is always a risk conversations and status menu to show different things
<dsc_> in the case of SMS, the CM is 'ring' and Tp reports this protocol as being 'offline' - it does have a connection to the CM but this onlineness is what the CM reports
<dsc_> so thats correct
<dsc_> (this is in the VM)
<dsc_> suppose I could decide to always consider this 'online' though when we have that CM active
<dsc_> 'online' with SMS is a bit strange and probably not implemented like the other CMs
<dsc_> I was just following what the CM reports
<dsc_> ill do that
<sicelo> looks like the first row is clickable? what does clicking do or show?
<sicelo> then, Telegram looks too prominent.
<sicelo> potential issue when many accounts are configured - the menu may end up unwieldy
<dsc_> sicelo: its for filtering the overview
<dsc_> based on protocol
xmn has quit [Remote host closed the connection]
xmn has joined #maemo-leste
_fab has quit [Quit: _fab]
<dsc_> regarding previews
<dsc_> i dont think I showed it yet
<dsc_> in this case, conversations is configured to first ask the user to preview it, but it can be fully automatic too (or completely disabled)
<dsc_> this results in
<dsc_> it shows the download progress as well
<dsc_> these results can be clicked, e.g. links will open Jib (after asking the user)
<dsc_> and clicking the image will result in a built-in image viewer with zoom/pan
<dsc_> try it out, its in the repos :))
Livio has joined #maemo-leste
<dsc_> freemangordon: maybe you know https://git.maemo.org/leste/osso-abook/issues/3
pere has quit [Ping timeout: 248 seconds]
_fab has joined #maemo-leste
akossh has joined #maemo-leste
<Wizzup> dsc_: fwiw the rtcom status applet just doesn't show the tp ring account
<Wizzup> but we can't do that here from a UX perspective because we want to filter by sms
Livio has quit [Ping timeout: 272 seconds]
<dsc_> Wizzup: right
<sicelo> dsc_: filtering by the overview: what is overview? sorry for dumb question
joerg has quit [Ping timeout: 258 seconds]
joerg has joined #maemo-leste
<kittysol> dsc_: excuse my ignorance but when you say its in the repos will i just be able to update communications on a daedalus image?
<sicelo> that's what it means, yes
<kittysol> thank you just didnt know if i had to switch to a devel branch or something
pere has joined #maemo-leste
<dsc_> sorry I do everyhthing via terminal
<dsc_> I think you can use the update application thing yes
<Wizzup> I don't think HAM will update conversations currently
<dsc_> sicelo: the overview of chat messages
<kittysol> oh yeah ill do it through terminal anyway i just didnt know if i had to add a repo or anything
<dsc_> the initial main screen
<Wizzup> g2g
<dsc_> kittysol: devel repo not necessary
<sicelo> ah, i see
FANTOM has quit [Ping timeout: 248 seconds]
Smatkovi has joined #maemo-leste
<Smatkovi> strange. somehow the n950 doesn't like soft reboots. it just hangs and wants that i press the powerbutton
<Smatkovi> that's why ubiboot isn't working and also moslo dualboot isn't working
<Smatkovi> i tried to delete all rd flags with flasher, but still the same behaivour
<Smatkovi> has someone of you heard of such behaivour?
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
FANTOM has joined #maemo-leste
Livio has joined #maemo-leste
FANTOM has quit [Ping timeout: 248 seconds]
pere has quit [Ping timeout: 258 seconds]
FANTOM has joined #maemo-leste
<freemangordon> dsc_: IIRC 'contact' is really the id in 'removed' handler, try with const gchar *contact = *contacts;
<freemangordon> also, I don;t think you shall connect to both aggregator and roster signals
<dsc_> yes
<dsc_> freemangordon: what kind of 'id' ? int?
<freemangordon> const gchar *contact = *contacts;
<dsc_> ah
<freemangordon> const gchar *id = *contacts;
<dsc_> we shall try (gchar)(uintptr_t)(*contacts)
<freemangordon> what?
<dsc_> what you suggested does not work, I'm not sure how to cast properly
<dsc_> its an error
<dsc_> so I shall try this other thing
<dsc_> :P
<freemangordon> dsc_: your callback signature is wrong
<dsc_> ah ok, thanks
<freemangordon> void contacts_removed_cb(OssoABookRoster *roster, const gchar **uids, gpointer data)
<dsc_> yes
<freemangordon> also, it is not gchar, but gchar *
<dsc_> it worked thanks
<freemangordon> seems the documentation is wrong
pere has joined #maemo-leste
<dsc_> heh'
<dsc_> so do you know what this id is btw
<freemangordon> dsc_: BTW, why do you care about contacts management?
<dsc_> osso-abook-tmc257
<freemangordon> everything is (should) already implemented in addressbook, what are you trying to reinvent?
<freemangordon> osso-abook-tmc257 is temporary uid, seems this is some online account addressbook
<freemangordon> perhaps you can get master uid from it
<dsc_> so im keeping state on conversations side of some abook things
<dsc_> and using the various signals to update this state
<dsc_> with state I mean a roster
<dsc_> I have not looked at this abook code for a while but I'm guessing its because 1) I was having trouble with the abook interface to query for things 2) performance
<Wizzup> I think osso-abook is in-process
<Wizzup> well, the abook lib
<Wizzup> so not sure what the performance hit would be, there's no ipc yeah?
<dsc_> Qt asking abook various things, and the lib iterating the whole roster each time
<dsc_> and then Wizzup gets a frozen conversations when an account goes online/offline ;)
<dsc_> osso-abook is not a fun library to interface with
<dsc_> but right now I want to focus on this ID
<Wizzup> I can't think of any C library that is fun to interface with ;)
<Wizzup> we'll get our AI overlords to rewrite everything in rust for us
<dsc_> no its fine but we are in Qt not gtk
<dsc_> this adds another layer of translation
<dsc_> both eventloops, both emit signals, gtk signals need to go to Qt etc.
<dsc_> i dont have an issue with C :P
<dsc_> s/gtk/glib/g
<dsc_> and another issue while im ranting
<dsc_> sometimes its hard to map my UIDs (from Tp, rtcom) to what is in abook
<dsc_> ^-- a bit crazy imo
<dsc_> I only want some contact attributes ya know :P
<dsc_> anyway yes `osso-abook-tmc257` is not the right uid for me
<dsc_> is there a way to get such a tmp. uid from an OssoABookContact* ?
<dsc_> this clears the table using this uid
<dsc_> so it must be set somewhere
Smatkovi1 has joined #maemo-leste
<Smatkovi1> wow
<Smatkovi1> sudo 0xFFFF -F no-force-power-key
<Smatkovi1> that did the trick, now i can use ubiboot :D
kiva has joined #maemo-leste
<Smatkovi1> oh, i only see kernel messages from maemo-leste, harmattan still shows a black screen :/
<Smatkovi1> maybe the partition for maemo is better with ubiboot
<kiva> does it look like that screen backlight is on?
<Smatkovi1> yes the backlight stays on
<Smatkovi1> the leste kernel didn't find the partition so it turned off
<kiva> so ubiboot might be better (I dont know really)
pere has quit [Ping timeout: 260 seconds]
<kiva> wait..from elinux page: "Watch the screen. It will go dark. If it blinks, it is a good sign. You may want to check with flashlight, maybe there's almost invisible text there. "
<Smatkovi1> so for meego the backlight stays on forever, but nothing else for maemo i think it cannot find the partition 4 and turns off
<Smatkovi1> yes after trying to boot maemo i only have to press the powerbutton briefly and it turns on, so it turned off
<Smatkovi1> yes that's the way i'm trying it right now
kiva has quit [Quit: killing zombies]
_fab has quit [Quit: _fab]
<freemangordon> dsc_: I there is no performance hit of using abook, as it already does everything behind the scenes, no matter if you use it or not. So, instead of reinventing the wheel, please share what exactly your issues with abook are and I'll try to help
<freemangordon> implementing in qt what abook already does in glib does not make sense to me
pere has joined #maemo-leste
<Wizzup> freemangordon: I think we need the contact selector widget/popup
<Wizzup> that would be a great addition
<Wizzup> and then 'new contact' and 'merge with contact'
<dsc_> freemangordon: not reinventing, im merely constructing a wheel because I have offered none
<dsc_> because I was not offered one*
<dsc_> we can go into a lengthy redesign of the API if you want
<dsc_> from conversations I just need simple things like presence, avatar, vcard attrs
<dsc_> so preferably this API has such functions that take a UID, thats it :P
<Wizzup> if we change the api then we have also have to change all other maemo sw fwiw
<freemangordon> dsc_: and you already have those
<dsc_> i do not
<freemangordon> which one is missing?
<dsc_> its 500 lines
<dsc_> I think it could be 20 lines in total
<dsc_> if those functions existed
<dsc_> why do I need to loop contacts with an aggregator
<dsc_> I already have some sort of UID from either tp or rtcom
<freemangordon> do you really ask me if I have ever seen abook code?
<dsc_> to get ... an avatar
<dsc_> instead it could be `gchar* path = get_avatar(uid)`
<dsc_> (just an example)
<dsc_> note that most of these functions call `get_im_contact`
<dsc_> which iterates *all* contacts
<freemangordon> why?
<dsc_> to get the correct `OssoABookContact* contact`
<freemangordon> there is no better function?
<dsc_> right
<dsc_> maybe there is
<freemangordon> I bet on that
<dsc_> who knows
<freemangordon> me?
<dsc_> sure, but preferably this API doesnt require handholding from fmg
<dsc_> from a coding perspective
<freemangordon> yes, there is documentation
<freemangordon> and source code also
<dsc_> Qt likes to spam all kind of calls in some scenarios, which means such abook functions get called often, and you can see how this iteration becomes problematic
<freemangordon> sure
<dsc_> in addition I recall Telegram CM being really spammy
<freemangordon> it makes no sense to iterate over and over
<dsc_> account comes online = avatar-changed notify for that whole roster
<freemangordon> but, I am sure there is a better function you can use
<freemangordon> no, you need to wait for contact changes
<freemangordon> IIRC
<dsc_> yes contact-changed actually
<dsc_> or maybe both
<freemangordon> WTYM "whole roster"?
<freemangordon> in 'contact changed' you get only changed contacts, as OssoABookContact*
<dsc_> ok so regarding my use of this singleton `ROSTER`
<dsc_> im fine with getting rid of it
<dsc_> but please, you'll have to accommodate any issues that arise from that
<freemangordon> still, I don't understand what you want to achieve and what abook lacks
<dsc_> I want to retreive attributes from a contact
<dsc_> given an UID
<dsc_> in the least possible amount of code
<freemangordon> ok, lemme see
<freemangordon> by attributes you mean? avatar? presence?
<dsc_> we can decide what this UID must be
<freemangordon> what else?
<dsc_> subscribed, published state
<freemangordon> ok
<dsc_> osso_abook_contact_get_blocked et al
<dsc_> display name
<freemangordon> but again, we have 2 types of uids - master UID (that's the one in EDS) and roster UID
<freemangordon> I assume you want master UID, right?
<freemangordon> contact for master UID I mean
<freemangordon> and you have roster uid I assume
<dsc_> I dont know.
<dsc_> I have UIDs from tp
<freemangordon> no, you dont; have UID from tp
<dsc_> const QString &local_uid, // e.g idle/irc/myself
<dsc_> const QString &remote_uid, // e.g cool_username (counterparty)
<dsc_> const QString &group_uid, // e.g idle/irc/myself-##maemotest
<freemangordon> this is not UID
<dsc_> right, its rtcom jargon
<freemangordon> so, you have remote account
<freemangordon> correct?
<dsc_> im not sure. Tp might be offline but I still want to request things from abook
<dsc_> at that point I have data from either rtcom or the state db
<freemangordon> ok, but then what is the thing used to identify the remote account? remote_id?
<dsc_> yes moment
<dsc_> no the account is local_uid
<dsc_> remote_uid is the counterparty
<freemangordon> wait, it is 'your' account
<dsc_> with account I mean Tp account
<dsc_> yes
<freemangordon> so, you want properties of local or remote party?
<freemangordon> or both?
<dsc_> it would be nice if I could supply this:
<dsc_> - gabble/jabber/vm_40xmpp_2ekroket_2eio0
<dsc_> - gajim@xmpp.kroket.io
<freemangordon> those being? local_id and remote_id?
<freemangordon> or?
<dsc_> alltho on your end, I'm not sure if you can easily get such strings
<dsc_> yes
<Wizzup> don't we have osso_abook ids in rtcom somewhere?
<freemangordon> yes, we have them
<freemangordon> at least we should
<dsc_> on your end its
<dsc_> tp_account_get_cm_name
<dsc_> tp_connection_get_protocol_name
<dsc_> and maybe some more
<dsc_> but
<dsc_> this only works if there is a connection
<dsc_> and im not sure if this is saved in the ebook
<freemangordon> IIRC, Wizzup is right and you have abook master UID in rctom db
<freemangordon> *rtcom
<freemangordon> at least you should
<Wizzup> that might not be the case for transient contacts (i.e. only there when online)
<dsc_> freemangordon: looks like I'm saving an abook UID in rtcom yes
<dsc_> its manually constructed
<dsc_> const QString abook_uid = this->local_uid + "-" + remote_uid;
<freemangordon> hmm, I think it should not be like that
<Wizzup> dsc_: hm, I'm not sure if we should construct that manually, did I do that? :D
<dsc_> yes I'm also not sure if this is valid
<Wizzup> I think normally abook creates these
<freemangordon> I think what shall happen is, when you insert into rtcom db, you should put abook master uid there
<dsc_> upon new message, how to get that abook master uid?
<freemangordon> well, why on new message?
<freemangordon> you should get it on start of conversation
<freemangordon> I doubt it changes for the conversation lifetime
<freemangordon> lemme check what abook has to say about it
<dsc_> rtcom chat message insertion has `remote_ebook_uid` that we set
<freemangordon> what does it contain?
<dsc_> const QString abook_uid = this->local_uid + "-" + remote_uid;
<dsc_> this
<freemangordon> uhuh
<freemangordon> Wizzup: where did you get ^^^ from?
<dsc_> thats probably me
<dsc_> and I dont know
<freemangordon> :)
<freemangordon> ok, lemme check what we have in fremantle
<freemangordon> yes, I think we have uids
<Wizzup> looks like it was added by me in 98c27067c54b0d8eab9b82666d1210c4573e95f8
<Wizzup> but I wrote
<Wizzup> + abook_uid = osso_abook_contact_get_uid(contact);
<Wizzup> based on osso_abook_contact_get_display_name's result
<freemangordon> but iirc rtcom db has a special column for abook_id, no?
<Wizzup> this was added in this mega commit ebdb07e6a35a9d6134ff0bea2d5f1330e5122337
<freemangordon> return (const char *) e_contact_get_const (E_CONTACT (contact), E_CONTACT_UID);
<freemangordon> so, this is EDS contact ID
<freemangordon> which makes sense
<Wizzup> 'this was added' being the hardcoding of the ids
<freemangordon> dsc_: where is that code 'const QString abook_uid = this->local_uid + "-" + remote_uid;'?
<dsc_> tp.cpp
<dsc_> log_event() gets called from onMessageReceived
<dsc_> im not sure which column that is in el-v1.db
<dsc_> or table
<dsc_> im looking :P
<freemangordon> :)
<freemangordon> Wizzup: I don't see osso_abook_contact_get_uid() being called in current master
<Wizzup> it is not
<Wizzup> I was just saying that it was when I first added the code
<freemangordon> mhm
<dsc_> did fremantle have this format?
<freemangordon> no
<freemangordon> dsc_: you are logging invalid abook id, trying to find which commit broke that
<freemangordon> seems will have to bisect, gimme some time
<Wizzup> I provided the id ebdb07e6a35a9d6134ff0bea2d5f1330e5122337
<freemangordon> yes, I know
<freemangordon> but I am trying to find which commit removed it
Smatkovi1 has quit [Quit: Leaving.]
<dsc_> i think this
<dsc_> oh what broke it
<dsc_> nvm
<freemangordon> bisect will tell us
<dsc_> yes ebdb07e6a35a9d6134ff0bea2d5f1330e5122337 I think
<freemangordon> Wizzup: oh, sorry, I didn;t understand this is the 'bad' commit
<freemangordon> dsc_: so yeah, you should restore that code, and you'll get the id you need from rtcom db
<freemangordon> also, you can use the same functions to lookup for contact uid
<dsc_> alright
<freemangordon> also, see osso-abook-aggregator-lookup()
<freemangordon> and osso-abook-aggregator-resolve-master-contacts
<freemangordon> please ping me if anything else is missing
<freemangordon> you can also use osso_abook_contact_get_master_uids() and osso_abook_contact_get_account()
<dsc_> ok thanks
<dsc_> I will remove ROSTER and we'll fix anything that comes up
<freemangordon> see osso_abook_aggregator_find_contacts_for_im_contact()
<freemangordon> I am not sure what is ROSTER here, but yeah, removing code is always good :)
<freemangordon> dsc_: btw, while at it, I don;t think you should resolve TpAccount (or username or whatever remote id) on every incoming message
<freemangordon> doing it once on start of conversation and caching it should be enough
<dsc_> ok wait
<freemangordon> ?
<dsc_> nvm
<dsc_> what do you mean 'not resolve TpAccount on every incoming message'
<freemangordon> not call osso_abook_aggregator_find_contacts_for_im_contact() every time
<dsc_> yes thats what will happen
<dsc_> how can I stop that?
<freemangordon> just call it once in the conversation start
<freemangordon> and cache it in a map <remote_uid -> abook_uid>
<freemangordon> or somesuch, I may miss some details
<dsc_> you mean, iterate the roster on startup
<dsc_> right?
<freemangordon> why iterate?
<freemangordon> you have osso_abook_aggregator_find_contacts_for_im_contact()
<dsc_> not following
<dsc_> incoming message -> need to check counterparty abook_uid
<freemangordon> you need abook remote id, right?
<freemangordon> right
<dsc_> yes, I can cache it
<dsc_> but on startup?
<dsc_> how?
<freemangordon> conversation startup I mean
<dsc_> ah ok
<freemangordon> like, when you start a new chat
<dsc_> sure
<freemangordon> though, wait, lemme check how expensive that is (calling it every time)
<freemangordon> yeah, it is expensive
<freemangordon> so you'd better call it only once per chat attendee
<freemangordon> dsc_: one more thing: you can call osso_abook_aggregator_find_contacts_for_im_contact() with either TpAccount or id
<freemangordon> but I guess you don;t have TpAccount in tp-qt
<Wizzup> well we have a tp account but not the glib version of it
<freemangordon> mhm. though, iirc you can get glib version from tp version
<freemangordon> as tp-qt works on top of tp-glib
<dsc_> I'm not sure how that casting is done but yes I can probably reach it
<freemangordon> it should not be any faster
<freemangordon> if you have remote_id, that's perfectly fine to pass to osso_abook_aggregator_find_contacts_for_im_contact()
<dsc_> thx
<freemangordon> actually, *do not* pass TpAccount, unless you got it from some abook function
<freemangordon> also, if you want to do some advanced search, see osso_abook_aggregator_find_contacts_full()
<dsc_> ah yes I remember now
<dsc_> uhh
<freemangordon> hmm?
<dsc_> so initially tp.cpp used
<dsc_> contact = conv_abook_lookup_tel(remote_uid.toLocal8Bit());
<dsc_> abook_uid = osso_abook_contact_get_uid(contact);
<dsc_> (or _lookup_im)
<dsc_> but this remote_uid is not unique
<Wizzup> not unique in what sense?
<dsc_> its unique on a per CM basis
<dsc_> remote_uid = e.g cool_username (counterparty)
<dsc_> so with 2 CMs with 2 users with the same name
<Wizzup> right, but the lookup_tel in this case makes sure it's a telno (specific to a cm)
<Wizzup> I'm not sure what the other lookups look like
<dsc_> same process for im
<Wizzup> is it lookup_im ? does it take other params?
<freemangordon> no, it takes remote username
<freemangordon> or rather, account id
<dsc_> thats why this check is here currently
<dsc_> (disregard the manual construction of persistent uid, yes its hacky)
<Wizzup> yeah, account id and remote_id is enough
<dsc_> the point is that the aggregator can return multiple results
<dsc_> ok anyway not an issue
<dsc_> just pointing out this was broken in the initial code :P
<freemangordon> dsc_: so, lemme try to share what I know about those ids:
<freemangordon> we have 'master id', which is the contact id in EDS address book
<freemangordon> we also have 'roster id', which is the id in the roster, but again, it is EDS id
ungeskriptet has quit [Remote host closed the connection]
<freemangordon> we also have 'temporary id' which might be another name for 'roster id'
<freemangordon> so, when you want a contact, which exactly contact do you need?
<freemangordon> master or roster?
<freemangordon> I guess master, right?
ungeskriptet has joined #maemo-leste
<Wizzup> I think the point is that a remote_uid from rtcom is not enough to unique identify a contact
<freemangordon> at least in rtcom db you *must* put master uid
<dsc_> freemangordon: im about to use `osso_abook_contact_get_uid()` to get the UID and preferably this thing I use to communicate further with abook
<Wizzup> you can have a fmg on xmpp, fmg on irc, fmg on facebook, etc
<freemangordon> Wizzup: right
<Wizzup> remote_uid is not unique here -I think-
<Wizzup> but I'm also hazy on this
<freemangordon> it is not
<dsc_> Wizzup: its not an issue, I can obtain TpAccount from an OssoAbookContact*
<Wizzup> ok
<dsc_> and compare it to my own local_uid
<freemangordon> why do you need it?
<dsc_> to ensure the remote_uid is part of a specific Tp account
<freemangordon> wait, what? your local id has nothing to do with TpAccount of remote contact
<dsc_> sorry I mean the UID of the tp account
<dsc_> or ehm
<dsc_> just name
<freemangordon> this is already done
<freemangordon> sec
<dsc_> are we still talking about osso_abook_aggregator_find_contacts_for_im_contact() ?
<freemangordon> yes
<dsc_> yes, it takes remote_uid, and yes it could return several users (from different CMs) but I can match that somehow, right?
<freemangordon> CMs has nothing to do here
<freemangordon> it may return several *master* contacts
<dsc_> right
<freemangordon> as you may have your master contacts 'fmg1' and 'fmg2', both having the same irc im account
<freemangordon> it has nothing to do with TP, CMs or whatever
<freemangordon> this is your addressbook which may have duplicated data
<freemangordon> and I don't think you can tell which master contact is 'more correct'
<freemangordon> so, just take the first one and call it a day
<dsc_> no
<dsc_> i dont like that :P
<freemangordon> as your comparison will match it anyway
<freemangordon> do you understand the ^^^ example?
<dsc_> if someone is called 'bob' on IRC it will also match with another 'bob' from XMPP
<freemangordon> no
<dsc_> when I call osso_abook_aggregator_find_contacts_for_im_contact for bob
<dsc_> it will return 2 bobs
<freemangordon> no
<freemangordon> this is account name + CM name search
<freemangordon> or rather, match on vcard field
<dsc_> osso_abook_aggregator_find_contacts_for_im_contact(OssoABookAggregator *aggregator, const char *username, McAccount *account);
<dsc_> what is McAccount here?
<dsc_> how do I use it?
<freemangordon> TpAccount
<dsc_> ah ok
<freemangordon> *do not* use it
<freemangordon> as you don;t have TpAccount returned from abook
<dsc_> i dont understand sorry
<dsc_> I shall call osso_abook_aggregator_find_contacts_for_im_contact with only a username?
<dsc_> and in our case, this is remote_uid from Tp
<dsc_> which could be a common name
<freemangordon> TpAccount * is a pointer to TpAccount object
<freemangordon> no, you don;t call with username only
<freemangordon> you need the full bound name
<freemangordon> sec
joerg has quit [Excess Flood]
<freemangordon> dsc_: ok, how do you choose an account to start conversation with?
<freemangordon> or, this is not implemented currently
<dsc_> via abook (GUI) or "send message" (conversations GUI)
<Wizzup> send message in conversations gui is wip and needs abook ui
<Wizzup> basically via abook (GUI) is the current way
<Wizzup> (imo)
<freemangordon> but that's not a must to be able to get abook contact from account
joerg has joined #maemo-leste
<freemangordon> so, now you receive the remote account name from abook, right?
<dsc_> are you asking about the mechanism
<dsc_> how chats get started if initiated from abook?
<freemangordon> dsc_: scratch that, I think I know what shall be done
<dsc_> because in that case IIRC I just receive a new TextChannel out of nowhere
<freemangordon> so, you need to get TpPtotocol object somehow
<freemangordon> (or whatever it is called in tp-qt)
<freemangordon> you can get that from the remote account object
<Wizzup> dsc_: not out of nowhere, we register a handler to deal with textchannels :)
<freemangordon> dsc_: btw, do you have the remote_id example somehwere?
<Wizzup> you can get them from your db
<freemangordon> like, what does it look like?
<Wizzup> select distinct remote_uid from events;
<Wizzup> iirc
<freemangordon> no, I mean the remote_id that comes with 'new message' signal
<dsc_> auto remote_uid = message.sender()->id();
<freemangordon> mhm
<dsc_> from
<dsc_> const Tp::ReceivedMessage &message
<freemangordon> what does it look like?
<dsc_> 'bob'
<freemangordon> heh
<Wizzup> is it also without the fqdn on xmpp?
<Wizzup> I am not so sure if that is the case
<Wizzup> it should be with fqdn on xmpp
<freemangordon> it should be with some more data
<Wizzup> but thre is no uniqueness guarantee
<freemangordon> there is
<freemangordon> in terms of CM
<Wizzup> within the cm yes
<dsc_> in the case of XMPP it is e.g `gajim@xmpp.host.tld`
<freemangordon> ah, right
<dsc_> for IRC it is 'freemangordon'
<freemangordon> but you don;t have contacts for irc anyway
<freemangordon> so irc can be ignored here
<freemangordon> in irc you don;t have roster
<freemangordon> only rooms
<dsc_> you say I need a TpProtocol
<dsc_> but I dont think so?
<freemangordon> right, you don;t need
<dsc_> what about calling `osso_abook_aggregator_find_contacts_for_im_contact` with only an username
<dsc_> then iterate those OssoAbookContact*s
<dsc_> then grab TpAccount from that
<freemangordon> no, you should provide the full remote_id
<freemangordon> but only when you have a roster
<dsc_> yes im providing a full remote_id :P
<dsc_> 'bob'
<freemangordon> but CM is not roster capable
<freemangordon> so it makes no sense to try to resolve remote_id to contact if there is no roster
<dsc_> fair
<dsc_> and those that are roster capable will have fqdn
<dsc_> is what you are saying
<freemangordon> exactly
<dsc_> okl
<dsc_> so I lied
<freemangordon> also, I think you can use TpHandle
<freemangordon> but not sure that is useful for abook
<freemangordon> lied as in?
<dsc_> I said that there will be many bobs, but the bobs are fqdn unique
Daanct12 has quit [Quit: WeeChat 4.7.1]
<freemangordon> mhm
<freemangordon> this is what Wizzup said ^^^
<freemangordon> still, you may receive more then one master contact for bob@fqdn
<freemangordon> but you don;t care for anyone but the first
<dsc_> alright
<freemangordon> it is not your job do decide which is the correct bob
<freemangordon> *to
<freemangordon> we had 'contacts merger' in fremantle
<freemangordon> which was fixing exactly such issues
<freemangordon> shall port it to leste someday
<freemangordon> still, we may miss some corner cases, but lets hit them, will solve on as-needed basis
<dsc_> ok
<freemangordon> dsc_: actually, you can do even better:
<freemangordon> instead of trying to get remote contact on conversation start, just do it in 'new message' and cache it
<freemangordon> like, if remote_id is not already resolved to contact, call osso_abook_aggregator_find_contacts_for_im_contact() and cache the result
<freemangordon> next time just use the cached value
<dsc_> yes
<freemangordon> or values (like name, whatever)
<dsc_> thanks
<freemangordon> also, you really want to display the master contact name in the chat, agree?
<freemangordon> NP, ping me if anything
xmn_ has joined #maemo-leste
xmn has quit [Ping timeout: 248 seconds]
<dsc_> well
<dsc_> i dont know?
<dsc_> for now I'm going to ensure the correct abook uid gets into rtcom
<dsc_> name retreival is the next part
<freemangordon> you get it for free once you have the master contact
<freemangordon> osso_abook_contact_get_display_name() :)
xolitude has joined #maemo-leste
xolitude has left #maemo-leste [#maemo-leste]
<dsc_> sounds good
<freemangordon> and the same for avatar
<Wizzup> 15:21 < dsc_> for now I'm going to ensure the correct abook uid gets into rtcom
<Wizzup> just stating the obvious, this won't be true for the ones inserted by conversations with the previous code
<freemangordon> yeah
<dsc_> yes, that *may* cause crashes actually
<freemangordon> that will affect the history in the addressbook
<dsc_> however, its fixable
<dsc_> (i hope, will see)
Smatkovi has quit [Ping timeout: 248 seconds]
xmn_ is now known as xmn
<dsc_> freemangordon: about this caching, are you suggesting to do this for most things?
<dsc_> because thats what ROSTER essentially was
<dsc_> nvm, will focus on abook uid for now (and display name)
<dsc_> continue tomorrow :P
arno11 has joined #maemo-leste
<dsc_> for remote_uid 'gajim@xmpp.kroket.io' I received 'osso-abook-tmc257' via 'osso_abook_contact_get_uid'
<dsc_> suppose thats ok
<dsc_> we can fix the previous erroneous entries if its always like that
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
_fab has joined #maemo-leste
Gary_M has quit [Quit: Leaving]
Gary_M has joined #maemo-leste
<freemangordon> dsc_: no, you should use osso_abook_aggregator_find_contacts_for_im_contact()
<freemangordon> to get the master uid
<freemangordon> oh, wait
<freemangordon> you may not have master id
<freemangordon> but still, that should be ok, though, we have to check what fremantle logs in case of temporary id
<freemangordon> dsc_: there is osso_abook_is_temporary_uid()
<freemangordon> it seems it logs temporary uid
<freemangordon> anyway, you still shall use use osso_abook_aggregator_find_contacts_for_im_contact() to get the master contact, if any
<freemangordon> or maybe there is a better (faster) function, to get master contact from roster one
<freemangordon> have to run now, will look at it later
<freemangordon> osso_abook_contact_get_persistent_uid()
<freemangordon> not sure, bbl
arno11 has quit [Quit: arno11]
inky has quit [Ping timeout: 255 seconds]
PieSen has quit [Ping timeout: 248 seconds]
<freemangordon> do you have a contact in addressbook for 'gajim@xmpp.kroket.io' ? offline one that is
<freemangordon> uh, actually 'osso-abook-tmc257' *is* master contact, albeit temporary
<freemangordon> so yeah, it is okay to insert that id in rtcom DB
<freemangordon> dsc_: so, create an entry in your addressbook which has 'gajim@xmpp.kroket.io' as xmpp address
<freemangordon> then you should start receiving that master contact id for 'gajim@xmpp.kroket.io'
<freemangordon> that's the theory
<freemangordon> so, first, make sure you have entries in rtcom db with 'osso-abook-tmc257' as abook_id
<freemangordon> then, from addressbook history, create persistent contact for that roster contact
<freemangordon> and then you should start receiving persistent contact id for 'gajim@xmpp.kroket.io'
<freemangordon> if not, LMK
Livio has quit [Ping timeout: 272 seconds]
Twig has joined #maemo-leste
apac has quit [Quit: Konversation terminated!]
<freemangordon> Wizzup: hmm... I don;t see abook_id in events table
<freemangordon> oh, it is in Remotes table
Gary_M has left #maemo-leste [#maemo-leste]
Gary_M has joined #maemo-leste
Gary_M has left #maemo-leste [#maemo-leste]
Gary_M has joined #maemo-leste
Gary_M has left #maemo-leste [#maemo-leste]
Gary_M has joined #maemo-leste
<freemangordon> dsc_: so, if uid is temp, do not log it, use NULL instead
<freemangordon> this is what fremantle does it seems
Gary_M has quit [Ping timeout: 248 seconds]
Gary_M has joined #maemo-leste
Gary_M has quit [Client Quit]
Gary_M has joined #maemo-leste
Gary_M has quit [Ping timeout: 248 seconds]
Gary_M has joined #maemo-leste
Wizzup has quit [Read error: Connection reset by peer]
Wizzup has joined #maemo-leste
ikmaak2 has quit [Ping timeout: 256 seconds]
ikmaak has joined #maemo-leste
Twig has quit [Remote host closed the connection]
arno11 has joined #maemo-leste
<arno11> sicelo: btw when you tried cloudgps on D4 the window was like 800x480, right ?
<arno11> i mean, not smaller ?
<Gary_M> Is there a working camera app for daedalus on tbe pinephone?
<arno11> i think there are some devuan apps, kiva should know
<Gary_M> arno11: thanks! I've tried pinhole and no luck.
<sicelo> arno11: i think it was 800x480
inky has joined #maemo-leste
Gary_M has quit [Ping timeout: 248 seconds]
<arno11> sicelo: ok, so it seems that D4 is recognised as N900 with #if defined(N900) macro
<arno11> ty
<arno11> Gary_M: ah ok
Gary_M has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 272 seconds]
arno11 has quit [Quit: arno11]
_fab has quit [Quit: _fab]
Anasko has joined #maemo-leste
freemangordon has quit [Ping timeout: 248 seconds]
lel has quit [Ping timeout: 248 seconds]
lel has joined #maemo-leste
freemangordon has joined #maemo-leste
retr0id has quit [Server closed connection]
retr0id has joined #maemo-leste
Gary_M has quit [Ping timeout: 260 seconds]
Gary_M has joined #maemo-leste