norayr has left #maemo-leste [Disconnected: Broken pipe]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
nyov has quit [Ping timeout: 260 seconds]
nyov has joined #maemo-leste
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
macros_ has quit [Ping timeout: 260 seconds]
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
macros_ has joined #maemo-leste
Twig has joined #maemo-leste
ceene has joined #maemo-leste
<freemangordon> uvos: "fixing" osso-addressbook to recognize event_type is a hack and not going to work. Event types are el plugin specific and not part of any API.
<freemangordon> also, I don;t see how we can distinguish between phone and SIP call
norayr has left #maemo-leste [Disconnected: timeout during receiving]
maxwelld has left #maemo-leste [#maemo-leste]
maxwelld has joined #maemo-leste
norayr has joined #maemo-leste
Daanct12 has joined #maemo-leste
Twig has quit [Remote host closed the connection]
norayr has left #maemo-leste [Error from remote client]
pere has quit [Ping timeout: 258 seconds]
maxwelld has left #maemo-leste [#maemo-leste]
maxwelld has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__> freemangordon: there is RTCOM_EL_PLUGIN_CALL_TYPE_VOIP and RTCOM_EL_PLUGIN_CALL_TYPE_GSM
<uvos__> yes you have to use the plugin to figure out what the type field is supposed to mean
<uvos__> you also have to use the plugin to know what any of the fields in the database mean, the plugins do do this differently
<uvos__> using the database directly like abook dose it broken, as can clearly be seen by the fact that it effectively hardcodes voip and gsm calls to not have a url in the remote_idenitifer field but then hardcodes all other types to be a uri
<uvos__> now you could argue this whole "plugin determines the meaning of fields" thing is stupid, and you would be right
<uvos__> its also really only half implemented
<uvos__> but thats how it nokia did it, fairly defficant.
<uvos__> we could change this by forgetting about the plugins and fixing the meaning of the database fields to allways be the same
<uvos__> but the choise to break compatability with fremantle databases should be made consciously
pere has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
DPA has quit [Ping timeout: 255 seconds]
DPA has joined #maemo-leste
pere has joined #maemo-leste
pere has quit [Ping timeout: 258 seconds]
xmn has quit [Ping timeout: 272 seconds]
<freemangordon> uvos__: oh, seems we already have something here https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/call-plugin.c#L266
<freemangordon> so we can just add vcard-field header when adding the event and I'll teach osso-abook to use it
<freemangordon> sounds sane?
<uvos__> not sure i grok what you want to add exactly
<uvos__> a table of type -> field?
norayr has joined #maemo-leste
<freemangordon> uvos__: I want to call rtcom_el_add_header("vcard-field", "tel") in sphone rtcomel plugin
<freemangordon> "Headers" table is already used as id->value table
<uvos__> freemangordon: ok thas fine for now
<uvos__> freemangordon: eventually the sphone backends sheme (https://github.com/maemo-leste/sphone/blob/e4f6af0d4d744f189ea0382846a6c1d9789c112e/src/modapi/comm.h#L34) should porbubaly be used instead of "tel"
<uvos__> also what about remote_uid when its not tel or sms
<uvos__> shal sphone append the sheme from the backend like fremantle
<freemangordon> what else it could be?
<uvos__> or shal we fix remote_uid to never contain the theme?
<uvos__> *sheme
<uvos__> well tel:// and sms:// are still a wierd case where fremantle dosent prepend tel:// to remote_uid
<uvos__> while it dose prepend skype:// for instance
<freemangordon> it does not prepend scheme to anything I have here
<freemangordon> i took my el db from fremantle
<freemangordon> no skype calls there though
<uvos__> hmm so why dose abook think the sheme should be in remote_uid?
<freemangordon> maybe some remnant frm the old times
<uvos__> abooks code tries to determine the vcard field by handling remote_uid as a uri
<freemangordon> no idea
<freemangordon> yes
<uvos__> ok
<freemangordon> but maybe some old version was working that way
<uvos__> so sphone shal never prepend, even when i add support for the backend sheme handling
<uvos__> ok
<freemangordon> anyway, if you check call plugin code, there is a special support for vcard-field event value
<uvos__> sounds sane
<freemangordon> mhm
<freemangordon> ok, will make a PR when I have it working
<uvos__> ok
<uvos__> great
<freemangordon> did you try latest changes?
<freemangordon> libhildonmime etc
<uvos__> no not yet sorry, im out of town
<freemangordon> ok
<freemangordon> ok, back to RL work, ttyl
<uvos__> ttyl
Daanct12 has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
ceene has quit [Ping timeout: 240 seconds]
xmn has joined #maemo-leste
hexnewbie has quit [Ping timeout: 255 seconds]
hexnewbie has joined #maemo-leste
RedW has quit [Quit: huh upgrades]
RedW has joined #maemo-leste
akossh has joined #maemo-leste
uvos__ has quit [Ping timeout: 255 seconds]
<Wizzup> the librem made it safely to my place
<freemangordon> uvos: so, there is no way now to get the currently used scheme (in sphone that is)?
Twig has joined #maemo-leste
<maxwelld> uvos, thank you for explanations. i am glad leste itself doesn't use much memory now. because i myself try to not use things that use lots of memory.
<maxwelld> i am a windowmaker/x11/xterm user with pidgin on laptops, well browser is a problem but i am trying to use netsurf and only rarely, if very necessary visit websites that are heavy and slow and have lots of js and ads etc.
<maxwelld> even on pinebook, when i run gentoo, if i see this is hard/slow to compile, i just don't use it anywhere, on a powerful laptop too.
pere has quit [Ping timeout: 255 seconds]
<Wizzup> freemangordon: with my sphone plugin each tp account is it's own sphone backend
<freemangordon> ok, but can I get backend uri scheme somehow?
<Wizzup> I will answer that tomorrow, I have a 7am meeting and it's 1:07am :)
<freemangordon> ok
<freemangordon> :)
<Wizzup> backend_id = id;
<Wizzup> backend_name = strdup(backend_id.toStdString().c_str());
<Wizzup> sphone_backend_id = sphone_comm_add_backend(backend_name, schemes,BACKEND_FLAG_CALL);
<Wizzup> I think that might just be the full backend id as in telepathy qt
<freemangordon> no, I need uri scheme like "tel", "sms", etc
<Wizzup> you can get it using that I guess, not sure about scheme, I think it might register it, will need to check tomorrow
<Wizzup> call_properties->needs_route = backend->type == "tel"
<Wizzup> oh, nevermind, that is the tp backend and not sphone backend I think
<Wizzup> oh, also for sphone you register it with a scheme
<Wizzup> so probably there is a way to get it
<Wizzup> static const Scheme call_scheme = { .scheme = (char*)"tel", .flags = BACKEND_FLAG_CALL
<Wizzup> };
<freemangordon> it is a list of schemes unfortunately
<freemangordon> we need uvos here I guess
<Wizzup> he'll be back soon enough :)
* Wizzup zzz
Twig has quit [Remote host closed the connection]
uvos has joined #maemo-leste
<uvos> freemangordon: this bit isent finished yet, sphone's backends register shemes, but they are not used, except to find a backend to use when sphone is called by the xdg-open dispatcher
<uvos> there currently is no api for sphones modules to read a backends shemes.
<freemangordon> ok
<uvos> that the schemes are a list
<freemangordon> though so and hardcoded "tel"
<uvos> yes
<uvos> for now untill i finish this bit
<freemangordon> mhm
<uvos> the fact that it is a list is just a hedge against the possibility that there could be several schemes that mean the same thing
<uvos> eatch backend is expected to be one protocoll
<uvos> so once this is finished using the first scheme in the list for the given backend should be safe
<freemangordon> uvos: BTW, I would have used hash table in sphone_comm_get_backend()
<uvos> assuming the flags match
<uvos> freemangordon: sure yeah
<uvos> would be better
<freemangordon> uvos: when the (scheme) API is there, we will just unhardcode it
<uvos> yup
<freemangordon> could you have a glance ove the PR so I can push osso-addressbook changes?
<uvos> freemangordon: "sphone_module_log(LL_ERR, "failed to add event to rtcom: %s");" <-- hmm
<freemangordon> uh
<freemangordon> sorry about that
<uvos> np
<freemangordon> will fix in a moment
<freemangordon> though I wonder why compiler said nothing
<uvos> maybe missing decorator
<uvos> hmm maybe the fact tht its through a macro trips it up?
<uvos> not sure
<freemangordon> me neither
pere has joined #maemo-leste
<uvos> your hardcodeing tel also for messages
<uvos> which is wrong, should be sms://
<freemangordon> no
<freemangordon> this is not uri scheme ;)
<uvos> sms dosent translate to the same vcard sheme?
<freemangordon> but vcard-field
<uvos> *field
<freemangordon> vcard-field is not scheme
<freemangordon> and sms, phone, tel, callto schemes, all translate to EVC_TEL
<uvos> ok but my understanding was we where translateing schemes to vcard fields here
<uvos> (which is something we need to do)
<uvos> somewhere
<uvos> if sphone needs to do this thats fine, but obv i need to be aware :P
<freemangordon> so? we support sms:// and tel:// schemes. right? both are mapped to EVC_TEL vcard-field
<uvos> sure, but atm sphone knows what sheme a backend supports
<uvos> but not what vcard fields that is
<freemangordon> and that's fine
<freemangordon> but we have no API to know which scheme was used for the particular event
<uvos> right, its just that later when we do have sutch api, we also need something to translate the scheme to vcard fields
<freemangordon> right
<freemangordon> the same like what _get_vcard_field_from_uri() in osso-addressbook does
<uvos> right, just more robust, to put it mildly :P
<freemangordon> mhm
<freemangordon> or more complete I would say
<freemangordon> maybe each backend shall provide mapping function
<freemangordon> dunno how much you want eds compatibility
<uvos> not sure yet
<uvos> later
<freemangordon> uvos: PRT updated
<freemangordon> *PR
<uvos> looks good
<freemangordon> ok, please make a release when you have time, I will make a new release for abook
<uvos> certenly
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
Schimon has quit [Ping timeout: 264 seconds]
ceene has joined #maemo-leste
ceene has quit [Ping timeout: 258 seconds]
akossh has quit [Ping timeout: 260 seconds]
ahmed_sam has joined #maemo-leste
parazyd has quit [Ping timeout: 272 seconds]
DPA has quit [Ping timeout: 245 seconds]