**** BEGIN LOGGING AT Thu Aug 11 02:59:58 2016 Aug 11 05:07:26 Morning Aug 11 05:09:14 Herrie: for the webappmgr PR, the last argument is actually a standard parameter of a LS2 call (not part of the json arguments!); in the end it's a metadata about the message, and that's why it is not neccessary to have it in the json parameters Aug 11 05:09:39 (it's the "-a xxx" or the luna-send command, to make a parallel) Aug 11 05:09:53 of* Aug 11 05:11:43 Tofe: OK already thought so Aug 11 05:11:53 Will merge so can test stuff Aug 11 05:12:04 cryptk: OK thnx Aug 11 05:12:05 ok :) Aug 11 05:12:18 It seems that the wiki DB is still read only, I cannot add/edit stuff Aug 11 05:12:28 cryptk: ^ And ideas? Aug 11 05:12:43 cryptk: Also our templates are broken it seems :S Aug 11 07:22:56 morning Aug 11 08:51:34 Tofe: ping Aug 11 09:03:19 Tofe: Nevermind found another way of getting what I was looking for :) Aug 11 09:32:32 Herrie|Pre3: pong^W Aug 11 09:37:20 Tofe: Sorted, was looking for a way to get deviceinfo and was thinking I needed PalmSystem in QML but seems I can simply do a ls2 call to com.palm.systemservice/deviceInfo/query :) Aug 11 09:38:21 yup :) Aug 11 09:42:46 Tofe: You don't happen to have a N4 at hand? Aug 11 09:42:58 To see what it gives for that call? Aug 11 09:45:35 ah, no, I'm at work, without any luneos device Aug 11 09:49:27 Tofe: OK was worth a shot :P Aug 11 09:50:01 Mine is at home too. I'll work on some small bits & fine tune later then when at home :) Aug 11 11:02:20 Herrie|Pre3: do you have anything in mind i can work on? Aug 11 11:45:01 nizovn: Hardware GPS via GeoClue2 or libevdev plugin for querying hardware features? Aug 11 11:47:37 Both are in the issue tracker. I can paste you the links when back in the office in a bit. Aug 11 12:03:00 1003 and 1111. I guess the 1111 would be nicer to have on a device if you use it on a daily basis :P Aug 11 12:04:39 1111 is harder to solve on device without gps Aug 11 12:05:57 nizovn: That's true... Aug 11 12:06:51 actually 1003 is not so hard as we already have something similar https://github.com/webOS-ports/nyx-modules-hybris/blob/master/src/system/power_key_resume_handler.c#L75-L122 Aug 11 12:08:26 nizovn: OK :) Aug 11 12:10:14 What we'd use this for is mainly in LNC (so QML) to determine if a device has certain hardware features like a power, volume key etc, so we can adjust UI elements based on that. We currently do that based on values in the luna-xyz.conf which is a bit nast Aug 11 12:10:15 y. Aug 11 12:11:15 ok Aug 11 13:40:15 filmor: Hi :) Aug 11 13:40:28 hi :) Aug 11 13:41:07 We're making solid progress with IM bits :) Tofe is working on some optimizations of the C++ code, so things don't need to be hardcoded :P Aug 11 13:41:21 But messages can now be received it seems :P Aug 11 13:41:26 nice :) Aug 11 13:41:34 glad you could get this running :) Aug 11 13:42:25 Sending has some issues still but that's because we didn't extend the hard coded list of IM services yet, so incoming messages got labeled as SMS :P Aug 11 13:43:00 So replies wouldn't work. Tofe is looking to optimize this code a bit so we don't need to keep static tables and update with each added protocol :P Aug 11 13:44:04 where are those static tables? Aug 11 13:44:16 I don't remember having to touch something like this for the pre or touchpad Aug 11 13:46:02 imlibpurpleservice/inc/PalmImCommon.h for example ;) Aug 11 13:46:54 The SERVICENAME_XYZ and CAPABILITY_XYZ values ;) Aug 11 13:49:28 well, yeah Aug 11 13:49:32 I removed that bit Aug 11 13:49:33 https://github.com/filmor/webos-messaging/commit/de13d1daf0ab7f0172800470fa6c597e65d35082 Aug 11 13:50:32 where are those entries still used? Aug 11 13:51:33 filmor: We have a bit of a hybrid of your version and the 3.0.5 open sourced version. Aug 11 13:51:39 Seems so :P Aug 11 13:51:53 Could be you removed it in your version somehow Aug 11 13:53:47 let me check your version Aug 11 13:54:14 IIRC the whole SERVICENAME stuff is completely obsoleted because the service name is generated dynamically Aug 11 13:54:16 Tofe: Might be an idea to put them side by side to see if there are some more ideas in filmor's version that we could leverage :P ? Aug 11 13:57:00 ah, okay Aug 11 13:57:16 you are apparently using a vanilla imlibpurpleservice with my imaccountvalidator Aug 11 13:57:27 weird that it has worked so far ... Aug 11 13:57:43 filmor: Yeah LOL :P Aug 11 13:59:54 Well our templates provide the right info probably :P Aug 11 14:00:25 Since validation & adding accounts works fine Aug 11 14:00:52 https://github.com/filmor/webos-messaging/blob/master/src/LibpurpleAdapter.cpp#L381 Aug 11 14:00:56 That's what you are missing Aug 11 14:01:21 the servicename is generated dynamically, you can't guess it from the account name Aug 11 14:01:47 (that fails for example if some service uses an email-address as account name) Aug 11 14:02:14 so what I did here is that I store the service-name that was used to create the account in the ui_data field of the struct Aug 11 14:02:51 https://github.com/filmor/webos-messaging/blob/master/src/LibpurpleAdapter.cpp#L1328 Aug 11 14:05:01 That's helpful :) Aug 11 14:05:09 Tofe: ^ Aug 11 14:10:22 you will also be missing all of the config-related code Aug 11 14:10:47 however, that's mostly relevant for jabber Aug 11 14:11:37 We have the validator getting the options from libpurple and showing them properly. But you mean that there's code to deal with that as well? Aug 11 14:11:52 We didn't test Jabber yet. AIM, ICQ, Yahoo, Skype so far :P Aug 11 14:12:57 Oh, hi filmor! Aug 11 14:14:07 hi :) Aug 11 14:14:36 well yeah, the imlibpurpleservice needs to process the config Aug 11 14:14:58 those are two separate logins and two separate implementations Aug 11 14:15:40 I changed quite a bit in the imlibpurpleservice, as it was using those dreaded c-style glib-hashtables Aug 11 14:15:44 filmor: service_name is determined by the categoryProvider template, isn't it? Aug 11 14:16:04 let me check Aug 11 14:16:52 because what I was going to do was to read the templates at the startup of imlibpurpleservice, and build up a map association between service names and their categoryprovider ids Aug 11 14:17:51 I'm not sure what use is service_name at all compared to the categoryprovider id, so far, but I didn't want to break legacy by modifying the loginstate db structure Aug 11 14:18:23 let me read your links Aug 11 14:18:28 reading the templates in imlibpurpleservice sounds "wrong" to me Aug 11 14:18:47 the templates are purely for the validator and frontend applications Aug 11 14:18:55 and they are enough Aug 11 14:19:33 well, then why is the categoryprovider used for the loginstate db Aug 11 14:19:44 (when updating the sync state) Aug 11 14:20:13 https://github.com/filmor/webos-messaging/blob/master/src/IMLoginState.cpp#L1340 <-- here it needs it Aug 11 14:21:06 not quite sure, what you are getting at Aug 11 14:21:42 I mean that just because it stores it in its loginstate db, it needs to get the categoryprovider id from the service name Aug 11 14:22:47 capabilityProvider, let me check where that one comes from Aug 11 14:22:54 Frankly I don't understand why service_name wasn't used for that field, it would have been quite as good for the db index, but legacy did it that way... Aug 11 14:26:05 The categoryProvider comes from the onEnabled callback, iirc Aug 11 14:30:25 what value does capabilityProviderId get from the frontend? Aug 11 14:30:45 ah, no, I see Aug 11 14:31:04 now, let me think what we need the service-name for ;) Aug 11 14:31:15 yeah, exactly :) Aug 11 14:32:20 hmm hmm Aug 11 14:32:51 Herrie|Pre3: we are missing quite a bunch of fixes from filmor, isn't it? Aug 11 14:33:11 Tofe: It seems so... Aug 11 14:33:50 as said, imlibpurpleservice is completely vanilla, it doesn't have any of my modifications applied Aug 11 14:34:22 looks like a mistake to me :) Aug 11 14:34:34 So we might not need due to the fact that filmor needed to do add-on on legacy and we can do some things straight at source Aug 11 14:35:09 Tofe: We should compare and pick what makes sense. Aug 11 14:35:14 Herrie|Pre3: yep Aug 11 14:35:29 Taking it 1:1 wouldn't work either I think. Aug 11 14:35:58 We'd need to update some bits to com.palm again instead of org.webosinternals for example Aug 11 14:36:05 All the service_name and capabilityProvider changes have to be reviewed, at least Aug 11 14:36:19 But most of filmor's changes should be an improvement anyway Aug 11 14:38:43 filmor: what is loginForTesting used for? Aug 11 14:38:54 link? Aug 11 14:39:02 https://github.com/filmor/webos-messaging/commit/d52787ff8b51834b0934c781f930e1ee92e2679a Aug 11 14:39:18 btw, I think serviceName was to decouple the imlibpurpleservice-code from the templates Aug 11 14:39:22 makes sense to me Aug 11 14:40:12 it's not used, at least not in any published code I could find Aug 11 14:40:23 seems to be a debugging-relic Aug 11 14:43:53 serviceName=type_jabber, capId=com.palm.messaging.facebook is an example Aug 11 14:45:05 filmor: Yeah it makes sense for things like jabber that can be used for Facebook, Google Talk etc Aug 11 15:07:20 let's summarize a bit here: com.palm.account.syncstate doesn't know anything about the "service_name" stuff, and uses capId to have several capabilities per account; but for imlibpurpleservice, having two capabilities for one account shouldn't be possible. Am I correct? Aug 11 15:08:20 yes Aug 11 15:08:26 so, about the latter Aug 11 15:08:34 don't know about the former Aug 11 15:09:21 have you tried what happens if you leave it out of the template? Aug 11 15:09:38 it could indeed be, that serviceName is completely superseded by the prpl field in the template Aug 11 15:09:56 that's kind-of what it was used for Aug 11 15:18:58 filmor: no I didn't try anything like that Aug 11 15:20:11 but one possibility that we wanted to try with Herrie|Pre3 was to do the query only with accountId + busName, the latter being something like "com.palm.imlibpurple" Aug 11 15:20:45 And therefore not needing capId at all in the syncstate db update Aug 11 15:21:43 But one question is if we still would be able to create the syncstate db entry correctly when creating the libpurple account Aug 11 15:23:24 I think we first need to do a diff between our vanilla code and your patched code, because I feel you already simplified the situation regarding this point Aug 11 15:49:02 Tofe: Yeah seems to make sense. I compared them side by side (ours and his). Diffs aren't huge in most files. Just LibpurpleAdapter.cpp seems to have a lot of big differences. Aug 11 15:53:50 no big difference for imloginstate.cpp? Aug 11 15:57:34 Well that one has quite some too :P Aug 11 15:57:51 But overall seem less shocking. Quite some seem logging & cleanup. Aug 11 15:57:59 But I only looked through briefly. Aug 11 16:03:38 yeah, a lot of those changes are due to me being unwilling to cope with GHashTable Aug 11 16:04:13 all of those casts made me nervous Aug 11 16:56:38 ok, now i'm home Aug 11 16:56:45 let's see about these changes Aug 11 16:57:22 Tofe: In most files there are small, usually logging related ones. Some have a bit bigger changes. 2 files have alot it seems Aug 11 16:57:27 At least for imlibpurpleservice Aug 11 16:58:11 I'm mostly interested in the disappearance of the SERVICENAME_XXX Aug 11 17:06:20 ah ! I knew it ! filmor already resolved the capabilityId issue in the update of the login state :) Aug 11 17:08:17 :D Aug 11 17:08:22 Let me try to merge the bits related to that Aug 11 17:11:11 Also I confirm we should be able to get rid of the loginForTesting stuff, which is just test code noise Aug 11 17:11:33 Tofe: Yeah though might be useful for testing some stuff :P Aug 11 17:11:37 If it were complete Aug 11 17:12:22 I'll propose a PR for FirstUse & LuneOS-Components to get rid of the WiFi page on emulator Aug 11 17:13:08 ok Aug 11 17:14:35 Just a slight annoyance, which was easy to fix actually :P Aug 11 17:28:00 Herrie: do we have an org.webosinternals.purple.config:1 db ? Aug 11 17:28:42 Maybe it just doesn't make sense for us now Aug 11 17:31:17 Tofe: currently not Aug 11 17:31:28 Not sure what's stored there Aug 11 17:33:16 ok I understand; actually filmor modified the properties stored for a loginstate, and now includes the capabilityProviderId Aug 11 17:34:06 We're free to do that in our kind in general Aug 11 17:34:14 Since we don't need to care about legacy for this really I think Aug 11 17:34:29 Only thing that would use it would be Messaging app I guess but could scan Aug 11 17:36:45 I shouldn't have hesitated doing that :p Aug 11 17:36:58 but merging filmor's changes is even better Aug 11 19:59:55 I've done the first part of the merge, and it's not worse than before. I removed all the usages of SERVICENAME_* in the code, so it's already some improvement here :) Aug 11 20:00:07 I'll PR that Aug 11 20:06:11 I didn't yet merge other improvements, like the char* to std::string migration or the unordered_map instead of the GHashTable. But I agree that filmor's code is more robust, and we should try merging those changes too. Aug 11 20:36:58 Nice :) I'll be sending a small PR for the config bits Aug 11 20:42:35 looks good, but can't merge :) Aug 11 20:48:06 OK done, SRCREV bumped Aug 11 20:54:07 PR for first use is tested ? Aug 11 20:56:02 Tofe: Yeah on desktop Aug 11 20:56:07 Works fine there Aug 11 20:56:12 Can test it on device if you want Aug 11 20:56:36 it's quite safe I think Aug 11 20:56:40 Yeah Aug 11 20:56:47 It's not very clean but well Aug 11 20:56:49 It works :P Aug 11 20:56:59 I'm sure they'r prettier ways Aug 11 20:57:08 But it's not horrendous either Aug 11 20:57:14 Maybe, but nothing really obvious came to my mind Aug 11 21:04:12 Yeah it's working fine ;) Aug 11 21:04:32 Could have probably removed the Wifi element instead of overwriting the whole bit but well Aug 11 21:04:36 Also more prone for errors Aug 11 21:05:22 I'm doing a test with QtWebengine now to see if I can get this one sorted: http://issues.webos-ports.org/issues/633 Aug 11 21:05:27 Should have some results in the morning Aug 11 21:05:49 https://github.com/webOS-ports/qtwebengine-chromium/commits/herrie/pwte last 2 commits Aug 11 21:05:54 Nasty but just for testing now Aug 11 21:05:59 To see if Enyo apps will then behave Aug 11 21:23:42 ok :) Aug 11 21:25:53 Because our method of putting it in the settings .in file didn't work, so decided to try this approach directly. Seems that in QtWebKit we could use settings.passwordEchoEnabled in our webview, but that's currently not available in QtWebEngine it seems. Aug 11 21:26:10 If this works we might be able to add the setting to the webview like we did for a few others. **** ENDING LOGGING AT Fri Aug 12 02:59:58 2016