**** BEGIN LOGGING AT Sun Aug 30 02:59:58 2015 Aug 30 09:17:48 Morning Aug 30 09:21:23 Tofe: morning Aug 30 09:21:53 Herrie|2: I am investigating that weird look of the dashboard Aug 30 09:22:29 And I'm wondering, do you know the meta tag "viewport" ? I'm not sure what it does, and if that would help Aug 30 09:23:53 My current hypothesis is that the WebView of the dashboard tries to guess a viewport size (it might be before or after we set the size of the dashboard card), and if that size is too high and if we then set the height to a lower value it will shrink the content Aug 30 09:23:57 Not sure though Aug 30 09:42:59 Tofe: I'm not very familiar with viewport Aug 30 09:43:18 I have seen some experimental preference for the webview i think Aug 30 09:43:43 Ah no... No experimental it seems Aug 30 09:44:19 yes, there is the flickable=false thing Aug 30 09:44:47 which tells WebView to not act as a Flickable, but to forward all mouse events to the webpage Aug 30 09:45:02 Unfortunately, this will result in WebView ignoring the viewport meta tag Aug 30 09:53:34 Tofe: btw some time ago i thought to use this tag in webappmanager to solve flickable issue, do you thing it's possible? Aug 30 09:54:11 nizovn: it's already used Aug 30 09:54:18 by default, flickable=false Aug 30 09:54:52 you can set it to true in appinfo.json Aug 30 09:56:03 iirc webappmanager uses "setflickableviewportenabled" function that changes flickable property of all webviews Aug 30 09:56:33 so it's not possible to have one flickable and another non-flickable card Aug 30 09:57:49 well, more precisely, it does setFlickableViewportEnabled(mApplication->desc().flickable()); Aug 30 09:58:26 so it should be card-specific Aug 30 09:58:46 no, it's global(static) function Aug 30 09:59:19 ah yes. Then the code is buggy Aug 30 09:59:48 Maybe it was correct when we used one process per card Aug 30 10:00:02 and then we went back to one process, and it became incorrect Aug 30 10:00:31 i thought to somehow "inject" viewport tag to webview. do you think it's possible? Aug 30 10:04:27 nizovn: it's possible, but the problem is that the Enyo apps already use it Aug 30 10:10:14 so enyo apps(or enyo2?) set flickable to false explicitly? and they will not scroll if use setflickableviewportenabled(true)? Aug 30 10:12:23 enyo apps set the viewport explicitely yes. However, most (all?) of them have flickable=false, resulting in WebView ignoring the viewport meta tag. Hum. Aug 30 10:15:19 I'll try to hack a bit the viewpoint and appinfo of Maps, to see if it helps Aug 30 10:15:31 viewport* Aug 30 10:16:34 hacking appinfo will not work, it's passing incorrectly to webappmanager Aug 30 10:17:37 huh? Aug 30 10:17:57 let me find info in logs Aug 30 10:22:11 http://logs.nslu2-linux.org/livelogs/webos-ports/webos-ports.20150517.txt Aug 30 10:22:36 we need to pass appdesc directly to webappmanager for now Aug 30 10:23:10 for testing, we can use luna-send -n 1 palm://org.webosports.webappmanager/launchApp Aug 30 10:24:50 nizovn: ok, I wronly thought webappmanager was reading the appinfo himself Aug 30 10:46:55 Merging both appdescription and moving it to luna-sysmgr-common would be a good thing Aug 30 10:47:07 I has already begun to diverge Aug 30 10:47:10 ok, it's helpful to look sometimes into qt code :) i'm going to use their scrollindicator in our browser(will be like on legacy) Aug 30 10:50:13 Tofe: yeah, morphis also suggested to adjust webview sources to implement flickable correctly. just think maybe using viewport tag may be much simpler. Aug 30 10:53:21 nizovn: if it works, yes, the viewport tag may be better. Aug 30 11:02:07 ok, this gets a bit ugly: there *is* an ApplicationDescription class in the -common repo Aug 30 11:02:37 And there is also an ApplicationDescriptionBase class, which should be the way to go I think Aug 30 11:04:13 ah no, sorry, looked at the wrong branch. There's only the Base one. Good. Aug 30 11:11:31 Tofe: you are right, seems we can remove ApplicationDescription.cpp from common Aug 30 11:15:31 yes, I'm currently working on that Aug 30 14:46:32 Ok, I have a set of 3 PR to propose (luna-webappmanager, luna-appmanager and luna-sysmgr-common), but before that I'll test a bit :) Aug 30 14:55:14 Tofe: Nice :D Aug 30 14:57:07 At first sight, it doesn't seem like I broke anything speical. But I saw a warning from WebAppManager that might be an hidden issue. Aug 30 17:10:18 Herrie: I think I got it right now. The little worry is if I forgot to test the rebuild of another module, but I think it'll be ok Aug 30 17:11:07 I'll PR all that (4 PR now, with luna-qml-launcher) Aug 30 17:12:42 ok Aug 30 17:12:52 I'll check, merge & start nightly then Aug 30 17:16:32 * Tofe hopes he didn't forget anything ! Aug 30 17:18:01 It still could be improved: we have now a common base class, but each component completes it as it needs Aug 30 17:22:07 oops, I just saw a bug with the qml-launcher. I'll fix that asap. Aug 30 17:36:53 Ok, it's fixed and the PR is updated. Aug 30 17:38:52 morphis: Ping Aug 30 17:41:18 Tofe: seems I cannot merge in luna-appmanager Aug 30 17:44:59 oh? Aug 30 17:45:04 It said mergeable Aug 30 17:45:18 Ah you mean you don't have write access Aug 30 17:45:50 Well, it's the same for me here :) Aug 30 17:51:57 Yeah Aug 30 17:58:00 You already merged some other PRs? Aug 30 17:59:20 No ;) Aug 30 17:59:32 Maybe nizovn can have a look to see if he likes them ;) Aug 30 17:59:37 I'm no good with C++ ;) Aug 30 18:02:46 It's mainly refactoring, nothing really fancy. Aug 30 18:04:53 ? i see nothing obviously wrong :) Aug 30 18:13:17 nizovn: Good ;) Aug 30 18:13:32 We now need morphis or JaMa to sort us some access ;) **** ENDING LOGGING AT Mon Aug 31 02:59:59 2015