**** BEGIN LOGGING AT Wed Jan 21 02:59:58 2015 Jan 21 06:40:09 Cage1___: morning Jan 21 06:41:32 Morgen Jan 21 06:44:48 Managed to get the messaging app running on emulator? Jan 21 06:49:00 Only using mock data but not with the services Jan 21 06:51:52 Ah ok Jan 21 06:52:51 Unfortunately hard to debug what's happening Jan 21 08:33:17 Cage1___: you got the inspector up and running? Jan 21 08:33:57 Herrie: no, only for settings so far Jan 21 08:45:10 DougReeder: how are we going forward with 757? Jan 21 08:54:56 Garfonso: I think I know what the the problem is you see with the InAppBrowser Jan 21 08:55:41 the CrossAppTarget is loaded in its own frame but the InAppBrowser extension only calls the setTitle method on the top frame Jan 21 09:02:45 hm.. I'll look into that. Jan 21 09:05:12 we somehow need to forward the call to the right frame where it came from Jan 21 09:06:53 btw: is there a way to get the current URL of the InAppBrowser? ;) Jan 21 09:08:06 no, not yet Jan 21 09:08:11 Garfonso: do you need it? Jan 21 09:08:43 I use that in MoboReader, not sure I really need it. Investigating. :) Jan 21 09:09:48 can add that Jan 21 09:11:24 ok, I don't really need it. But maybe some other people might need it. Those solutions usually offer the url.. if it is not too hard. Maybe just add it in the title changed callback? Jan 21 09:12:35 btw: on the emulator (i.e. in landscape mode) the InAppBrowser window scrolls quite strange if you tap on an text-input. Jan 21 09:12:51 hm Jan 21 09:13:00 Not sure if this is a general issue... but it seems to scroll the input into the center of the screen, which is 50% behind the keyboard. Jan 21 09:16:28 Garfonso: one downside of the current implementation is that you can only have on InAppBrowser per the whole frame hierachie Jan 21 09:16:47 yes, I saw that. Jan 21 09:17:17 I just tested and InAppBrowser works in MoboReader. :) So the iframe seems to be the issue. Jan 21 09:19:11 yeah Jan 21 09:19:30 I am adding a frame identifier now so that you get the callback called in the frame where you called open Jan 21 09:20:19 doesn't really like this but with our limited capabilities that is the best solution atm Jan 21 09:23:21 just segfaulted webappmanager :-/ Jan 21 09:24:20 hm Jan 21 09:26:39 we will have a crash reporter soon to catch those and have proper information to find out why Jan 21 09:27:20 CrossAppUI: checkLoad: things look okay. enyo-build.js:6456 Jan 21 09:27:20 Checking all frames for accountManager_AccountsView_customAccountsUI_crossAppUI about:blank:16 Jan 21 09:27:20 accountManager_AccountsView_customAccountsUI_crossAppUI about:blank:18 Jan 21 09:27:20 Found it [object Navigator] about:blank:21 Jan 21 09:27:20 Title changed: Sign in - Google Accounts CrossAppTarget.js:72 Jan 21 09:27:21 Got response: "Sign in - Google Accounts" Jan 21 09:27:26 looks like it works now Jan 21 09:27:28 morning Jan 21 09:27:37 great. :) Jan 21 09:27:42 Herrie|Veer: morning Jan 21 09:29:10 morphis: I was looking into bringing DockMode (clock to start with) back (seems fairly straight forward) but might need some help on C-side of things it seems Jan 21 09:29:14 btw: I can't launch settings on my N4. Is this a known issue? Jan 21 09:29:56 I was thinking single short power press enables dockmode, 2nd single press turns off screen (or make it customizable via Tweaks). Wanted to check with you if feasible approach Jan 21 09:30:00 Garfonso: yeah it is and fixed Jan 21 09:30:08 ah. :) Jan 21 09:30:27 Garfonso: ok, I get the "Got access token" lines in the inspector now Jan 21 09:30:46 it doesn't close the InAppBrowser yet but it seems like you're never calling InAppBrowser.close Jan 21 09:30:57 yes, that's true. Jan 21 09:32:18 morphis: done closes the InAppBrowser anyway, right? Jan 21 09:32:26 Garfonso: right Jan 21 09:32:27 Garfonso: https://github.com/webOS-ports/luna-webappmanager/pull/11 Jan 21 09:32:59 I can add the url change notification later on Jan 21 09:33:51 Herrie|Veer: what will be the trigger for the dockmode? Jan 21 09:34:21 morphis: I guess it should be charging Jan 21 09:34:48 We don't have Touchstone like charging method Jan 21 09:34:49 So charging & single power press = dockmode Jan 21 09:35:04 charging & in dockmode + power press = screen off Jan 21 09:35:10 Garfonso: builds with that change included running now Jan 21 09:35:24 Or Directly screen off based on Tweaks setting? Jan 21 09:35:29 Just thinking out loud now Jan 21 09:35:32 Herrie|Veer: can you document those requirements in a ticket? Jan 21 09:35:37 ah. Great. :) Jan 21 09:35:49 btw my builds still fail with the same error. :-( Jan 21 09:35:59 morphis: I could just not 100% sure how this is currently handled Jan 21 09:36:00 Garfonso: you asked JaMa? Jan 21 09:36:15 I mean power button presses etc Jan 21 09:36:16 Herrie|Veer: apps can be loaded on the dock screen, right? Jan 21 09:36:22 didn't meet him the last days. Jan 21 09:36:35 I see cardshell deals with the long power press Jan 21 09:36:52 But the short ones seem to be done elsewhere or I missed something? Jan 21 09:36:53 Garfonso: you tried resetting your environment? Jan 21 09:37:02 aka a rm -rf tmp-glibc? Jan 21 09:37:04 morphis: Yeah based on appinfo.json value Jan 21 09:37:34 Herrie|Veer: power key detection should be done by LunaSysMgr Jan 21 09:37:37 morphis: yes. Jan 21 09:37:41 which then sends out the signals to others Jan 21 09:39:42 Garfonso: btw. I rebased your cdav branch Jan 21 09:43:07 oh, ok. Thanks. :) Jan 21 10:18:44 Herrie|Veer: you already had time for the sounds? Jan 21 10:19:58 morphis: Hopefully tonight Jan 21 10:20:20 Need to index which ones are used and assign them to the right actions Jan 21 10:21:10 Herrie|Veer: great Jan 21 10:21:14 morphis: Can we have lunasysmgr behave differently based on a Tweaks setting? Jan 21 10:21:25 Herrie|Veer: why? Jan 21 10:22:34 Quickest fix for dockmode would be to change the bool DisplayManager::isOnPuck() in DisplayManager.cpp to only check for connected charger Jan 21 10:23:09 But that would mean it goes to dockmode always when you press power button and are charging Jan 21 10:31:55 Herrie|Veer: yeah Jan 21 10:32:36 We might want to make that a Tweaks option somehow hence my question Jan 21 10:38:50 hm Jan 21 10:38:57 let me look at the code for this Jan 21 10:38:58 DougReeder: ping Jan 21 11:11:14 Herrie|Veer: it looks a bit more complex with all the code we have for that in the DisplayManager Jan 21 11:11:24 so it is not an easy thing to add Jan 21 11:13:27 Is this a simple binary that you could build for me for N4 with just this change and I'll test it from there? I think we're fairly OK with rest of "puck" behavior :P Jan 21 11:16:05 are you sure? Jan 21 11:16:13 the state machine for that is quite complex Jan 21 11:17:52 Garfonso: http://issues.webos-ports.org/issues/825 Jan 21 11:18:21 Hence I'd like to test :P Jan 21 11:18:36 But could setup my own dev environment again too Jan 21 11:18:56 Need to do that anyway after reinstalling and upgrading to the 4TB array :P Jan 21 11:19:34 let me build one for you then Jan 21 11:24:40 morphis: just the filename changed? Jan 21 12:35:26 Garfonso: yes Jan 21 14:19:33 morphis: pong Jan 21 14:21:04 DougReeder: you know the window.postMessage method? Jan 21 14:21:26 Morphis, I’m thinking to finish 821 first Jan 21 14:21:40 I know of postMessage; havn’t needed it yet. Jan 21 14:21:45 ok Jan 21 14:22:10 we have a bug within the accounts app where templates are passed between the frames via postMessage Jan 21 14:22:47 to rule out the fact that it's a problem with webkit rathern than with enyo-1.0 just wanted to ask you if (after 821) you can write a small test case for it within the testr app Jan 21 14:25:59 To test that postMessage correctly does what? Jan 21 14:26:10 Pass mesages between frames? Jan 21 14:26:47 Which lines of the Accounts app - it should be closely based on that, if it’s to be a good test. Jan 21 14:30:21 DougReeder: https://github.com/webOS-ports/enyo-1.0/blob/master/framework/source/palm/system/windows/windows.js#L297 Jan 21 14:30:34 the window parameters never arrive on the other side Jan 21 14:30:50 but the cross app communication uses it for other scenarios and there it works fine Jan 21 14:31:12 see http://issues.webos-ports.org/issues/591 Jan 21 14:31:16 How is the second window created? Jan 21 14:31:21 really want this to be fixed before we do the next release Jan 21 14:31:28 DougReeder: it is a frame in this case Jan 21 14:31:39 Garfonso: can also comment on this Jan 21 14:32:01 DougReeder: https://github.com/webOS-ports/enyo-1.0/blob/master/framework/source/palm/system/CrossAppUI.js Jan 21 14:32:32 DougReeder: but don't want to interrupt you :) Jan 21 14:34:19 It looks like we’d need to recreate the key aspects of the Enyo 1 CrossAppUI control. Jan 21 14:34:36 for the test case? Jan 21 14:34:45 Yes. Jan 21 14:34:50 yes Jan 21 14:34:56 I would like to start with a simple one Jan 21 14:35:03 just an iframe and passing messages around Jan 21 14:35:17 * DougReeder nods Jan 21 14:35:17 if that works we need to go further down into the enyo1 framework and see what is wrong there Jan 21 14:36:30 I could probably whip up a simple IFRAME test case before finishing 821. Jan 21 14:36:38 that would be nice Jan 21 14:37:21 Might not have time until the weekend, though - JavaScript user group is tonight! Jan 21 14:37:38 :) Jan 21 14:38:13 You should probably add those URLs to the issue. Jan 21 14:38:59 will do that Jan 21 16:22:18 JaMa: builds on my machine (ubuntu 14.04, 64bit) fail, because they try to compile gstreamer1.0-plugins-bad_1.4.1.bb (which complains about missing object c compiler). Any idea how to fix that? Jan 21 16:22:31 from what I understood this package should not be compiled at all. Jan 21 16:24:15 can you pastebin whole error Jan 21 16:24:26 Garfonso: no the package, but it should not be build with Mac support Jan 21 16:30:51 JaMa: https://bpaste.net/show/3aa64e5c156a Jan 21 16:31:20 hm. Jan 21 16:33:43 doesn't look familiar but as morphis said, we can compare log.do_configure to see what got autoenabled in your build and explicitly disable that Jan 21 16:35:05 JaMa: yeah Jan 21 16:35:18 Garfonso: you're building on ubuntu, right? Jan 21 16:35:27 yes. ubuntu 14.04 Jan 21 16:39:10 contents of log.do_configure for that package: https://bpaste.net/show/26b00d202ca4 Jan 21 16:45:32 rebuilding now Jan 21 17:25:23 morphis: just noticed your comment: # Fix builds with new -ferpmissive set by default Jan 21 17:26:05 it's quite misleading, because the build errors are caused withOUT OLD -fPERmissive :) Jan 21 17:41:35 JaMa: ah sorry Jan 21 17:57:36 Garfonso: this is the most suspicious part: Jan 21 17:57:38 -checking for gnustep-config... /usr/bin/gnustep-config Jan 21 17:57:38 -checking for GNUstep... yes Jan 21 17:57:47 +checking for gnustep-config... no Jan 21 17:57:48 +checking for GNUstep... no Jan 21 17:58:07 other than that your configure just shows also valgrind detected Jan 21 17:58:53 so adding PACKAGECONFIG[gnustep] is in order especially as it detects gnustep from host not sysroot Jan 21 18:12:28 so a quick and dirty fix would be to remove gnustep from the system? ;) Jan 21 18:16:33 PACKAGECONFIG[gnustep] = "--enable-cocoa,--disable-cocoa,cocoa" # we don't have cocoa recipe Jan 21 18:16:46 add this line to the recipe and you're good Jan 21 18:16:56 you can also send it to oe-core ML for special bonus Jan 21 18:17:13 or I'll do it after you confirm it helped Jan 21 20:05:50 JaMa: worked. :) Jan 21 21:03:42 Garfonso: good boy! :) Jan 21 21:04:24 heh oe-core already has fix for that as well Jan 21 21:04:44 so you can also cherry-pick this to your oe-core checkout e526f5633669819417ef975c49d07fff8f35b91b Jan 21 21:42:20 morphis: added issue for the displaymanager/dockmode stuff Jan 21 21:42:29 Got it working quite OK and nice looking on N4 now :D Jan 21 21:42:33 In all 3 variants Jan 21 21:42:49 Needed some QML tweaking and still need to test on TP, but it looks good so far on N4 Jan 21 22:17:08 Herrie: can you push the code? Jan 21 22:17:13 can test it with your code then **** BEGIN LOGGING AT Thu Jan 22 01:55:47 2015 **** ENDING LOGGING AT Thu Jan 22 02:59:59 2015