**** BEGIN LOGGING AT Mon Mar 31 03:00:00 2014 Mar 31 08:20:46 morning Mar 31 08:24:35 morphis: Ok, thanks for the test and the fixes! I still have a couple of uncommitted changes, mainly for the card list view; I think the best way to go would be that I import your fix commit into my branch, then I'll rebase onto master and I'll do a PR Mar 31 08:45:20 Tofe: look at my recent morphis/work3 branch Mar 31 08:45:23 I pushed some more Mar 31 08:46:00 and you also need https://github.com/webOS-ports/luna-next/commit/f2416ee0d56f0b972bea07a66db2a8b61fa0fc87 Mar 31 08:49:30 morphis: yes, that's what I looked at; if I'm right, apart from the two architecture commits, the rest is already in master (luna-next & cardshell PRs yesterday) Mar 31 08:50:29 currently the architecture fixes I have concern the closing of an card, so it's not in conflict with your fixes I think Mar 31 11:10:35 morphis: can I merge master-next to master in libhybris? they are quite different, but SRCREV points to master-next and branch param to master Mar 31 11:10:59 JaMa: for sure Mar 31 11:11:02 44 extra patches in master-next :) Mar 31 11:16:28 the same with qt5-qpa-hwcomposer-plugi Mar 31 11:23:28 JaMa: I think we can switch qt5-qpa-hwcomposer-plugin maybe back to upstream Mar 31 11:25:32 morphis: I've merged webOS-ports/master-next to webOS-ports/master for now to unblock build for master, we can improve it later :) Mar 31 11:25:46 yes Mar 31 14:34:21 Tofe: will you do the PR today? Mar 31 14:34:57 I will give it a try yes Mar 31 14:35:06 this evening Mar 31 14:35:11 ok Mar 31 14:35:35 Tofe: I have one change pending locally which will split LUnaNext into LunaNext.Common, LunaNext.Compositor and LunaNext.Shell Mar 31 14:35:45 I already adopted the cardshell for this Mar 31 14:37:15 ok; your patch should apply smoothly on top of my PR, I think Mar 31 14:37:53 (I didn't change the beginning of the files, and I only have changes to the CardListView and its delegate that are pending) Mar 31 14:38:28 I can also apply it myself on top of my commits of the PR, if you like Mar 31 14:41:46 you mean the architecture related one I did? Mar 31 14:48:22 I mean the slip of LunaNext Mar 31 14:48:25 split Mar 31 14:48:31 ah Mar 31 14:48:37 yeah, that applies cleanly on top Mar 31 14:48:43 I will do the PR for it Mar 31 14:48:53 as it needs modification to other components in our stack too Mar 31 14:49:06 luna-next/cardshell/webapp-launcher/... Mar 31 14:49:37 ok Mar 31 14:50:29 but lets get your changes in first Mar 31 14:50:36 sure Mar 31 15:58:12 morphis: the fix you did in __switchToCurrentWindow isn't actually used, isn't it Mar 31 15:59:46 because we don't use windowWrapper directly anymore, we only manipulate window objects ( I hope it's not too confusing ) Mar 31 16:00:51 I'll check that method when at home Mar 31 16:54:53 morphis: getByIndex does return directly the window, isn't it ? Mar 31 16:58:13 Tofe: it returns a QVariant Mar 31 16:58:16 which is the Window Mar 31 16:58:45 return QVariant::fromValue(static_cast(window)); Mar 31 16:58:50 yes, ok, so then I'll have some fixes for your fixes :) Mar 31 16:59:15 there are some places with getByIndex(......).window Mar 31 17:05:16 ok, I don't have anything in local, but I'll test it a bit on the emulator Mar 31 17:18:22 Tofe: thanks Mar 31 17:21:59 Tofe: I am also not sure yet wether the WindowModel works fine with the filter set Mar 31 17:22:27 :) We'll see that quickly, as I use it to filter out the keyboard and JustType Mar 31 17:22:34 right Mar 31 17:22:50 I just saw the just type app as card so thats why I fear it's not working Mar 31 17:23:13 ok; I'll see Mar 31 17:23:55 justtype has the type "Launcher", right ? Mar 31 17:24:38 I remember not being 100% sure about that Mar 31 17:28:34 yes Mar 31 17:40:40 ok, yes, I see justtype appear as a launcher, as a card, and as a keyboard. There's a bug. Mar 31 17:41:24 oh wait, I didn't pick your luna-next fix Mar 31 17:54:50 morphis: keyboard works correctly, so I think my hypothesis still applies for the launcher Mar 31 17:55:10 (being that the launcher wasn't filtered by type before, but by appId) Mar 31 17:57:38 oh, thats possible Mar 31 17:58:30 should I modify the cardshell, or modify the compositor ? Mar 31 17:59:35 I don't really mind, but modifying the compositor may look more logical to me Mar 31 17:59:59 Tofe: yeah, do it that way Mar 31 18:00:11 ok, let's go Mar 31 18:07:29 morphis: I didn't want to introduce a setWindowType in CompositorWindow, so I did the filtering in CompositorWindow. Hope it's fine for you ? Mar 31 18:08:09 yeah Mar 31 18:08:24 ok; well, looks like it works Mar 31 18:08:53 ah, forgot to focus out the launcher when hiding it Mar 31 18:10:52 there are still some minor fixes to do: focus, app startup is not set to maximized, maybe other bugs Mar 31 18:16:25 https://github.com/webOS-ports/luna-next/pull/67 should work for both cardshell, before and after rearchitecture Mar 31 18:18:44 Tofe: merged it Mar 31 18:20:29 thx Mar 31 18:21:06 what do you think, for the architecture: I do a PR now and debug after, or the contrary ? Mar 31 18:21:44 depends on how you plan to manage the bumps of srcrev for master Mar 31 18:21:54 just push out the PR Mar 31 18:22:04 I will not bump the SRCREV until we have fixed this Mar 31 18:22:13 ok Mar 31 18:23:29 https://github.com/webOS-ports/luna-next-cardshell/pull/65 here goes the PR Mar 31 18:26:05 merged it Mar 31 18:26:10 let me rebase my other code Mar 31 18:33:20 Tofe: https://github.com/webOS-ports/luna-next/pull/68 Mar 31 18:35:03 Tofe: https://github.com/webOS-ports/luna-next-cardshell/pull/66 Mar 31 19:00:02 all merged Mar 31 19:47:56 morphis: I see a little problem with WindowModel: for the same filter, two WindowModel instances might not be identical during small amount of time Mar 31 19:52:53 Tofe: and one other thing Mar 31 19:53:03 I can swipe down a black card from the top after I closed all Mar 31 19:53:17 oh ? Mar 31 19:54:35 ah yes ! funny ! -- well, I mean, I'll fix it. Mar 31 20:02:10 morphis: it comes from Compositor::closeWindowWithId, which deletes the window object too soon Mar 31 20:02:54 (unmapped is not yet called when we delete the window, I guess it is async with a wayland request in the middle) Mar 31 20:11:04 morphis: it's quite strange, the "delete window" in closeWindowWithId has always been there... has it always been wrong ? Mar 31 20:11:51 It looks like a tryRemove in surfaceAboutToBeDestroyed would be enough, but maybe you remember more about that Mar 31 20:34:06 ok, will continue the debug later Mar 31 20:34:08 gn8! Mar 31 23:42:46 morphis: http://build.webos-ports.org/webos-ports-master/images/qemux86/ **** ENDING LOGGING AT Tue Apr 01 02:59:59 2014