**** BEGIN LOGGING AT Wed Oct 21 02:59:59 2015 Oct 21 07:15:39 hmm. i thought i'd enabled alpha and beta feeds.. must have to check to see if i misentered alpha. Oct 21 07:29:33 Andolamin: nice work! Oct 21 07:30:20 morning Oct 21 07:30:41 morning! Oct 21 07:31:27 Andolamin: I wonder, why did you need to append qtwebengine to luna-qml-launcher dependencies? It should still use only qtwebkit, if I didn't miss anything Oct 21 07:33:53 Andolamin: Indeed, we'll have a review and see what would need to be changed. I think we're currently not very happy with using submodules but that's minor. Oct 21 07:35:37 Andolamin: also, more fundamentally, why splitting it into two layers? What we do currently is that we have everything that should be common to all targets in meta-webos-ports (or even upstream), and the target-specific bits are put in meta-smartphone/xxx Oct 21 07:36:23 Also not sure why you'd use 5.3.x and 5.4.x QT patches on QT 5.5 (unless they didn't change and the version number of patch didn't get updated?) Oct 21 07:54:31 Tofe: I assume your webengine PR's are initial bits for switching luna-webappmanager to qtwebengine and shouldn't have any effect on browser currently? Oct 21 07:55:17 Herrie|Veer: yes, it fixes issues that only appear with luna-webappmanager. Shouldn't have any incidence on the browser usage. Oct 21 07:56:17 OK but we didn't migrate luna-webappmanager to webengine yet, so it shouldn't have any influence on it currently? Oct 21 07:56:48 exactly Oct 21 07:57:37 It just makes it easier for me if the fixes are already in testing Oct 21 07:57:51 Yup :) Oct 21 07:57:51 Less delta to manage Oct 21 07:58:01 Merged will kick off some nightlies shortly Oct 21 07:58:32 Ok; no hurry anyway. Oct 21 07:59:23 I detected an issue with UserScripts in the subframes (i.e. the card that is opened by a card), it doesn't seem to be executed properly, or executed at all Oct 21 07:59:44 Tofe: hmmmz Oct 21 08:00:41 But currently I don't really use the "UserScript" capability, I just do runJavaScript with the userscripts' content :) Oct 21 08:00:56 So maybe I'm just doing it wrong; we'll see Oct 21 08:04:05 Tofe: That could be ;) Oct 21 08:04:22 Had any luck in finding a culprit for crash issues? Oct 21 08:21:00 EricBlade: How's your 64GB TP doing :P? Got LuneOS up already? Oct 21 08:24:34 Herrie|Veer: I didn't analyze that yet Oct 21 08:30:27 OK and that small qtlocation test? Oct 21 09:10:36 Herrie|Veer: what qtlocation test? Oct 21 09:11:10 The one I pasted a while ago Oct 21 09:11:17 Let me send you the link. Oct 21 09:11:34 It's a C++ snippet to see if we have a source set Oct 21 09:11:50 Seems that our html5 geolocation doesn't work with qtwebengine while it should Oct 21 09:12:32 Well, the maps apps manages to see where I am Oct 21 09:13:12 but that may be a LS2 call more than HTML5 Oct 21 09:13:47 For the latter, I think we miss an authorization Oct 21 09:14:05 Tofe: No it's there... I tried :P Oct 21 09:14:12 Let me check again Oct 21 09:14:54 https://github.com/Tofee/qtwebengine/blob/dev/src/webengine/api/qquickwebengineview_p.h#L300 Oct 21 09:15:54 ah ok I see Oct 21 09:17:01 I didn't try Oct 21 09:18:15 Permission dialog works, I know the accept is OK just it never finds position while according to documentation that should work Oct 21 12:43:20 Tofe: You around? Oct 21 12:43:37 yup Oct 21 12:43:58 Was trying to complete the luneos-components migration Oct 21 12:44:17 Bit stuck how to make a stub org.nemomobile.voicecall Oct 21 12:45:47 where is it used? Oct 21 12:46:31 Try the phone app in qml creator Oct 21 12:46:41 And, also, why would you want to put it in luneos-components tests folder? Oct 21 12:47:15 It is specific to the phone app, so it wouldn't be shocking to let the stub be in the phone app too Oct 21 12:47:22 Tofe: no it can stay in phone app but should have stub Oct 21 12:48:21 ah ok, nothing blocking for luneos-components then; let me see Oct 21 12:48:50 Just I cannot test the move of other bits to luneos-components because I cannot test it without the stub for the org.nemomobile.voicecall :P Oct 21 13:07:32 at the same level as LuneOS or MeeGo folders, in test/imports, create a directory structure org/nemomobile/voicecall Oct 21 13:07:48 It's exactly like the MeeGo.QOfono stub Oct 21 13:24:03 I get either: module "org.nemomobile.voicecall" is not installed or "a component declaration requires two or three arguments, but 1 were provided" :s Oct 21 13:33:38 I just gave it a quick try, and it worked Oct 21 13:33:51 did you put the correct infos in the qmldir ? Oct 21 13:34:35 Yeah :s Oct 21 13:34:38 I'd say so :s Oct 21 13:34:55 line 1: module org.nemomobile.voicecall Oct 21 13:35:05 Tofe: I added depends on qtwebengine because builds consistently failed if qtwebengine wasn't built first. That solved the issue for me. Oct 21 13:35:16 line 2: VoiceCallManager 1.0 VoiceCallManager.qml Oct 21 13:35:29 (there's no line 3) Oct 21 13:35:57 ah so no qmltypes line? Oct 21 13:36:03 That's my mistake I guess Oct 21 13:36:06 Herrie|Veer: it's not mandatory Oct 21 13:36:52 Ah ok and what you put in VoiceCallManager.qml? Oct 21 13:37:09 Herrie|Veer: btw, during your refactoring, could you rename qml/services/VoiceCallManager.qml ? Oct 21 13:37:39 Herrie|Veer: you create an Item with only what's needed from the phone app: properties, signals, methods... Oct 21 13:38:33 Herrie|Veer: My layer is split into two (meta-rpi-luneos and meta-raspberrypi) because meta-raspberrypi *should* be able to be rebased to easily to pull in upstream changes. If Raspberry Pi becomes an official build target, I expect meta-rpi-luneos will go away and the necessary patches will be merged into the meta-webos-ports layer Oct 21 13:38:51 Also, good morning Oct 21 13:39:06 Andolamin: morning! Oct 21 13:39:30 Andolamin: ok, quite surprising it needed qtwebengine, but well. It will need it in the future anyway. Oct 21 13:40:07 Layer only works with testing, by the way. Haven't worked out all the build errors on stable Oct 21 13:40:58 Andolamin: don't bother with stable, testing is a good base Oct 21 13:43:52 Tofe: Not sure why I brought those Qt5 patches back in. I needed them for my 5.4.2 project, had removed them here, then added them back in but don't remember why... Oct 21 13:44:14 I suspect something wasn't working, but I probably don't need all the patches Oct 21 13:45:17 I'll have to try removing them again to see if anything breaks. Oct 21 13:46:18 Does the viewport on apps shrink when the keyboard is open for you guys? Not sure if the keyboard is supposed to overlay the apps or sit along side them. Oct 21 13:47:45 Andolamin: they shrink Oct 21 13:48:19 well, at least for Enyo apps Oct 21 13:48:29 Andolamin: Legacy did that too. Oct 21 14:01:44 Yeah, I thought that was the case. Wanted to verify that it wasn't a by-product of moving maliit to wayland instead of wayland-egl Oct 21 14:02:29 I'm hoping that the VC4 drivers get better quickly so we can build wayland-egl and get hardware acceleration Oct 21 14:04:34 Andolamin: today it's on bare framebuffer? Oct 21 14:06:10 I *think* some things are hardware accelerated. Anything that uses EGL or GLESv2 directly should be fine. Just no wayland-egl, so maliit (and anything else I missed that uses it) need to fall over to wayland Oct 21 14:08:39 Tofe: Seems I'm just messing up with the stub :s Oct 21 14:08:44 maybe it doesn't support some egl extension needed by wayland-egl, for example to share textures Oct 21 14:09:24 Herrie|Veer: I can begin a draft tonight :) And then you can move things to luneos-component Oct 21 14:09:28 Possibly. Not exactly sure what the problem is. I actually had wayland-egl building and *theoretically* working fine Oct 21 14:09:44 But nothing was ever shown on the screen Oct 21 14:09:56 Other people I've talked to had the same problem Oct 21 14:10:32 The Tizen guys apparently got the WIP VC4 drivers to build with wayland-egl, but I haven't found anybody who can reproduce their work. Oct 21 14:10:50 Troublesome, especially considering they released their code Oct 21 14:11:45 Tofe: Thnx that would be good. Also will start to work on adding Preware feeds to FirstUse Oct 21 14:12:46 Herrie|Veer: if you work on FirstUse, maybe you could migrate the last agreement page to WebEngine ? Should be fairly straightforward Oct 21 14:13:47 OK :) Oct 21 14:14:04 Not sure how to do the Preware feeds yet but will get my head around it. Oct 21 14:17:15 Tofe: Any thoughts on why first use and browser still don't run? Oct 21 14:17:42 Andolamin: Do you get any clues in journalctl? Oct 21 14:19:12 I didn't see anything last time I checked, but I admit I didn't dig too deeply. First concerns were getting the keyboard working and posting the layer. I'll pull it again and post it momentarily. Oct 21 14:20:58 Andolamin: I'd say it's the same wayland-egl issue, probably Oct 21 14:24:32 Tofe: Looks like I found it Oct 21 14:24:49 I'll build and try, then just need to figure out how to include the fix Oct 21 14:25:37 EXTRA_OECONF += "-qpa wayland-egl" in meta-webos-ports/meta-luneui/recipes-qt/qt5/qtbase_git.bbappend Oct 21 14:43:59 You already have a qtbase_git.bbappend, right ? Oct 21 14:47:38 Yeah Oct 21 14:47:40 Andolamin: I'm surprised you want to force wayland-egl now... didn't you try to remove it for client apps like maliit for instance? Oct 21 14:48:02 I didn't add that - that's in the webos-ports recipes Oct 21 14:48:15 oh, ok Oct 21 14:48:30 I'm changing it to "-qpa wayland" instead Oct 21 14:49:19 maybe if you simply add EXTRA_OECONF += "-qpa wayland" it would take the last one on the config line ? Oct 21 14:49:53 That's what I'm thinking Oct 21 14:51:01 JaMa: ^ Oct 21 15:03:00 Tofe: How would you go about a list with checkboxes? Regular ListModel or something else? Oct 21 15:03:11 I mean for the Preware feeds Oct 21 15:03:39 And ListModel + ListView I mean Oct 21 15:12:04 EXTRA_OECONF_remove = "-qpa wayland-egl" doesn't work? Oct 21 15:15:38 JaMa: Haven't tried it. So I would use EXTRA_OECONF_remove to remove wayland-egl, then append the new value? Oct 21 15:16:35 yes Oct 21 15:17:09 you can also use python replace function to just replace wayland-egl with wayland or just to remove -egl, but _remove + _append might be easier to use Oct 21 15:17:36 Yeah, sounds easier to read, too, Oct 21 15:18:09 Also, I tried what you said to override maliit-env.conf, but it's not pulling in my file. Can you take a look at https://github.com/Andolamin/meta-rpi-luneos/tree/master/recipes-qt/maliit and tell me what I'm doing wrong? Oct 21 15:22:16 I tried without the SRC_URI and it didn't work, so I added it just to check, but still doesn't work Oct 21 16:34:58 Is this still used? https://trello.com/b/TIZXk0xw/luna-next Oct 21 16:36:51 Andolamin: a bit Oct 21 16:37:09 Not actively Oct 21 16:37:37 OK Oct 21 16:39:29 But most todo's are still accurate Oct 21 16:39:50 I cleaned it up recently Oct 21 16:56:27 Plans to move to Enyo 2.6 once it's released? Oct 21 16:58:05 On the one hand, the new requirejs system means apps don't have to load all of Enyo if they're not going to be using it, just the bits that they need Oct 21 16:58:13 On the other hand, means all the apps have to be re-written Oct 21 16:58:46 Porting is straight forward, though (I've been working with it for about a month now). Acts just like Node. Oct 21 17:05:50 Herrie: ListModel+ListView seems perfect yes Oct 21 17:14:06 andolamin: We try to move to latest stable Enyo usually shortly after it's released Oct 21 17:14:17 I guess with all the changes in 2.6 we'll need some help ;) Oct 21 17:14:44 Might be something we could already prepare for in separate branches + latest enyo WIP for 2.6? Oct 21 17:15:38 If the intention is to move shortly after release, we should definitely prepare 2.6 porting branches for the apps and get started on them now. Oct 21 17:15:46 I'd be glad to help out Oct 21 17:17:03 That's something I guess we could tackle shortly already :) Oct 21 17:17:16 Not sure which Enyo branch to use for that? Latest? Oct 21 17:19:59 2.6.0-dev Oct 21 17:25:23 I guess I could do some initial legwork shortly Oct 21 17:25:23 I.e. create branches from master, update with Enyo 2.6.0-dev and Onyx etc Oct 21 17:25:30 I assume need the same branches for Onyx etc? Oct 21 17:30:35 Yeah, but don't update the branches and everything. Enyo 2.6.0 moves to a new developer toolchain Oct 21 17:30:36 s/branches/enyo branches Oct 21 17:30:41 You now define the versions of enyo and libraries in an .enyoconfig file Oct 21 17:30:41 Then enyo init/serve/pack handles the checkouts for you Oct 21 17:30:41 OK but for our build we need to include them, like we cannot use submodules currently Oct 21 17:30:45 Hmmm. True. For now though, I imagine we'd just be sideloading the apps to test, so we wouldn't need to update the version of Enyo used system-wide, right? Oct 21 17:30:46 Each app could just use it's own local copy of Enyo. A bit slower, yes, but adequate for porting. Oct 21 17:35:10 Andolamin: We currently distribute a copy of Enyo with each app, same for Onyx and other libs Oct 21 17:35:19 We don't use system wide, only for Enyo 1.0 apps currently Oct 21 17:35:31 Though it might be an idea to use a system wide one at some point ;) Oct 21 17:43:05 Yeah. If I remember correctly, webOS 3.0.x had a "cached" copy of Enyo preloaded in WAM, so when you launched Enyo apps you didn't have to wait for Enyo to be loaded and parsed. Are you guys doing that with Enyo 1.0? Oct 21 17:46:45 Andolamin: I doubt that, we only load it from /usr/palm/frameworks etc during load of app Oct 21 17:46:52 Might be an idea to implement some caching Oct 21 17:47:10 Tofe might know since he's currently playing with WAM for QtWebEngine migration ;) Oct 21 17:47:39 I noticed our ENyo 1.0 apps take longer to load on LuneOS compared to 3.0.x Oct 21 17:48:27 Yeah, they did quite a bit of optimization for Enyo app load there Oct 21 17:48:40 wow, didn't the discussion, wait a bit :) Oct 21 17:49:53 Caching would probably be higher priority for Enyo 2.x, rather than Enyo 1.0. Enyo 1.0 apps should eventually migrate over to Enyo 2.x with the possible exception of legacy app support, which I wouldn't place as high priority Oct 21 17:50:25 Tofe: A bit behind? ;) Oct 21 17:50:45 Ok, I don't know at all how to cache/preload some js scripts Oct 21 17:55:49 Neither do I... Oct 21 17:58:13 Herrie: here is a beginning of something: https://github.com/webOS-ports/org.webosports.app.phone/commit/0c86dcad930391d787282b4084de27326f54c7b4 Oct 21 17:58:49 Beware! For the Pin Types I don't use the enumeration exposed by OfonoSimManager! Oct 21 17:59:03 means: it won't work on device like this Oct 21 18:01:06 I has first use!!! Oct 21 18:01:23 The -qpa wayland change for qtbase fixed that issue Oct 21 18:01:24 *\o/* Oct 21 18:01:35 ok, that makes sense Oct 21 18:02:20 Now just need to figure out why my bbappend broke qtwebengine builds Oct 21 18:02:37 Tofe: Thnx. Not sure I understand your comment about Pin Types Oct 21 18:02:46 Will probably create a new qtbase_git.bbappend instead of using the qtbase_%.bbappend that I have right now. Oct 21 18:03:02 Herrie|Laptop: well, currently it mainly means that the code in my branch won't work on device Oct 21 18:03:13 I'm not even 100% convinced I need that qtbase_%.bbappend, so I may just remove it to see how it goes Oct 21 18:03:42 I'm trying to figure out how to solve that without modifying MeeGo.Ofono Oct 21 18:04:10 Tofe: Ah OK Oct 21 18:12:00 No virtual keyboard in first use... Checking journalctl now Oct 21 18:13:56 Herrie|Laptop: I think you can now use my branch as a starting point Oct 21 18:14:04 it should work both on desktop and device Oct 21 18:14:24 well, it doesn't really work on desktop yet, but there are no QML errors at least :p Oct 21 18:16:54 Tofe: OK thnx Oct 21 18:17:43 Browser doesn't launch, either... Oct 21 18:18:28 Tofe: LunaAppManager[386]: QWebEngine: OpenGL resource sharing is not set up in QtQuick. Please make sure to call QtWebEngine::initialize() in your main() function Oct 21 18:19:00 Immediately followed by Received SIGCHLD from PID 825 (QtWebEngineProc) Oct 21 18:28:14 Andolamin: You might want to update browser to: https://github.com/webOS-ports/org.webosports.app.browser/commit/ab2d51c3d6d30f51c586be37c3b013e3a5d618ab Oct 21 18:28:22 Or newer Oct 21 18:28:29 And also take latest luna-qmllauncher Oct 21 18:28:35 We updated those recently Oct 21 18:28:43 Because browser wouldn't launch for us either Oct 21 18:30:12 See https://github.com/webOS-ports/luna-qml-launcher/commits/master Oct 21 18:31:03 OK. I'll try that Oct 21 18:32:24 Because those error messages look veyr familiar to me :P Oct 21 18:32:43 That's a good thing Oct 21 18:32:58 I'd rather the issue be something that is across everything, not just RPi specific Oct 21 18:34:08 Herrie, what do you think about https://github.com/Andolamin/meta-rpi-luneos/issues/3? Reasonable? Oct 21 18:36:28 Andolamin: Sounds reasonable in general. Shouldn't be too hard to accomplish in QML Oct 21 18:36:42 I thought the same Oct 21 18:36:44 Eventually I'd like to have a nicer looking system/device menu anyway ;) Oct 21 18:36:56 I always like Choorp's New Device Menu in 2.x ;) Oct 21 18:38:44 http://webos-ports.org/wiki/Luna_Next#Features Oct 21 18:38:50 Not my style. But yeah, a new one would be good. Especially if/when we unify the UI components. The current style wouldn't match. Oct 21 18:39:23 Andolamin: It's a lot better compared to 2.x and 3.x default one to use ;) Oct 21 18:39:51 I guess the rpi doesn't have a physical button to power off like a phone or tablet? Oct 21 18:40:14 We do have a power menu build in that's triggered by the power button ;) Oct 21 18:41:14 Yeah, no button to use, so it would have to go into the system menuy Oct 21 18:41:20 s/menuy/menu Oct 21 18:41:54 Andolamin: OK Oct 21 18:42:01 Relatively easy to do Oct 21 18:42:06 QML is flexible Oct 21 18:42:18 You'd just need to detect it's a Pi and adjust accordinly Oct 21 18:42:30 What's the repo? I can probably make the changes Oct 21 18:42:44 https://github.com/webos-ports/luna-next-cardshell/ Oct 21 18:43:00 You cna run it in QtCreator, it has stubs for most things on device :) Oct 21 18:43:06 So pretty easy to test stuff :D Oct 21 18:43:37 You'd want to look at: https://github.com/webOS-ports/luna-next-cardshell/tree/master/qml/StatusBar/SystemMenu Oct 21 18:43:59 It's all a bit more structured and easier to find compared to legacy lunasysmgr Qt C++ :P Oct 21 18:59:20 Ok, RPi dpi is <2 off from original TouchPad, so I'll probably use 10 for the grid unit to match Oct 21 19:08:30 Andolamin: That sounds like a plan Oct 21 19:08:44 The idea is that GridUnits are like "flexible" pixels Oct 21 19:09:36 Herrie|Laptop: yes, we can think "millimeters" with GridUnits, quite handy when dealing with a touch UI Oct 21 19:09:48 So you get an uniform experience across various targets. I.e. elements should look similarly no matter what the resolution Oct 21 19:10:00 Tofe: Yeah Oct 21 19:10:32 Andolamin: what screen are you using ? Is it one that is bundled with RPi by default? Oct 21 19:11:21 (or let's say, proposed by the RPi organization) Oct 21 19:12:14 That's the one. Sold separately right now, but officially supported for the RPi. http://www.element14.com/community/docs/DOC-78156?ICID=hp-7inchpidisplay-ban Oct 21 19:13:12 It works well, doesn't require a USB cable for the touch screen and frees up the HDMI to theoretically drive a second display. Oct 21 19:13:27 Viewing angles could use some improvement, though. Oct 21 19:13:49 Especially when you view the screen from above Oct 21 19:18:10 I'll post the full hardware list that I'm using (Pi, Display, Frame, WiFi adapter, Bluetooth adapter) to the repo wiki later today. Oct 21 19:20:05 I want to keep track of the wifi/bluetooth adapters and displays that work with it. Oct 21 19:21:31 Does your BT work with connmanctl enable bluetooth? Oct 21 19:24:25 ok Oct 21 19:24:30 With "work" I mean powers on ;) Oct 21 19:24:48 Tp = 1024 * 768 Oct 21 19:24:58 I think your screen has a different resolution? Oct 21 19:25:09 TP Go = 1024 * 768 on 7" too Oct 21 19:31:53 Herrie: yes Oct 21 19:32:02 And the resolution is 800x480 Oct 21 19:32:51 TP is 131.96 dpi, RPi is 133.28 Oct 21 19:39:04 Ah OK Oct 21 19:40:21 Should be close enough then. Not sure what value you had before? Oct 21 19:45:06 Not at all. I didn't deploy a raspberrypi conf file Oct 21 19:49:15 Ah ;) Oct 21 19:49:50 We basically try to use this in QML where we can :) Oct 21 19:50:08 So when we ported TP QML bits we took pixel value/10 ;) Oct 21 19:50:57 I love the windsornot conf Oct 21 19:52:06 I got to play with one the other day, actually Oct 21 19:52:29 Trying to wrangle it into my collection Oct 21 19:52:33 Hehe Oct 21 19:52:44 Got quite a few Go's laying around here Oct 21 19:52:55 Yeah, I have 2 Oct 21 19:53:08 Got some connections in China who could pick them up from TaoBao (CHinese eBay) for me :P Oct 21 19:53:29 Both mine were found in boxes around the office Oct 21 19:57:32 They're nice little devices too bad they were never released Oct 21 19:57:41 Would love to see LuneOS run on it ;) Oct 21 19:58:11 Could've made a difference for webOS as a whole... There weren't any similar spec 7" tablets around at that time Oct 21 20:21:11 Herrie: I think they were a little bulky. But if they had slimmed them down a bit then absolutely. Oct 21 21:11:27 Herrie, FYI: I'm going to work on completing/updating Mochi. I'm going to go through everything and port it to Enyo 2.6, then I'll work on completing the 'light' theme components, then add dark theme, then do the same for QML. Oct 21 21:11:58 I'll track my progress at https://alanstice.com/luneos/mochi.html **** ENDING LOGGING AT Thu Oct 22 02:59:58 2015