<Wizzup>
uvos: but I am finding more than yeah we might not want to just install sfos vc-mgr
<Wizzup>
so we could write code for sphone to just load vc-mgr providers plugins directly, or copy the code to sphone, what do you think?
<Wizzup>
copying directly would probably make more sense for us: easier to maintain / modify and such, and voicecall-mgr isn't normally packaged on debian anyway (I packaged it for us)
<Wizzup>
uvos: in any case let me know what you think before I proceed to do useless work ;)
<Wizzup>
freemangordon: ^^
rafael2k has quit [Ping timeout: 260 seconds]
arno11 has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
rafael2k has joined #maemo-leste
Pali has joined #maemo-leste
rafael2k has quit [Ping timeout: 256 seconds]
slep has joined #maemo-leste
Danct12 has quit [Quit: WeeChat 4.1.1]
<freemangordon>
Wizzup: maybe I am missing the details, but I think using upstream (and not forking) is more sane
<freemangordon>
I doubt they will make drastic changes to the interface with out need
<freemangordon>
packaging should not be a stopper
<freemangordon>
not to say if we have that as a package, another UI will be more easy to create
<Wizzup>
what do you mean with 'using upstream' specifically
<Wizzup>
to use the tp .so from voicecall-manager but not the binary?
<Wizzup>
as in, not run voicecall-manager, but use it's shared object directly
<Wizzup>
the 'problem' with voicecall-manager is that it basically does what sphone does, and it actually also talks to mce and such (with wrong signatures sometimes), which we don't really want
<Wizzup>
also I might have to make some changes to the tp plugin potentially
<Wizzup>
but they (voicecall-manager) mostly abstracted the code quite well
<Wizzup>
so the way I see it we have a few options...
<Wizzup>
1. talk to voicecall-manager over dbus from sphone (what I implemented currently)
<Wizzup>
2. implement stub voicecall-manager interface in sphone and load voicecall-manager .deb's .so directly (this is as upstream as it gets)
<Wizzup>
3. copy code from voicecall-manager to sphone and modify it a bit to suit our needs
<Wizzup>
please note that I am 100% confident we will have to make a bunch of changes to the tp code regardless, it doesn't support jabber at all atm (protocol hardfilter on 'sip' and 'tel')
<Wizzup>
there's also the anonymous caller bit being set
<Wizzup>
I think (1) will get us quickly to TP calls, and I might press ahead just to make this work for my devices today/now
<Wizzup>
I think (3) will be the easiest for us going forward, (2) would be more tricky since for every change we'd have to recompile the pkg
<Wizzup>
freemangordon: ^
<sicelo>
Wizzup: forgive the possibly silly question ... vcm is needed because it has tp integration/support already? or tp is still totally separate?
<Wizzup>
yes, I was looking at it for TP
<Wizzup>
but we can also just use their TP code in sphone and modify it, rather than run VCM
<Wizzup>
and I have it working now with TP, but apart from a few minor small fixes there is an architectural thing where it replaces a lot of what sphone does for us
pere has quit [Ping timeout: 256 seconds]
slep has left #maemo-leste [#maemo-leste]
ceene has quit [Ping timeout: 256 seconds]
slep has joined #maemo-leste
fab_ has joined #maemo-leste
<Wizzup>
freemangordon: do you know if tracker has logs?
<Wizzup>
I am also seeing poor pm and now my database is gone again, and tracker-extract was using a lot of cpu
slep has left #maemo-leste [#maemo-leste]
slep has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
akossh has joined #maemo-leste
<freemangordon>
Wizzup: I think logs are disabled by default
<freemangordon>
isn't ther anything in syslog?
<freemangordon>
Wizzup: re vcm - seems I am missing the details, however, wouldn't we want some cooperation with SF guys?
<freemangordon>
like, they will support debian packaging and in return we will implement jabber or somesuch
<Wizzup>
freemangordon: that doesn't solve the problems I mentioned
<Wizzup>
also I found the sfos people to very unresponsive
<Wizzup>
to be*
<freemangordon>
I see
<Wizzup>
freemangordon: I tried to give the details :D
<freemangordon>
sure
<freemangordon>
ok, I don;t understand what are the cons of option 1
<Wizzup>
separate daemon that does all kinds of things like talk to mce, turn screen on, etc
<Wizzup>
which sphone already does for us
<Wizzup>
and the same downsides from (2) apply - regarding fixing things
<freemangordon>
ok, but if I want to implement tphone someday, I will be able to focus on the UI only, no?
<Wizzup>
what is tphone?
<freemangordon>
s->t
pr0ton has quit [Ping timeout: 256 seconds]
<Wizzup>
well, not if you want the actual integration
<Wizzup>
like, what about mce
<freemangordon>
if vcm already talks mce, albeit some dialect, we shall fix/improve that
<Wizzup>
why?
<Wizzup>
what will do rtcom logging?
<freemangordon>
because it we are to use another dialer someday, not sphone, we'll have to reimplement all this from scratch
<Wizzup>
not really, the code will still be there
<freemangordon>
where?
<freemangordon>
in sphone?
<Wizzup>
sure
<freemangordon>
that does not make it reusable
<Wizzup>
unless you plan to not use sphone I don't think having another daemon that does the same makes sense imo
<Wizzup>
nevertheless, this is exactly what I did in pull request 4
<Wizzup>
and I run into stupid things like I can't control the privacy/anonymous bit through the interface they offer
<Wizzup>
also, for any video calls you'll also need some level of control
<Wizzup>
as in, why would we try to 'fix' mce calls for sailfish (not maemo mce) when we have it working in sphone already, is what i mean
<Wizzup>
we can still try to fix voicecall-manager but most of what it does, we do not need
<Wizzup>
I'm pretty sure sfos just uses the ofono provider instead of the telepathy-ring one btw, but that is just a guess
<freemangordon>
yes, I plan to not use sphone, unless uvos decides to implement/accept proper abook integration at some point and give up on his plans to remove rtcom support (iirc)
<Wizzup>
we can make a hildon gtk2 ui and load it
<Wizzup>
the ui is already modular
<freemangordon>
it is not about the ui
<freemangordon>
have to go to the store, brb
pr0ton has joined #maemo-leste
Shock_ is now known as shOkEy
<freemangordon>
Wizzup: also, I am not sure sphone has any concept of video calls
brabo has joined #maemo-leste
<Wizzup>
freemangordon: I just want to get working calls with tp-ring and sip/jabber, what do you think is the best path forward, with not too much effort
<freemangordon>
sphone
<freemangordon>
but at the same time we shall try to make future replacement as easy as possible. not that 'easy' is applicable here, but I think you get the point
<Wizzup>
sure
<Wizzup>
it's quite funny to me just how hard it is to figure out what params can be set for a tp account
<Wizzup>
I am trying to see if anon calls are just enabled by default in tp ring or something and I just can't figure it out
<Wizzup>
freemangordon: in any case I still don't know how to proceed
<Wizzup>
I am just going to try to debug the one problem with anon calls and then I can use this on my device to develop conversations with dsc for sms and such
<sicelo>
ac_laptop: there were lots of fakes too, fyi :-p
<sicelo>
as you've been told already, no real N900 was dual sim
<sicelo>
poor people going to lose $50
DPA2 is now known as dpa
Twig has joined #maemo-leste
dpa is now known as DPA
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: having a sphone module that can load vcm modules would be fine by me, as long as you dont have to "poision" sphone core, ie leak details of the vcm modue interface
<uvos__>
freemangordon: what is "rtcom support" the only original rtcom piece used by sphone is rtcom-el, im not planning on dropping that, but eventually i want to add a module that logs allows you to its own sql database, but that dosent affect us here at all
<uvos__>
i am planning on removeing the abook module
<uvos__>
but that is because it dosent do anything that is usefull at this point
<uvos__>
it opens a abook dialog to allow you to select a contact and phone number
<uvos__>
but you might as well use that button in sphone to open osso-addressbook, wich allows you to do the same thing now, while being simply better than the abook dialog
<uvos__>
Wizzup: if you want to do 3 thats fine to by me, but its more work, and in the end the qt code you then have inside of sphone will allways be pretty akward anyhow in a primary glib application
<uvos__>
then again i want to replace the current gtk ui with qt, so this is sphones future anyhow, and is why the inter-module interfaces are all plain c
<uvos__>
not "poision" sphone core ofc dosent mean not adding new functionality required, we just need to think of how to do generic interfaces that fit with all the other inter-module interfaces
<uvos__>
im happy to do this part
<uvos__>
that includes add video calls, atho i think this is really not a priority at all atm.
<uvos__>
and will be hard to do in a system where i expect the provider of the video call and the ui to not leak toolkit details to eatch other, while avoiding copying things around.
pere has joined #maemo-leste
<Wizzup>
uvos__: thanks, I am not sold on the loading vcm modules directly
<Wizzup>
feels very hacky
<Wizzup>
uvos__: to me (3) seems more future proof, we already have qt code in sphone now with telepathy qt and it works fine
arno11 has joined #maemo-leste
<uvos__>
for 2 i was thinking having a shim.c file that we compile with the module sources to compile sphone native modules from vcm sources
<uvos__>
not loading the vcm modules as is
<uvos__>
but keeping the source files close enough to keep merging sfos patches in
<Wizzup>
so sfos rarely touches this, like less than twice a year or so
<uvos__>
Wizzup: sure @ qt code in sphone, its just akward as long as this is the only qt part, and the ui is still gtk, so mostly near-ish term
<uvos__>
Wizzup: ok
<Wizzup>
well I already did this in the current pull request (mapping qt to gtk)
<Wizzup>
I mean their code doesn't even let you set anon calls or not
<uvos__>
you mapped qt to sphones moudle interface
<uvos__>
wich is not gtk
<Wizzup>
so I bet they might not use it
<Wizzup>
yeah, ok, sry :)
<uvos__>
i mean we can evolve 2 into 3 slowly prety smoothly
<uvos__>
so maybe we should do that
<uvos__>
but whatever you like best
<Wizzup>
I am not sure what the benefit of 2 would be if we don't plan to do it long term I think
<Wizzup>
argh, now the modem of my VM resets when it goes online :)
<Wizzup>
life is just full of struggles
<Wizzup>
:D
uvos__ has quit [Ping timeout: 264 seconds]
ac_laptop has quit [Quit: WeeChat 3.8]
arno11 has left #maemo-leste [#maemo-leste]
Twig has quit [Remote host closed the connection]
RedW has quit [Ping timeout: 256 seconds]
RedW has joined #maemo-leste
<Wizzup>
freemangordon: I can't figure out how to make a channel using ensureChannel* or createChannel* and actually pass any properties on the channel
<Wizzup>
telepathyprovider.cpp:136:135: error: use of deleted function ‘Tp::Client::ConnectionInterfaceAnonymityInterface::ConnectionInterfaceAnonymityInterface(Tp::Client::ConnectionInterfaceAnonymityInterface&&)’
<Wizzup>
really
<Wizzup>
I don't know how anyone ever just groks the TP APIs
<Wizzup>
i'm just trying to set the anonymity bits using tp qt and it seems freaking impossible