**** BEGIN LOGGING AT Mon Jul 15 02:59:58 2013 Jul 15 03:38:57 hai guyz Jul 15 09:00:49 morning! Jul 15 09:03:04 morphis: if you look at my branch tofe/compositor-integration, you'll have a good idea what I'm going to PR. It needs some polishing, but the main things are there Jul 15 09:04:34 Tofe: monring Jul 15 09:05:45 Tofe: you respected that the notification bar is only visible when there is really a notification? Jul 15 09:07:17 Tofe: https://github.com/webOS-ports/luna-next/commit/73865e7130157224df5c7c53fe2c9722849cf6f5 is going to be the compositor rework Jul 15 09:07:33 the enum for the window states are already there Jul 15 09:10:19 morphis: ah, no, not yet Jul 15 09:10:57 but that's not going to be a hard one Jul 15 09:12:25 Currently, to show a widget in the notification area, how is it done ? the app asks for the widget container, and it adds its own ? or is it more formal (only text, etc) ? Jul 15 09:18:47 it can display a whole html page Jul 15 09:18:57 there are different kinds Jul 15 09:23:22 Tofe: lets keep with a dummy notification for now Jul 15 09:24:51 and lets define the following three states for the notification area: open, minimized, closed Jul 15 09:24:59 closed: no notifications are shown Jul 15 09:25:08 minimized: just notifications icons are shown Jul 15 09:25:23 open: all notifications with there content (html, formal format) are shown Jul 15 09:27:42 open vs. minimized: http://admintell.napco.com/ee/images/uploads/gadgetell/facebook_update_for_webos_640.jpg Jul 15 09:28:17 lets implement a dummy notification to show how it looks like until we're going further with reimplementing the API for this Jul 15 09:29:05 ok! Jul 15 13:32:24 Tofe|Away: ping Jul 15 16:33:52 morphis: pong Jul 15 16:34:09 morphis: I've seen I forgot to implement the windowDestroyed function :) Jul 15 16:36:43 Tofe: yes :) Jul 15 16:36:45 done. Back to notification area ! Jul 15 16:36:59 Tofe: ok, I just got clients nicely carded Jul 15 16:37:16 great ! Jul 15 16:37:25 and currently trying to get the ugly window decorations out of the game Jul 15 16:37:35 btw. are you still developing on the PC? Jul 15 16:37:52 yes, I'm still not at home anyway Jul 15 16:38:11 I can just ask for the PR, which hasn't this nasty decoration anymore Jul 15 16:38:45 I'll do the notification area stuff in another PR Jul 15 16:39:15 Tofe: the decorations are coming directly from qtwayland ... Jul 15 16:39:24 need to set a environment variable to disable them Jul 15 16:39:57 ah, ok ! I didn't think qtwayland did put something oh its own Jul 15 16:39:59 of* Jul 15 16:40:11 https://qt.gitorious.org/qt/qtwayland/commit/77248e2765e4db5cd7fe6e53e07a612d75b91011?format=patch Jul 15 16:40:21 it does Jul 15 16:41:06 ah, yes... and they create it by default... what a great idea :) Jul 15 16:42:53 yes :) Jul 15 16:43:25 I just backported that patch to our qtwayland version but maybe it's wise to disable them by default Jul 15 16:44:18 yes, it's better to have simply our windowing stuff, with "vanilla" windows Jul 15 16:44:42 yes Jul 15 16:45:03 there is also the cursor shown but there is already support for disabling it in the latest qtwayland Jul 15 16:45:26 ok Jul 15 16:46:36 I'm currently hesitating a bit for the "rounded corners" implementation, because in QML the right way to go is to have a "OpacityMask" item, which uses a shader to clip the real item on the alpha channel Jul 15 16:46:49 But I just hope it's not too slow Jul 15 16:47:57 shader should be fine Jul 15 16:48:06 LSM also used a shader for this Jul 15 16:48:15 btw. the cards are still a little bit to small Jul 15 16:48:37 yes, I scaled them up to 60% of the maximized size Jul 15 16:48:56 ok Jul 15 16:48:58 based on the various screenshots I saw here and there Jul 15 16:49:46 ok Jul 15 16:49:56 and the QRect of the card is scaled down from the one of the maximized window, it's not rectangular anymore Jul 15 16:50:07 btw. ShiftyAxel|Away would be a good help with all that if he would show up :) Jul 15 16:50:22 :p Jul 15 17:01:20 Tofe: ok, latest morphis/work branch of meta-wop has the window decorations disabled by default Jul 15 17:01:30 ok! Jul 15 17:12:51 morphis: is it ok to take the pictures of the gesture area of LSM ? Jul 15 17:23:25 yes Jul 15 17:24:28 Tofe: you're integrating real gesture support for it too? Jul 15 17:24:44 no, not yet, just wanted it to look a bit nicer Jul 15 17:25:06 though integrating basic gestures (swipe up, left, right) wouldn't be so hard Jul 15 17:25:24 yes Jul 15 17:25:44 I'm still working on the notification area essentially Jul 15 17:31:22 morphis: just using glow.png, I'm already getting something nice. Jul 15 17:31:31 ok Jul 15 18:36:45 morphis: would you have some kind of "rule" for me to know what images of LSM are OK with luna-next ? Jul 15 18:37:05 are, for example, the "x4" project images ok ? Jul 15 18:43:19 puuh Jul 15 18:43:27 :) Jul 15 18:43:27 good question Jul 15 18:44:02 lets keep it likes this: we add a list of images and their license into the repo so we can separate things for now Jul 15 18:44:15 all things from LSM should be Apache-2.0 Jul 15 18:44:31 zz_ka6sox: any objections? Jul 15 18:45:06 ok Jul 15 18:52:47 Tofe: we need further on decide on how we're going to handling scaling between different devices Jul 15 18:54:10 yes; currently it should scale alright, I think, if the dimension are not too tiny. But some more attention is needed, sure Jul 15 18:54:53 it's looking very tiny on Galaxy Nexus atm Jul 15 18:55:04 we used a DPI setting value in LSM/WAM for this Jul 15 18:55:23 yes, I introduced it too Jul 15 18:56:01 ok Jul 15 18:56:08 with the same semantics? Jul 15 18:56:31 not sure; what semantics ? Jul 15 18:57:28 so DPI settings in LSM/WAM match to the one you implemented in luna-next? Jul 15 18:57:56 so status bar will same height with same DPI settings in both LSM and luna-next for example? Jul 15 18:58:39 ah, mmh, no, I did a dotPerMM, but I can easily switch to dotPerInch Jul 15 18:59:13 I would prefer that Jul 15 18:59:30 yes, I can understand why Jul 15 19:01:28 :) Jul 15 19:08:14 JaMa: would you prefer a configuration file specific for a machine in OE or in a separate git repo? Jul 15 19:09:57 * JaMa reading backlog first Jul 15 19:11:45 morphis: DPI config? Jul 15 19:11:58 luna-platform.conf for example Jul 15 19:12:11 I really like how fso was handling configs Jul 15 19:12:20 using the same repo for code and config Jul 15 19:12:29 :) Jul 15 19:12:38 ok, then lets do the same Jul 15 19:12:59 A) then separate MACHINE_ARCH recipe which installs config for specific MACHINE if available or default one Jul 15 19:13:02 JaMa: furthermore if we're going to use for example luna-sysmgr-common I want to make it not machine specific anymore Jul 15 19:13:26 b) or all configs packages with main app and runtime code which selects if there is specific config for running device Jul 15 19:14:00 b) is better because it doesn't even need separate recipe for configs Jul 15 19:14:02 I would like to have a config package per machine Jul 15 19:14:52 as in the end we're building machine specific images anyway Jul 15 19:15:22 with fso we were somewhere between a) and b), because runtime deps for MACHINEs were in separate recipe (like fsodeviced-modules) and configs were installed all at once Jul 15 19:15:35 yes Jul 15 19:16:32 but it was great that we were able to build all modules in TUNE_PKGARCH fsodeviced package and then only the selection of what needs to be installed on each MACHINE was MACHINE_ARCH Jul 15 19:17:02 yes Jul 15 19:17:15 I would like to implement it in a similar way Jul 15 19:18:56 so a luna-next-conf-${MACHINE} package Jul 15 19:19:17 which is then pulled in by some already machine specific packagegroup Jul 15 19:19:54 JaMa: and the other thing: Jul 15 19:20:03 no I think it should be luna-next-conf for every MACHINE, only the content would be MACHINE specific Jul 15 19:20:23 so luna-next can RDEPEND on luna-next-conf wich is excluded as ABISAFE Jul 15 19:20:47 shoot Jul 15 19:21:13 that means we need another recipe for it, right? Jul 15 19:21:20 right Jul 15 19:21:29 ok Jul 15 19:21:55 it can (or even should) reuse SRC_URI, SRCREV from luna-next recipe Jul 15 19:21:58 next thing: if we're going to modifying already existing components like luna-sysmgr-common we have to modify the existing recipes too Jul 15 19:22:11 like dropping qt4, make it not machine specific anymore etc. Jul 15 19:22:36 fine with just doing all modifications in the recipes or does that cause a lot of merging overhead when rebasing? Jul 15 19:23:03 it's fine with me Jul 15 19:23:06 ok Jul 15 19:23:41 the modifications in "upstream" repo are so small so that most rebasing overhead is cleanly handled by my migration scripts Jul 15 19:23:57 and we don't need to rebase often now Jul 15 19:24:22 yes Jul 15 19:24:47 the alternative with .bbappend or something wouldn't allow us e.g. to uninherit webos_qmake Jul 15 19:25:09 yes Jul 15 19:41:53 JaMa: I know I had this one here http://pastebin.com/0EJpQRD5 some time ago Jul 15 19:41:57 Garfonso: hey Jul 15 19:43:39 morphis: changing PACKAGE_ARCH from MACHINE_ARCH to TUNE_PKGARCH? Jul 15 19:43:48 yes Jul 15 19:43:56 morphis: you need to remove tmp-eglibc/pkgdata for old luna-sysmgr-common Jul 15 19:44:07 ah yes, that was the trick Jul 15 19:44:29 find tmp-eglibc/pkgdata/ -name luna-sysmgr-common\* -exec rm -rf {} \; Jul 15 19:52:02 works fine now, thanks Jul 15 19:56:35 Tofe: https://github.com/webOS-ports/luna-next/pull/12 Jul 15 19:57:26 damn, it's already too late ... merged my own PR by accident Jul 15 20:30:59 morphis: and I merged the other one Jul 15 20:31:06 ok Jul 15 20:31:32 one question: what can be used in window, in windowDestroyed ? Jul 15 20:32:25 maybe it's just unparented; I'll try to remove the card the other way around. Jul 15 21:32:46 JaMa: ok, luna-sysmgr-common is reworked, based on qt5 and builds with cmake now Jul 15 21:35:19 makes the recipe really small :) Jul 15 21:35:23 :) Jul 15 21:55:56 JaMa: cleaning this messay qmake stuff was already over time **** ENDING LOGGING AT Tue Jul 16 02:59:58 2013