**** BEGIN LOGGING AT Fri Mar 18 02:59:57 2011
Mar 18 03:01:48 <balrog-k1n> denkenz: re c8b5143a03a4abe9e632610883ea853e7f222a7e: if we don't update the call forwarding properties when the EF changes then we may find we're out of sync with the sim
Mar 18 03:02:09 <balrog-k1n> so imho we'd either need to overwrite sim contents or update properties
Mar 18 03:19:49 <denkenz> balrog-k1n: How will that happen? We know the values from the network
Mar 18 03:20:09 <denkenz> Besides, the next time they're set / reset the sim will be updated
Mar 18 04:10:14 <balrog-k1n> denkenz: how would the network notify us if the values have changed? as far as i see we won't notice until we explicitly query the values
Mar 18 04:11:10 <denkenz> It doesn't, and the only way to change them is via a mobile request
Mar 18 04:11:40 <denkenz> If they magically change on their own then we should just scrap the cache inside call-forwarding in the first place
Mar 18 04:13:03 <balrog-k1n> right, but we don't do that, right?
Mar 18 04:13:31 <denkenz> sorry?
Mar 18 04:14:19 <denkenz> do you mean s/don't/won't?
Mar 18 04:14:19 <balrog-k1n> at this point, when the operator magically resets our call forwarding settings, we just ignore this, right?
Mar 18 04:14:38 <balrog-k1n> no, we don't scrap the cache right now
Mar 18 04:15:01 <denkenz> The purpose of EFcfis is not to store the CF settings
Mar 18 04:15:33 <denkenz> It is meant to tell the user they are on when they re-activate the phone / insert it into a different device
Mar 18 04:15:45 <denkenz> I highly doubt anyone will use Refresh to update EFcfis
Mar 18 04:16:25 <balrog-k1n> yeah, me too, but if something changes then we shouldn't ignore that that, i think? :)
Mar 18 04:17:36 <denkenz> Since we overwrite this file anyway, who cares?
Mar 18 04:17:37 <balrog-k1n> if we want to ignore the change then we have no need for the notifier in call-forwarding.c
Mar 18 04:18:35 <denkenz> I don't necessarily want to ignore it, just when we have queried the settings
Mar 18 04:18:41 <denkenz> But we could ignore it, sure
Mar 18 04:19:14 <balrog-k1n> i mean i don't see why we specifically ignore changes in CFis but not in any other writable files
Mar 18 04:19:28 <balrog-k1n> EFcfis i mean
Mar 18 04:19:33 <denkenz> Because EFcfis is non-authoritative
Mar 18 04:19:44 <denkenz> All others are
Mar 18 04:19:48 <balrog-k1n> same is true for EFmsisdn for example
Mar 18 04:20:00 <denkenz> Not really, there is no other source of EFmsisdn
Mar 18 04:20:12 <denkenz> There are two sources of CFU
Mar 18 04:20:33 <balrog-k1n> the other thing is that the notifier in call-forwarding.c is dead code if we just return at the beginning
Mar 18 04:21:17 <denkenz> How is that? We're not guaranteed to have the cached flag set
Mar 18 04:21:56 <balrog-k1n> yeah, but if we don't then we'd re-read the file anyway, i think the point of using the notifier is specifically to update our cache
Mar 18 04:21:59 <balrog-k1n> i will bbl, battery's running out
Mar 18 04:22:23 <denkenz> We can't, the cache is updated once we queried all the settings
Mar 18 04:23:17 <denkenz> However, call-forwarding is a huge disaster area and I'm wondering whether we should just redo it completely
Mar 18 04:43:43 <weiqq> Does anyone know how to make the cmtspeech active?I mean cmtspeech_is_active(cmtspeech_t*) return true,
Mar 18 08:46:12 <fdanis> denkenz: ping
Mar 18 15:36:35 <fdanis> denkenz: ping
Mar 18 15:47:27 <denkenz> fdanis: pong
Mar 18 15:48:40 <fdanis> denkenz: do you see my comment about +COPS ?
Mar 18 15:49:17 <denkenz> yes, and I still stick to my earlier suggestion
Mar 18 15:49:29 <denkenz> We can't have hundreds of emulator foreach calls everywhere
Mar 18 15:50:07 <denkenz> you have to solve the online problem in a different way
Mar 18 15:52:07 <fdanis> this will imply to have one callback for offline mode in emulator and one for online mode in netreg, is it acceptable ?
Mar 18 15:53:54 <denkenz> no
Mar 18 15:54:18 <denkenz> have a think about it, there are other ways
Mar 18 15:54:41 <denkenz> I'm even fine taking your patch ignoring the online problem for now
Mar 18 15:55:17 <fdanis> which one ? indicators or cops ?
Mar 18 15:55:31 <fdanis> I have a new version for indicators
Mar 18 16:01:58 <fdanis> I am not sure to understand your last sentence, will you apply the current +COPS patch ?
Mar 18 16:09:40 <denkenz> no, but I will apply one that moves cops implementation to netreg.c
Mar 18 16:09:55 <denkenz> Then you can have a think about solving your online issue
Mar 18 16:12:13 <fdanis> ok, so I will send the indicators patch first
Mar 18 16:22:51 <Jeevaka> holtmann: ping
Mar 18 16:23:45 <fdanis> and, there is no issue with online mode, but with offline mode (when netreg atom is not registered)
Mar 18 16:25:23 <holtmann> Jeevaka: pong
Mar 18 16:25:52 <Jeevaka> holtmann: test has been done with timeout value of 0 and it works for different cases.
Mar 18 16:26:35 <Jeevaka> If you want to use 1 millisecond, thats also fine with me
Mar 18 16:27:09 <holtmann> I want you to use 1 second.
Mar 18 16:27:29 <holtmann> That is works is pure luck that the AT response is read first.
Mar 18 16:27:58 <holtmann> g_timeout_add_seconds(1, ...)
Mar 18 16:28:38 <holtmann> You can use g_idle_add if you like.
Mar 18 16:29:24 <holtmann> But then again here, NITZ without DST value is rather pointless. Why bother with NITZ at all then.
Mar 18 16:30:20 <holtmann> ofonod[1332]: Aux: < \r\n+CTZV: +08,"10/10/20,12:58:20"\r\n
Mar 18 16:30:20 <holtmann> ofonod[1332]: Aux: < \r\n+XNITZINFO: "GMT+1","10/10/20,12:58:20"\r\n\r\n+CTZDST: 1\r\n
Mar 18 16:30:31 <holtmann> Jeevaka: Btw. this is also all stupid IFX.
Mar 18 16:30:33 <denkenz> It wants you to have extra fun implementing it ;)
Mar 18 16:30:47 <denkenz> fdanis: Yes I know ;)
Mar 18 16:31:11 <holtmann> If they would just send +XNITZINFO after +CTZV and +CTZDST then this would be simpler, but no they need to send an optional one later on.
Mar 18 16:34:47 <Jeevaka> holtmann: test was done with the simulator where you can disable sending the network daylight saving with the MM information message
Mar 18 16:35:40 <holtmann> I bet you it works fine 99% of the time, but one bad timing in the kernel IO interrupt handling and you fail.
Mar 18 16:35:44 <Jeevaka> holtmann: atleast with the live network case, we receive all. But dont know with which network Antti observed this issue
Mar 18 16:36:18 <holtmann> Hence either g_timeout_add_seconds or g_idle_add.
Mar 18 16:36:34 <holtmann> Not a millisecond timeout of zero. Timeouts have priority over idle.
Mar 18 16:41:40 <Jeevaka> ok
Mar 18 16:49:57 <BertrandAygon> Hi. While testing cppcheck (which is very nice), I could found 2 non init var in oFono. And looking into this, I have saw this macro: #define uninitialized_var(x) x = x. And so, the var are declared like this: enum sms_charset uninitialized_var(charset);
Mar 18 16:50:13 <BertrandAygon> I am a bit surprised about this, can someone give me some hints
Mar 18 16:50:33 <denkenz> It is to shut up the compiler
Mar 18 16:50:52 <holtmann> BertrandAygon: False positives.
Mar 18 16:51:09 <denkenz> Basically it is flagging uninitialized variables, but if you follow the logic flow, they're never used uninitialized
Mar 18 16:51:24 <BertrandAygon> Ok, so you can init a var with itself, and compiler is ok with this
Mar 18 16:51:43 <denkenz> yep
Mar 18 16:51:49 <holtmann> It is gcc magic.
Mar 18 16:51:58 <BertrandAygon> :)
Mar 18 16:52:17 <BertrandAygon> Thanks, I learn a new magic
Mar 18 16:52:39 <holtmann> We "stole" that one from the kernel guys ;)
Mar 18 16:53:20 <BertrandAygon> Ok. Compiler is OK, but cppcheck not...
Mar 18 16:53:47 <BertrandAygon> I will try to see what we can do for cppcheck. I love magic
Mar 18 17:10:09 <pnunes> denkenz: You applied recently a STK patch from Andrew to fix an issue with null data object alpha id.
Mar 18 17:11:08 <pnunes> denkenz: Besides the fact that stk-util unit test is broken with this patch, I would like to understand in order to fix it properly if we still want to distinguish the case where the alpha id is not provided and the case where it is provided but it is a null data object (len = 0).
Mar 18 17:12:37 <pnunes> denkenz: if we don't want to display something when no AID is provided then OK we don't need to distinguish the 2 cases
Mar 18 17:20:35 <Jeevaka> pnunes: currently, we dont differentiate between alpha identifier not provided and null data object
Mar 18 17:22:06 <pnunes> jeewaka: That's what I see but I would like to confirm that we decided in this case to never display a "default" text.
Mar 18 17:22:28 <Jeevaka> pnunes: I think we will stick with that if we dont find a better idea
Mar 18 17:22:53 <pnunes> jeewaka: as you know, providing a null data object AID is an indication from the SIM to not display anything
Mar 18 17:23:09 <Jeevaka> pnunes: comment to confirm this has been added to stk_alpha_id_set function in stk.c
Mar 18 17:27:18 <pnunes> jeewaka: Ok, I see. But for unit test, we need to distinguish this case. Or we need to remove the test
Mar 18 17:29:16 <Jeevaka> pnunes: As per the spec, "if the alpha identifier is not provided by the UICC, the terminal may give information to the user concerning
Mar 18 17:29:19 <Jeevaka> what is happening."
Mar 18 17:29:41 <Jeevaka> pnunes: Note: "may give"
Mar 18 17:30:38 <pnunes> jeevaka: Yes, I understand but personally, I would prefer to display always something except when UICC asks to not display.
Mar 18 17:31:08 <Jeevaka> pnuens: Some text or no text both can be considered as success in this case
Mar 18 17:31:59 <pnunes> jeevaka: it's more user friendly to display something otherwise the user can consider that the lats action has not been taken into account. 
Mar 18 17:32:06 <Jeevaka> pnunes: if we can distinguish, then its fine with me too
Mar 18 17:33:17 <Jeevaka> since we didnt find a better idea, we left it undistinguished
Mar 18 17:33:45 <pnunes> jeevaka: we could just send an empty AID to the stk agent (with stk_agent_display_action_info) and let it display a default text or icon.
Mar 18 17:35:31 <pnunes> jeewaka: Ok, I'l try to bring a proposal that does this distinction.
Mar 18 17:35:49 <Jeevaka> pnunes: ok
Mar 18 17:35:51 <pnunes> jeevaka: thanks.
Mar 18 17:54:22 <denkenz> pnunes: I doubt anyone really cares in the end
Mar 18 17:54:39 <denkenz> And the default text has to come from the application, not from oFono since it is not i18n-ed
Mar 18 17:54:47 <denkenz> With the current setup it won't work
Mar 18 17:55:01 <denkenz> Jeevaka, balrog-k1n: Please investigate the unit test break and submit a patch
Mar 18 17:57:10 <pnunes> denkenz: yes , indeed, the idea was to let the stk agent to display a default text which could be localized. Can't we pass an empty string to the stk-agent ?
Mar 18 17:57:34 <denkenz> And do what? You still need the actual action as well
Mar 18 17:57:44 <denkenz> Today we don't hand out this information
Mar 18 17:58:13 <pnunes> denkenz: Yes, you're right. I missed this point.
Mar 18 17:59:53 <pnunes> denkenz: fact is that I already found a SIM card that wasn't providing AID with Send SMS command
Mar 18 18:00:27 <denkenz> As I said, nobody cares in the end
Mar 18 18:00:41 <denkenz> It is probably even annoying to get a popup of 'ooh you're sending an SMS'
Mar 18 18:01:09 <denkenz> The user goes like : "And? I just hit a menu requesting this info, I know I'm sending an SMS"
Mar 18 18:01:28 <denkenz> The whole idea of STK is 20th century, the less the user sees it the better
Mar 18 18:03:57 <pnunes> denkenz: hum, my point of view is that it is always better to indicate that the last action of the user is processing especially with finger touch
Mar 18 18:04:48 <pnunes> denkenz: for send sms, I not sure that the user knows what is going on , no confirmation is required
Mar 18 18:06:14 <denkenz> Getting an annoying popup in the middle of whatever he's doing is also annoying
Mar 18 18:06:35 <denkenz> And its not like the user can do anything about it
Mar 18 18:06:42 <denkenz> So why even bother telling them
Mar 18 18:09:21 <pnunes> denkenz: if the user can at least understand that his last action is processing then I 'm also fine with this approach. 
Mar 18 18:11:13 <denkenz> The UI knows since it will hide the last menu
Mar 18 18:15:14 <pnunes> denkenz: send sms is an action which can take a while.  I though that the last menu (or dialog) was displayed until the next proactive command is received or until the end session occurs. 
Mar 18 18:15:39 <denkenz> It shouldn't
Mar 18 18:15:54 <denkenz> If you get a RequestSelection and you return, you need to close that dialog
Mar 18 18:16:40 <pnunes> denkenz: yes but to display what ?
Mar 18 18:17:28 <denkenz> The main menu?
Mar 18 18:17:51 <pnunes> denkenz: I thought that the stk agent was just a dummy browser which was displaying what we ask to display 
Mar 18 18:18:12 <pnunes> denkenz: displaying the menu will bring flikering
Mar 18 18:18:30 <denkenz> Seriously, there's nothing to display once you're done with the action
Mar 18 18:19:59 <pnunes> pnunes: my approach is to switch to the next view only once the next proactive command is received or when the end session occurs.
Mar 18 18:21:29 <pnunes> denkenz: that's why I was demanding to display something in case of send SMS since we would likely be stuck a while in the last menu. 
Mar 18 18:22:56 <pnunes> denkenz: now I saw devices which were displaying the main menu between proactive commands. But I fell this flickering between main menu and the other views annoying
Mar 18 18:27:24 <denkenz> You will have other problems anyway
Mar 18 18:27:30 <denkenz> Send USSD comes to mind
Mar 18 18:28:23 <denkenz> Not to mention that any of these can come unsolicited without a user session
Mar 18 18:33:19 <pnunes> denkenz: Ok, I guess that I need to check with Luc (who is implementing the STK agent) regarding how the views are interlinked.  
Mar 18 18:33:39 <pnunes> denkenz: Thanks
Mar 18 20:45:49 <denkenz> holtmann: For lucas' patches, are you fine with CancelMessage(o) or do you want Cancel() on the Message object itself?
Mar 18 20:54:05 <denkenz> I'm going for Cancel on the Message object unless you change your mind ;)
Mar 18 23:30:41 <holtmann> denkenz: Either way is fine with me there.
**** ENDING LOGGING AT Sat Mar 19 02:59:56 2011