**** BEGIN LOGGING AT Sun Jan 31 02:59:58 2016 Jan 31 07:42:37 morning Jan 31 07:42:43 nizovn: ping Jan 31 08:04:51 Morning: Jan 31 08:05:14 (Automatic : !) Jan 31 08:05:43 Herrie: Am I supposed to hear the ringtone if my N4 receives a phone call? Jan 31 08:06:18 Herrie: I mean, now rather than in principle ;) Jan 31 08:09:28 Herrie: pong Jan 31 08:20:46 * DougReeder waves insomniacly Jan 31 09:59:44 elvispre: I think we don't have that hooked up yet, so it's correct you don't hear anything yet ;) Jan 31 09:59:48 Tofe: ^ ;) Jan 31 10:00:19 nizovn|TP: Seems we might have some large chunk of c++ code to review shortly ;) iscgar has been cleaning up certmgr Jan 31 10:01:12 ok Jan 31 10:04:53 Herrie, elvispre: no ringtone right now, it's just not implemented :) Not really hard to do, though. Jan 31 10:05:10 Morning! Jan 31 10:05:43 Herrie: I've been thinking about this phonenumber issue Jan 31 10:07:35 And, either I find a way to include enyo.g11n into qml and we get like 20 countries covered, or we try to use libphonenumber from Google (Apache-2.0 licenced) everywhere, and we get the whole world covered and up-to-date Jan 31 10:07:45 Tofe: Herrie: That's alright then. I have implemented [default] ringtone picking in Settings and wasn't sure if I had broken it or not. Jan 31 10:09:23 elvispre|s: I noticed that the scrolling in the filepicker is broken though. It's probably not your implementation, but a generic issue Jan 31 10:09:54 Tofe: Whole world, covered & up-to-date sounds like a nicer alternative :P Jan 31 10:10:15 I think in contacts & messaging we probably just need basic formatting, nothing too extensive Jan 31 10:10:40 Herrie: It doesn't respect the launch category - e.g. "audio" - either. I may take a look at it. Jan 31 10:10:41 So distinguish between countrycode, city/region/operator code and subscriber number Jan 31 10:10:41 Herrie: well, they also read&store the normalized phone number in the db Jan 31 10:11:47 Herrie: Filepicker is in webos-lib. Jan 31 10:21:26 Ah, Google's implementation uses Protobuf and Closure ... Has someone here used that before? Jan 31 10:28:24 An opinion about https://github.com/seegno/google-libphonenumber ? Jan 31 10:29:29 Up-to-date, contains the browser-independant and minimized versions, together with the build scripts used there Jan 31 10:33:37 Tofe: On initial view looks good to me Jan 31 10:33:49 But I'm sure DougReeder or others might have an opinion Jan 31 11:07:46 Herrie: I've been able to use it inside QML, at least. Using a non-modified version of this js file: https://github.com/seegno/google-libphonenumber/tree/master/dist Jan 31 11:08:07 (which is a standalone js file) Jan 31 11:08:35 So the status is already better than telephony-lib, actually :p Jan 31 11:09:27 What I've done is executing the little test code suggested by the guy, and it ouputs the correct result Jan 31 11:23:54 Tofe: nice :) Jan 31 11:27:49 Here's what I can get now: "qml: normalizePhoneNumber(0032661583265)=-562385166--23-+" Jan 31 11:28:31 Which is already compatible with Enyo g11n I think Jan 31 11:32:57 Tofe: Yeah I remember the number was stored funnily ;) Jan 31 11:33:29 It's pretty easy to find the formatting in legacy's phone source code Jan 31 11:33:45 Tofe: Yeah the legacy code is pretty easy to read most of the times Jan 31 11:33:50 It helps it's JS for me :P Jan 31 11:33:52 And not C++ Jan 31 11:33:56 I think it's to easy saerching in db8 with "%" operator Jan 31 11:35:30 One sad thing I just found is that the JS version of libphonenumber doesn't have geo-location right now Jan 31 11:37:08 Also, frankly, maybe we could add that ourselves, given the very easy format of google's database Jan 31 11:37:23 |"location" Jan 31 11:39:58 Yeah, I could do that Jan 31 11:40:46 A little script that would fetch all these resources, and put them as JSON one or several files Jan 31 11:40:49 +in Jan 31 11:42:22 Should we put that in db8 somehow? Jan 31 11:50:18 Tofe: Yeah I'm not sure why it was stored in files before. DB8 might make sense? Should be a bit quicker performance wise? Jan 31 11:51:38 Herrie: well, it's static data, to be shared in the whole OS, Db8 seems the natural choice Jan 31 11:52:04 It would also be easier to update automagically from an online resource Jan 31 11:55:56 Tofe: Yeah that's what I'm thinking as well Jan 31 12:23:19 Herrie: one little tricky question: I have taken the JS file from https://github.com/seegno/google-libphonenumber/tree/master/dist, whose project is under MIT licensed. However the libphonenumber project from which the JS is built is under Apache-2.0. What is the license of the JS file ? :) **** BEGIN LOGGING AT Sun Jan 31 12:28:53 2016 Jan 31 12:36:27 Herrie: https://github.com/Tofee/luneos-components/tree/tofe/work/modules/LuneOS/Telephony/geocoding Jan 31 12:38:36 Tofe: Depends a bit Jan 31 12:39:03 If you only took that JS file and it's unmodified from Google source I'd say it's fine with Apache 2.0 Jan 31 12:39:17 If it's modified as part of the project, I'd say you'd have to use MIT Jan 31 12:40:06 Well, it's Google's code, but compiled, so it will include its own dependencies, and be stripped of comments. But the compiler is ant, so Google's too. Jan 31 12:40:54 I'd say since it's part of the "seegno" repo, you'd be safe with the MIT Jan 31 12:40:57 It's probably Apache-2.0 Jan 31 12:41:16 well, Apache-2.0 is more restrictive, isn't it Jan 31 12:41:18 The repo owner has Apache 2.0 mentioned at the bottom of the license Jan 31 12:41:35 yes, for the dependencies Jan 31 12:41:36 Tofe: https://www.quora.com/Whats-the-different-between-Apache-v2-0-and-MIT-license Jan 31 12:41:47 Nothing that we should be worried about for this probably Jan 31 12:42:26 As long as we don't brand it Google something we should be OK I guess :P Jan 31 12:42:41 :) Jan 31 12:43:01 https://github.com/Tofee/luneos-components/blob/tofe/work/modules/LuneOS/Telephony/LICENSE ? Jan 31 12:43:33 Looks OK to me I'd sya Jan 31 12:43:37 But I'm not expert Jan 31 12:43:48 KyleMaas might have some ideas when he's around later Jan 31 12:44:16 It's no big deal anyway, both are probably ok Jan 31 12:45:13 But I wanted to make a reference to the project from which the file was taken, just in case Jan 31 12:45:24 Yeah that's always good Jan 31 12:46:10 I've forked it on my account, too, so that we won't be taken aback if he deletes his account suddently :p Jan 31 13:38:05 Tofe, Herrie: IANAL and nothing I say on the subject of licensing is to be construed as legal advice, but here's the Apache project's opinion on the subject of license compatibility: http://apache.org/legal/resolved.html#category-a Jan 31 13:40:42 I like seeing a LICENSE or COPYING file like Tofe's where the licensing is all listed out in one place. I strongly dislike when projects have compatible-but-different licenses for dependencies scattered in source files throughout their project. That just seems really messy. Jan 31 13:40:50 But, like I said, that's my opinion. Jan 31 13:43:06 This chart by David A. Wheeler seems to be a good general reference: https://commons.wikimedia.org/wiki/File:Floss-license-slide-image.png Jan 31 13:43:15 Ok, so, let's just keep it like that. It would take a rather annoying person to criticize our approach :) Jan 31 14:26:16 The FilePicker available to enyo 2 apps via webos-lib Jan 31 14:26:22 https://github.com/webOS-ports/webos-lib/blob/master/source/FilePicker.js Jan 31 14:26:29 is an enyo 1 "cross app UI" passed params and mediated by Jan 31 14:26:35 https://github.com/webOS-ports/webos-lib/blob/master/source/CrossAppUI.js#L14 Jan 31 14:26:41 The FilePicker itself is in luna-systemui. Jan 31 14:26:47 So far as I can tell, the params do not reach it. I tried putting some logging in here Jan 31 14:26:53 https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/app/FilePicker/FilePickerApp.js#L81 Jan 31 14:27:00 but that (this.log) did not do anything so I have to rely on how the picker behaves (just picks all possible file types all the time). Jan 31 14:27:06 I would raise an Issue but I don't know what to raise it against. Jan 31 14:27:11 WebAppManager perhaps? Jan 31 14:36:52 elvispre: maybe yes Jan 31 16:03:19 The devil is in the details (which I don’t know here) so do whatever makes sense, Herrie & Tofe. Jan 31 18:02:00 Tofe: I assume you build tested the luneos-components PR? Jan 31 18:04:35 I fixed my PR in extreme urgency, but yes, it can safely be merged, now. Jan 31 18:14:38 Herrie: with the new libphonenumber.js, loading the phone app has become much slower... Jan 31 18:57:30 Tofe: Hmmz that's not so good.... I'll kick off a new nightly with all the various changes and test it on N4 and Maguro once it's ready Jan 31 18:57:36 See if it's acceptable or too slow Jan 31 18:57:48 For me it's too slow Jan 31 18:58:04 5s to start, for a simple QML app... Jan 31 18:58:20 (and an essential one) Jan 31 18:59:16 But 400k of javascript are sure a bit heavy for the QML JS engine Jan 31 19:06:50 400k for just phone number logics :S ? Jan 31 19:10:43 well, phone logic for almost all countries in the world Jan 31 19:10:52 and not minimized Jan 31 19:11:46 but it's still 345k minimized, I guess the data makes most of it Jan 31 19:18:31 Maybe it's just not the right design choice, and we should fallback on another solution Jan 31 19:32:25 Hi guys! Jan 31 19:55:48 * DougReeder waves hello, belatedly Jan 31 20:44:48 elvispre: ping Jan 31 20:45:40 nizovn: pong Jan 31 20:46:15 seems i fixed wifi & bt plugins Jan 31 20:46:26 but this need some modification to settings app Jan 31 20:46:47 nizovn: Yes, I would expect that. Jan 31 20:47:08 Can I pull the plugin changes from somewhere? Jan 31 20:48:01 elvispre: https://github.com/nizovn/luna-webappmanager/tree/bt_wifi Jan 31 20:48:39 my debugging code for settings: https://github.com/nizovn/org.webosports.app.settings/commits/bt_wifi Jan 31 20:48:49 i guess you would like to improve it Jan 31 20:50:09 nizovn: :) Thanks. I'll take a look at those soon. (Might not be till tomorrow.) Jan 31 20:51:23 as for path of hidden network, you should search for it in foundNetworks, it should have empty name, and wanted security Jan 31 20:52:31 btw i think we shouldn't show hidden networks in common list(they are without title) Jan 31 21:00:05 nizovn: So the hidden ones *are* in the list. I agree that they should not be listed unless actually connected. Jan 31 21:01:15 yes, ok **** ENDING LOGGING AT Mon Feb 01 02:59:58 2016