| Wizzup | sicelo: did they maybe change the dbus interface or something | 12:20 |
|---|---|---|
| Wizzup | https://kernel.googlesource.com/pub/scm/network/ofono/ofono/+/refs/tags/2.0/ChangeLog | 12:20 |
| Wizzup | doesn't look like it | 12:20 |
| Wizzup | looks like 2.1 has ussd fixes for quectel | 12:21 |
| sicelo | yes dbus interface is unchanged | 12:21 |
| Wizzup | I think we can probably rebase relatively easily then | 12:22 |
| sicelo | they recently changed the ofono atoms stuff. i have not been able to get the org.ofono.RadioSettings interface to appear since then | 12:22 |
| sicelo | so no way to select 3G or 2G anymore ... but it should be a small thing. just need to make time to look into it | 12:22 |
| Wizzup | wonder if that is a bug | 12:24 |
| Wizzup | seems like it is | 12:24 |
| Wizzup | uvos: so this is what the voicecall-manager pt plugin implements https://github.com/maemo-leste-upstream-forks/voicecall/blob/master/lib/src/abstractvoicecallhandler.h | 12:24 |
| Wizzup | and https://github.com/maemo-leste-upstream-forks/voicecall/blob/master/lib/src/abstractvoicecallmanagerplugin.h | 12:25 |
| Wizzup | this is the interface I use atm from sphone https://github.com/maemo-leste-upstream-forks/voicecall/blob/master/lib/src/voicecallmanagerinterface.h but if we just load the plugin in sphone directly it won't be all that different I suppose | 12:26 |
| Wizzup | uvos: we'd have to pull in some additional code if we would just use their interface as-is | 12:29 |
| Wizzup | doesn't seem too hard though, if you think that makes more sense | 12:29 |
| Wizzup | or we can hard-fork the code and just modify it to our needs and not care about their future fixes | 12:29 |
| Wizzup | https://github.com/maemo-leste-upstream-forks/voicecall/blob/master/src/voicecallmanager.cpp this seems to be what glues things together | 12:30 |
| Wizzup | uvos: but I am finding more than yeah we might not want to just install sfos vc-mgr | 12:34 |
| 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? | 12:34 |
| 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) | 12:36 |
| Wizzup | uvos: in any case let me know what you think before I proceed to do useless work ;) | 12:39 |
| Wizzup | freemangordon: ^^ | 12:39 |
| freemangordon | Wizzup: maybe I am missing the details, but I think using upstream (and not forking) is more sane | 14:37 |
| freemangordon | I doubt they will make drastic changes to the interface with out need | 14:38 |
| freemangordon | packaging should not be a stopper | 14:38 |
| freemangordon | not to say if we have that as a package, another UI will be more easy to create | 14:39 |
| Wizzup | what do you mean with 'using upstream' specifically | 14:43 |
| Wizzup | to use the tp .so from voicecall-manager but not the binary? | 14:43 |
| Wizzup | as in, not run voicecall-manager, but use it's shared object directly | 14:44 |
| 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 | 14:44 |
| Wizzup | also I might have to make some changes to the tp plugin potentially | 14:44 |
| Wizzup | but they (voicecall-manager) mostly abstracted the code quite well | 14:44 |
| Wizzup | so the way I see it we have a few options... | 14:45 |
| Wizzup | 1. talk to voicecall-manager over dbus from sphone (what I implemented currently) | 14:45 |
| Wizzup | 2. implement stub voicecall-manager interface in sphone and load voicecall-manager .deb's .so directly (this is as upstream as it gets) | 14:45 |
| Wizzup | 3. copy code from voicecall-manager to sphone and modify it a bit to suit our needs | 14:46 |
| 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') | 14:46 |
| Wizzup | there's also the anonymous caller bit being set | 14:46 |
| 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 | 14:47 |
| 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 | 14:47 |
| Wizzup | freemangordon: ^ | 14:47 |
| sicelo | Wizzup: forgive the possibly silly question ... vcm is needed because it has tp integration/support already? or tp is still totally separate? | 15:01 |
| Wizzup | yes, I was looking at it for TP | 15:05 |
| Wizzup | but we can also just use their TP code in sphone and modify it, rather than run VCM | 15:05 |
| 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 | 15:06 |
| Wizzup | freemangordon: do you know if tracker has logs? | 16:55 |
| Wizzup | I am also seeing poor pm and now my database is gone again, and tracker-extract was using a lot of cpu | 16:56 |
| freemangordon | Wizzup: I think logs are disabled by default | 18:45 |
| freemangordon | isn't ther anything in syslog? | 18:46 |
| freemangordon | Wizzup: re vcm - seems I am missing the details, however, wouldn't we want some cooperation with SF guys? | 18:56 |
| freemangordon | like, they will support debian packaging and in return we will implement jabber or somesuch | 18:57 |
| Wizzup | freemangordon: that doesn't solve the problems I mentioned | 19:06 |
| Wizzup | also I found the sfos people to very unresponsive | 19:06 |
| Wizzup | to be* | 19:07 |
| freemangordon | I see | 19:07 |
| Wizzup | freemangordon: I tried to give the details :D | 19:07 |
| freemangordon | sure | 19:07 |
| freemangordon | ok, I don;t understand what are the cons of option 1 | 19:09 |
| Wizzup | separate daemon that does all kinds of things like talk to mce, turn screen on, etc | 19:10 |
| Wizzup | which sphone already does for us | 19:10 |
| Wizzup | and the same downsides from (2) apply - regarding fixing things | 19:11 |
| freemangordon | ok, but if I want to implement tphone someday, I will be able to focus on the UI only, no? | 19:11 |
| Wizzup | what is tphone? | 19:11 |
| freemangordon | s->t | 19:11 |
| Wizzup | well, not if you want the actual integration | 19:11 |
| Wizzup | like, what about mce | 19:12 |
| freemangordon | if vcm already talks mce, albeit some dialect, we shall fix/improve that | 19:12 |
| Wizzup | why? | 19:12 |
| Wizzup | what will do rtcom logging? | 19:13 |
| freemangordon | because it we are to use another dialer someday, not sphone, we'll have to reimplement all this from scratch | 19:13 |
| Wizzup | not really, the code will still be there | 19:13 |
| freemangordon | where? | 19:13 |
| freemangordon | in sphone? | 19:13 |
| Wizzup | sure | 19:13 |
| freemangordon | that does not make it reusable | 19:14 |
| Wizzup | unless you plan to not use sphone I don't think having another daemon that does the same makes sense imo | 19:14 |
| Wizzup | nevertheless, this is exactly what I did in pull request 4 | 19:15 |
| Wizzup | https://github.com/maemo-leste/sphone/pull/4 | 19:15 |
| Wizzup | and I run into stupid things like I can't control the privacy/anonymous bit through the interface they offer | 19:15 |
| Wizzup | also, for any video calls you'll also need some level of control | 19:16 |
| 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 | 19:17 |
| Wizzup | we can still try to fix voicecall-manager but most of what it does, we do not need | 19:17 |
| Wizzup | I'm pretty sure sfos just uses the ofono provider instead of the telepathy-ring one btw, but that is just a guess | 19:17 |
| 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) | 19:19 |
| Wizzup | we can make a hildon gtk2 ui and load it | 19:19 |
| Wizzup | the ui is already modular | 19:19 |
| freemangordon | it is not about the ui | 19:19 |
| freemangordon | have to go to the store, brb | 19:20 |
| freemangordon | Wizzup: also, I am not sure sphone has any concept of video calls | 19:31 |
| 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 | 19:34 |
| freemangordon | sphone | 19:34 |
| 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 | 19:35 |
| Wizzup | sure | 19:38 |
| Wizzup | it's quite funny to me just how hard it is to figure out what params can be set for a tp account | 19:39 |
| 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 | 19:39 |
| Wizzup | freemangordon: in any case I still don't know how to proceed | 19:40 |
| 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 | 19:40 |
| Wizzup | $ mdbus2 org.freedesktop.Telepathy.ConnectionManager.ring /org/freedesktop/Telepathy/Connection/ring/tel/ring org.freedesktop.DBus.Properties.GetAll org.freedesktop.Telepathy.Connection.Interface.Anonymity | 19:44 |
| Wizzup | ({'AnonymityModes': <uint32 0>, 'SupportedAnonymityModes': <uint32 3>, 'AnonymityMandatory': <false>},) | 19:44 |
| Wizzup | I suppose 0 is just do whatever is requested, or perhaps what the network wants | 19:45 |
| Wizzup | perhaps my provider does anon by default is not specified | 19:45 |
| Wizzup | what would explain why this is not a problem on my vm,but it is on my d4 | 19:46 |
| Wizzup | ok, now it works! | 19:50 |
| Wizzup | mdbus2 org.freedesktop.Telepathy.ConnectionManager.ring /org/freedesktop/Telepathy/Connection/ring/tel/ring org.freedesktop.DBus.Properties.Set org.freedesktop.Telepathy.Connection.Interface.Anonymity AnonymityModes 2 | 19:50 |
| Wizzup | now sphone doesn't hide my caller id | 19:50 |
| Wizzup | so voicecall-manager doesn't set this connection param | 19:56 |
| Wizzup | that's a problem | 19:56 |
| Wizzup | in any case, freemangordon, shall I continue with (1) until we decide a better wy? | 19:56 |
| Wizzup | I personally think (3) is best fwiw, but it would take a bit more time, but provide us with flexibility | 19:57 |
| Wizzup | we can always contribute fixes back to them if they are interested | 19:57 |
| freemangordon | Wizzup: whatever fits you best | 20:00 |
| Wizzup | there is also a way to set anonymity per channel | 20:02 |
| Wizzup | freemangordon: well I might start asking you for help at some point with sip/jabber | 20:02 |
| freemangordon | sure | 20:13 |
| freemangordon | I am a bit overloaded with my RL job, but during the weekend I will have spare time | 20:13 |
| Wizzup | sometimes trying to telepathy is quite frustrating :D | 20:14 |
| freemangordon | heh | 20:15 |
| ac_laptop | was there a dual-sim version of the n900 ? | 20:24 |
| freemangordon | no | 20:25 |
| ac_laptop | I stumbled upon this | 20:26 |
| ac_laptop | https://www.ebay.com/itm/186171242846?hash=item2b58abb95e:g:LxQAAOSwykVlWTNy&amdata=enc%3AAQAIAAAA4K7a4ZYdsYv90p5Us9OmAlsrgOpyb48dOYfkDI4peeAgOICveHQaczaPIWZfONDj0JCNaMapNrK0Bre2Y3MjnEELh%2F%2FXUBip4UgdyzH37EsScjojkY9w4p94e3t7OkpCE5hi%2FOplO%2BurHM1uoobpzi%2FGOqpOzlTbvYKUm8YJgCmNgQj2akoaLs7ylWJSdP5jBsvAKrPPLW1W79jvlEdzzzPXFTzxc0rl0F21Vmt1Lh8SSJanLOgF0oIyl2h7x8zW0utcopa3371OVkqNiBD6r8tWea%2BhiB | 20:26 |
| ac_laptop | H%2Bamudx8tHDRu6%7Ctkp%3ABk9SR6b-8fWCYw | 20:26 |
| ac_laptop | sorry for the long link, here's the short one : https://www.ebay.com/itm/186171242846 | 20:28 |
| ac_laptop | anyway I guess it's modded hardware | 20:29 |
| sicelo | ac_laptop: there were lots of fakes too, fyi :-p | 20:29 |
| sicelo | as you've been told already, no real N900 was dual sim | 20:29 |
| sicelo | poor people going to lose $50 | 20:31 |
| 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 | 20:49 |
| 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 | 20:51 |
| uvos__ | i am planning on removeing the abook module | 20:52 |
| uvos__ | but that is because it dosent do anything that is usefull at this point | 20:53 |
| uvos__ | it opens a abook dialog to allow you to select a contact and phone number | 20:53 |
| 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 | 20:54 |
| 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 | 20:56 |
| 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 | 20:57 |
| 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 | 21:00 |
| uvos__ | im happy to do this part | 21:01 |
| uvos__ | that includes add video calls, atho i think this is really not a priority at all atm. | 21:01 |
| 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. | 21:03 |
| Wizzup | uvos__: thanks, I am not sold on the loading vcm modules directly | 21:49 |
| Wizzup | feels very hacky | 21:49 |
| Wizzup | uvos__: to me (3) seems more future proof, we already have qt code in sphone now with telepathy qt and it works fine | 21:55 |
| 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 | 22:08 |
| uvos__ | not loading the vcm modules as is | 22:08 |
| uvos__ | but keeping the source files close enough to keep merging sfos patches in | 22:09 |
| Wizzup | so sfos rarely touches this, like less than twice a year or so | 22:09 |
| 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 | 22:09 |
| uvos__ | Wizzup: ok | 22:10 |
| Wizzup | well I already did this in the current pull request (mapping qt to gtk) | 22:10 |
| Wizzup | I mean their code doesn't even let you set anon calls or not | 22:10 |
| uvos__ | you mapped qt to sphones moudle interface | 22:10 |
| uvos__ | wich is not gtk | 22:10 |
| Wizzup | so I bet they might not use it | 22:10 |
| Wizzup | yeah, ok, sry :) | 22:10 |
| uvos__ | i mean we can evolve 2 into 3 slowly prety smoothly | 22:11 |
| uvos__ | so maybe we should do that | 22:11 |
| uvos__ | but whatever you like best | 22:11 |
| Wizzup | I am not sure what the benefit of 2 would be if we don't plan to do it long term I think | 22:15 |
| Wizzup | argh, now the modem of my VM resets when it goes online :) | 22:17 |
| Wizzup | life is just full of struggles | 22:17 |
| Wizzup | :D | 22:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!