=== salem_ is now known as _salem [08:03] tsdgeos: hey, do you have a galaxy nexus? [08:07] kgunn: no, a nexus4 [08:08] tsdgeos: mm, thanks...i might come back...but i'll try not to :) [08:09] arggg [08:09] come on, can someone ban morphis for a while? [08:58] tsdgeos, mzanetti, could one of you guys please try and investigate bug #1206991 [08:58] bug 1206991 in Unity 8 "Frequent CPU hogging" [Critical,Triaged] https://launchpad.net/bugs/1206991 [08:59] Saviq: sure, which image, today's one? or? [09:01] tsdgeos, all of 'em, more or less ;) [09:01] tsdgeos, it just gets stuck at 30-40% CPU at times (although I have no real way to reproduce) [09:01] Saviq: ah... happens on desktop all the time for me [09:02] mzanetti, good, you're it [09:02] I just run unity8 and my fans start running. [09:02] ok. I'll check it out [09:02] mzanetti: ok, yours it is [09:05] mzanetti, it seems to settle after a minute or so here (on desktop) [09:07] mzanetti, "14,08% unity8 libQt5Quick.so.5.0.2 [.] QSGNodeUpdater::isNodeBlocked(QSGNode*, QSGNode*) const" is the biggest one for me on desktop, per perf [09:09] Saviq: I'll check it out in a few. still discussing about LVWPH with tsdgeos right now. [09:09] mzanetti, yup, thanks [09:15] nooo, dandrer is on holiday already? [09:15] ah, ignore me :D [09:42] tsdgeos, yeah, and out for the whole month! [09:48] who authorized that? [09:48] pete-woods, hey, just check, is the new glibmm in saucy working for you now? [09:49] larsu: ping [09:50] dednick, he's at GUADEC for a week, he might not be around a lot (just mentioning it so you are not surprised if he doesn't pong) ... maybe let some question/context so he can reply when he reads backlog [09:50] dednick, or use emails [09:51] seb128: ok. thanks [09:52] seb128: perfect, thanks! [09:53] pete-woods, excellent, yw ;-) [09:53] pete-woods, thanks for the updated patch! [09:54] seb128: not a problem! [09:58] oh may [09:58] i mean [09:58] my [09:58] https://bugreports.qt-project.org/browse/QTBUG-32745#comment-211018 [09:58] " [09:58] Assignee: [09:58] Unassigned " [09:58] it'll be fixed fast! [09:59] :/ [10:00] tsdgeos: otoh. we're only using it for the fake video data [10:05] Saviq: KWin has a plugin which shows all paint events on the screen. unity8 flickers like crazy. also callgrind shows like 47% cost in ligGL and mesa stuff [10:05] Saviq: seens something is triggering paints all along [10:06] dednick: ping [10:06] mzanetti: pong [10:06] dednick: if I run unity with the fake plugins, the indicators have some colored rectangles rotating all the time [10:06] Cimi, can you join https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV85ODZnYWZucHJ2cmU5OGRscjgyMm9zYzg2c0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t.7i0fmrimvi8oactkg0q3s1e44o please [10:07] suew [10:07] dednick: mind changing that to non-rotating rectangles? [10:07] sure [10:07] dednick: it makes it hard to profile because that stuff constantly calls paints. [10:07] mzanetti: can do. [10:08] dednick: and also, seems you should stop painting alltogether when indicators are collapsed. maybe even unload stuff [10:08] mzanetti: they unload after awhile [10:08] dednick: define "a while" === shiznix_ is now known as shiznix [10:09] mzanetti: 20 seconds [10:14] mzanetti: https://code.launchpad.net/~nick-dedekind/unity8/indicators.remove-fake-animations/+merge/178031 [10:16] dednick: thanks. approved. [10:16] dednick: and indeed my CPU is not hogging any more whenever I do ./run -p [10:16] mzanetti: :) [10:17] dednick: but I have some bad news [10:17] dednick: it didn't stop after 20 mins. so the unloading doesn't seem to work [10:17] andyrock: hi! [10:17] err, 20 secs [10:18] mzanetti: ah. right. i think the fake ones dont actually [10:18] andyrock: I'm currently *trying* to dogfood the new unity with compiz 0.9.10, but I think I'm having problems [10:19] mzanetti: they don't really "unload". they "stop" which is intended to stop the dbus shizzle. [10:19] dednick: you sure that works? :P [10:19] mzanetti: er. last time i checked it did [10:20] mzanetti: and as far as i remember there was a test. [10:20] dednick: because I see this all the time: https://bugs.launchpad.net/touch-preview-images/+bug/1183065 [10:20] Launchpad bug 1183065 in touch-preview-images "Occassional severe battery drain" [High,Confirmed] [10:20] dednick: and reading through the comments it seems to be related to network [10:20] dednick: so unity8 going crazy because of networking can only be related to the network indicator, I'd think [10:22] mzanetti: i'll have to look into it [10:22] mzanetti: may have something to do with the network indicator continously crashing... [10:23] dednick: hmm... that sounds indeed interesting [10:24] dednick: this bug is the only really bad issue I'm suffering when dogfooding the device. Whenever I leave home my pocket starts heating up and battery is empty in no time [10:24] mzanetti: ever notice if the network indicators content is flashing? [10:25] dednick: hm... I think so, yes. But I can't tell if there's a directo connection to the CPU hogging [10:26] mzanetti: well if the indicator dbus stuff isnt stopping, then the model wiill most likely be reloading itself continuously. i'll have to check if the stop is working. [10:27] dednick: but unless networkmanager or the indicators backend have some issues, that shouldn't cause 80% cpu usage, no? [10:27] andyrock: ok, scratch that [10:28] mzanetti: in which process? unity8? [10:28] dednick: but actually... the fact that strace shows unity8 trying to access a file descriptor which isn't available any more, kind indicates a crash of something unity relies on [10:29] dednick: yeah, unity8 is the one hogging the cpu [10:30] Saviq: now that we fixed the fake plugins, I can't reproduce it any more :/ [10:30] * mzanetti keeps on trying [10:31] :/ i can't really say where the process cycles are going. other than maybe redrawing the indicator. [10:32] which shouldnt be done if it's not showing [10:32] mzanetti: can you catch redraws of items in qml? [10:33] dednick: yes [10:33] dednick: well, seems we always paint the full qmlscene [10:34] mzanetti: how? :) [10:34] dednick: so not single items, but I can see everything flicker if something repaints [10:34] dednick: KDE's KWin has a "desktop effect" called "Show paint". That colorizes every painted frame differently [10:34] sil2100: hi. I was looking at your lucene++ packages, and ran into a problem compiling the media scanner with it [10:34] mzanetti, but can you confirm that's not the case for simple qmlscene apps? [10:35] mzanetti, I don't think we have damage support in QML [10:35] jamesh: hi! What was the problem? [10:35] sil2100: it looks like it has been compiled with a custom allocator, which trips up the configure checks in the mediascanner [10:35] Saviq: what, the CPU hogging? [10:35] jamesh: we're configuring it with -DLPP_USE_ALLOCATOR:BOOL=OFF, so hm [10:36] mpt, ping [10:36] mzanetti: yeah, but you cant see that while your phone is off ;) [10:36] mzanetti: i meant is there a signal you can connect to for redraw requests on items. [10:36] sil2100: changing "-DLPP_USE_ALLOCATOR:BOOL=OFF" to "-DENABLE_STANDARD_ALLOCATOR:BOOL=ON" in debian/rules should do the trick [10:37] dednick: ah... hmm... I guess that would require you to subclass QQuickItem or some part of the Engine [10:37] sil2100: I think the lucene++ cmake flags have changed since the packaging you based your work on was written [10:37] joy [10:37] jamesh: ok, might be - but I actually see Ken change it from -DENABLE_STANDARD_ALLOCATOR:BOOL=ON to the current one, so maybe in the past he had a need for a custom allocator? [10:37] * mzanetti needs to turn off the show paint effect before he gets an epileptic stroke [10:38] jamesh: I'm prepping a new version now anyway so I'll change that [10:38] sil2100: "grep LPP_USE_ALLOCATOR /usr/include/lucene++/Config.h" should show whether it is set correctly [10:38] sil2100: we need it to be an #undef, while the current test package has it #define'd [10:44] sil2100: I'm not sure if the media scanner was ever built against Ken's updated package: its packaging still refers to the "luceneplusplus" package rather than "lucene++" [10:45] jamesh: probably! [10:45] jamesh: anyway, it will be fixed in the next version [10:46] sil2100: awesome. Thanks for your help with this. [10:47] dednick: hey, what's up? [10:48] larsu: hey. sorry, figured out my issue [10:49] larsu: wasnt getting dataChages for submodels. but i was looking on the parent. [10:49] dednick: great :) === MacSlow is now known as MacSlow|lunch [10:53] mzanetti, no, the fact that it redraws the whole thing [10:53] mzanetti, if it redraws constantly - that's a different issue [10:53] mzanetti, but I don't think we can be redrawing just parts of our UI [10:53] Saviq: I agree... as its one single opengls scene [10:53] mzanetti, yup [10:54] Saviq: anyways... the issue I've seen was the fake indicators [10:54] mzanetti, ah, so not applicable to device [10:54] Saviq: now that this is fixed, I'm having a hard time to reproduce Kaleo's bug [10:54] Saviq: no... been swiping the dashes now for 5 minutes... nothing happens in regards of CPU usage [10:54] mzanetti, yeah, it's random unfortunately [10:55] Saviq: I can however reliably reproduce the other one: https://bugs.launchpad.net/touch-preview-images/+bug/1183065 [10:55] Launchpad bug 1183065 in touch-preview-images "Occassional severe battery drain" [High,Confirmed] [10:55] mzanetti, as I wrote in the bug - I couldn't reproduce either [10:55] Saviq: so its maybe this one that Kaleo has seen in combination with the mem leaks [10:55] mzanetti, yeah, but the battery drain is usually caused by CPU hogging, so... [10:56] Saviq: yeah... I did an strace for that one... [10:56] Saviq: its unity8 stuck in an endless loop trying to read some fd which is "temporarily not available" [10:57] Saviq: I'm tempted to reopen that one for unity8 as even if some backend crashes away, we shouldn't hog CPU because of that === hikiko is now known as hikiko|lunch [11:38] tsdgeos: hey, do you know of a way to get to animations in QML tests? [11:38] they don't seem to be proper childs and are not found by findChild() [11:39] hmm [11:39] haven't tried [11:39] mzanetti: so you can't find them by ojbectName? [11:40] tsdgeos: not right now, no [11:42] weird [11:43] i mean a QQuickAnimation is QObject [11:43] don't see why it should not get parented as usual [11:44] hmm... I don't know why either [11:44] maybe thats the mem leak dandrader tries to find :D === alan_g is now known as alan_g|lunch [11:51] tsdgeos: ok... they are parented... but not where they are written in the QML code [11:52] tsdgeos: In this case, the anim has no parent: http://paste.kde.org/pd5712ba0 [11:52] tsdgeos: in the Lockscreen, the parent is the next wrapping Loader {} [11:52] weord [11:52] yeah... totally [11:52] lunch time [11:52] bbl === MacSlow|lunch is now known as MacSlow [12:02] ok... it gets even weirder: myAnim.parent == myLoader, BUT myLoader.children does NOT contain myAnim [12:05] andyrock: running the new compiz, so far so good [12:05] andyrock: do you know if there have been any performance improvements? === hikiko|lunch is now known as hikiko [12:28] Cimi: MacSlow: you guys had some tests where you would have needed to access animations in findChild, right? [12:29] mzanetti, correct... that's in the qmltest for the notification-frontend (lp:unity8/unity8/tests/qmltests/Notifications/tst_Notifications.qml) [12:31] MacSlow: Cimi: I found the cause for that not working and fixed our findChild(). will land in trunk soon [12:31] tsdgeos: btw ^ [12:31] mzanetti, well in the notification-qmltest is works atm... what issue did you fix? === _salem is now known as salem_ [12:32] MacSlow: findChild() now also finds animations (and other non-visible items) [12:33] mzanetti, ah... good to know... although I can't jump in an fix/change the test right now (once your stuff is merged) [12:33] MacSlow: iirc you added some workaround like some __properties that refer to animation.running, right? [12:34] mzanetti, waitForRendering(...) is used atm [12:34] MacSlow: ??? [12:35] thats not related in any way [12:36] mzanetti, then I don't know [12:38] hah! could reproduce the testRightEdgeDrag hanging as we've seen it on jenkins lately [12:41] mzanetti, tsdgeos can you or someone https://code.launchpad.net/~saviq/unity8/add-fake-disclaimer/+merge/178059 please [12:41] Saviq: ok. can do [12:41] mzanetti, under autopilot or real? [12:42] Saviq: qmltestrunner [12:42] mzanetti, ah [12:43] mzanetti, sounds like a candidate for a test if you can reproduce [12:47] Saviq:would you mind documenting your findings in the mp after you test galaxy nexus w/ duflu's switch branch [12:47] kgunn, will do [12:48] kgunn, unfortunately gn is *slow* for building... === alan_g|lunch is now known as alan_g [12:51] kgunn, your leg is twitching [12:56] mzanetti, nope [12:56] Cimi: I know you did... [12:56] but anyways... just wanted to let you know that as of now it works [12:59] Saviq: :) [12:59] only way to stay awake [12:59] Saviq: do we want tr() for that text? [12:59] tsdgeos, nah [13:00] ok [13:01] Saviq: tsdgeos: any idea on that one? http://paste.kde.org/p6ab70292 [13:01] this is the result of a findChild(shell, "launcherPanel") [13:03] somewhere in responsiveGridViewGridView we have some parent-child loop [13:03] urg [13:03] you sure? [13:04] tsdgeos: the test hangs forever here... admittedly after my change in findChild which does not only search visible children but also invisible ones (e.g. animations) [13:04] yeah 0x282bbd0 seems to be there too often [13:05] tsdgeos: to reproduce, edit UnityTestCase and change "obj.children" to "obj.data" which also allows finding animations [13:05] tsdgeos: I could now just create a second one, findInvisibleChild or the like and get around this issue. but it feels fishy enough to investigate [13:05] yeah [13:07] dednick, So it seems that the switch items require a target type to be set? [13:07] dednick, I'm a bit confused on why that is. It seems like they should just be using the state of the action. [13:09] tedg: you mean based on the action state being of type boolean? [13:10] dednick, Yes, I think that is how it should be [13:10] tedg: hm. interesting point. [13:10] tedg: at the moment we dont look into the type until we know what it is. [13:10] dednick, That is, for instance, how check items work in GTK. [13:10] tedg: what if we have 2 items with the same format state? [13:11] dednick, What do you mean by format state? [13:11] eg an float for progeress/slider. [13:11] Yes, it should be. That should be the state of the action. [13:11] tedg: the gvariant format of the action state [13:11] Targets are really only used for radio groups. [13:12] tedg: what i mean is. how do we know to render a slider, or a progress bar? [13:12] dednick, Won't that be the x-canonical-type ? [13:12] tedg: what is the target type? [13:13] tedg: that's what i though you ment of 'type' [13:13] tedg: mumble? [13:13] dednick, Sure [13:20] tsdgeos, mzanetti any word on the disclaimer? we would like to get it in so we can get into distro asap [13:20] Saviq: didn't test yet... can do now if urgent [13:21] mzanetti, yes please [13:23] Saviq: this sucks [13:23] mzanetti, that we get in on desktop all the time? [13:23] mzanetti, think we should have an env var that would disable it? [13:24] like I_KNOW_ITS_ALPHA=1? [13:24] Saviq: probably add something into the ~/.unity8-greeter-demo even if the filename is probably not the right one, but its already there and easy to adjust [13:25] Saviq: and how does this go with planet ubuntu tellig people they should start dogfooding it? [13:25] mzanetti, on phone [13:25] mzanetti, it's not going to be there on phone [13:25] mzanetti, only with the fake Ubuntu.Application [13:25] ah... oh. that's different then [13:25] ;) [13:26] lemme try on the phone [13:26] mzanetti, it will be there on desktop and during autopilot runs, that's it [13:26] Saviq: ah ok... I'm fine with it then... [13:27] Saviq: just wondering. what's the resoning for this? [13:27] mzanetti, so that when we land in distro and people see it [13:27] mzanetti, it's obvious that it is so [13:27] ok.. [13:27] mzanetti, i.e. `apt-get install unity8; unity8` AAAH that's crap! let's blog about it [13:28] Saviq: right. makes sense [13:30] Saviq: still compiling for the phone, but I would expect it to throw a warning "no such property applicationManager.fake" if its the real one [13:30] tedg: having an issue with the current network indicator. it's not giving me a action state for the root menu item. [13:31] Saviq: yep: file:///home/phablet/shell/Components/ApplicationManagerWrapper.qml:32: Unable to assign [undefined] to bool [13:31] mzanetti, hmm let me "cast" ;) [13:32] lol [13:34] tedg: never mind. i think it's my fault. [13:35] Cimi: standup? [13:39] mzanetti, pushed [13:42] Saviq: happroved [13:50] mzanetti, o/ === salem_ is now known as _salem === _salem is now known as salem_ [14:05] sil2100, no idea about that [14:05] there are some branches that should improve the performance [14:05] *s [14:14] mterry, ping [14:14] Saviq, hello [14:15] mterry, hey, would you have time to work on a quick'n'dirty solution for the powerd SysPowerStateChange signal? [14:15] mterry, we identified that this would significantly improve battery life [14:15] mterry, if we unfocus all the apps when locking, 'cause we'd disable accelerometer then [14:16] mterry, I talked to sforshee that there is (some) plan for a common library to talk to powerd, but it's not on the roadmap [14:17] mterry, so we need to hack something up :/ [14:19] doesn't look like you will ;P [14:20] Saviq, my IRC connection seems awful [14:20] mterry, I noticed [14:20] mterry, hey, would you have time to work on a quick'n'dirty solution for the powerd SysPowerStateChange signal? [14:20] mterry, we identified that this would significantly improve battery life [14:20] mterry, if we unfocus all the apps when locking, 'cause we'd disable accelerometer then [14:20] mterry, I talked to sforshee that there is (some) plan for a common library to talk to powerd, but it's not on the roadmap [14:20] mterry, so we need to hack something up :/ [14:20] does anyone know what the plan is with regards to wiping the root partition on device flash? at the moment this is killing everything in /var/lib? is there somewhere more permanent that I should be putting things? [14:20] <-- mterry has quit (Ping timeout: 248 seconds) [14:20] doesn't look like you will ;P [14:20] My internet doesn't appear to be this bad... [14:20] pete-woods, with the system-image flashing, it won't anymroe [14:20] anymore [14:21] pete-woods, or at least you won't need to flash [14:21] Saviq: is there somewhere I can read about that? so as not to ask you a serious of dumb questions [14:21] *series [14:21] pete-woods, https://wiki.ubuntu.com/ImageBasedUpgrades/ [14:22] tedg: ping [14:22] pete-woods, lool would be your PoC for that while stgraber is away [14:22] pete-woods, You should talk to stgrabber there [14:22] dednick, howdy [14:23] Saviq: basically the question is really, should I be stuffing data in another location than /var/lib, but it sounds like someone else has fixed the issue for me (which is always good) [14:23] pete-woods, yeah, I think /var/lib is right [14:23] tedg: hi. ok, so i think i've found the code in unitymenumodel (at least) which is things up. it looks like the "action type" and "action state type" have to match to be deemed "activatable". [14:24] Saviq: awesome, thanks! [14:24] *which is screwing things up [14:24] tedg: at least it's screwing it up for me because the network indicator root item has a action type, but no action state. [14:25] dednick, Hmm, is that a Unity menu model thing or a handling thing? [14:26] mterry, want me to email? [14:26] tedg: its a gmenumodel handling thing. inbetween backend and unitymenumodel [14:27] tedg: so the item doesnt have a target type, but has a state type. === alan_g is now known as alan_g|tea [14:27] which unitymenumodel feels is bad. [14:27] larsu: ^ when you're about. [14:28] Saviq: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/577 and (running the stack) [14:28] tsdgeos, https://launchpadlibrarian.net/146390382/buildlog_ubuntu-saucy-amd64.unity-mir_0.1-0%2B201308011415~24~saucy1_FAILEDTOBUILD.txt.gz ;( [14:28] sil2100: FYI ^ [14:28] didrocks, awesome :) [14:28] tedg: was your problem that you needed to set a target type? or a state type? [14:29] tedg: i'm confusing myself again i think [14:29] kgunn, olli_, asac, unity8 is getting released into distro right now [14:29] dednick, I had to set the target type [14:29] Saviq, coolio [14:29] not "now", NOW! :) [14:29] Saviq, which string did you go with? [14:30] Saviq, heh, let's try one more time [14:30] lol [14:30] mterry, you've got @ [14:30] olli_, "EARLY ALPHA\nNOT READY FOR USE" [14:31] olli_, JohnLea's recommendation [14:31] Saviq, neato [14:31] thx [14:32] olli_: Saviq ...i still prefer "hold my beer...watch this" [14:32] Saviq, I see [14:32] Saviq, does SysPowerStateChange need implementing on Ubuntu or do we need unity8-side listening for it? (or both) [14:33] kgunn, :) [14:33] kgunn, https://www.facebook.com/HoldMyBeerMemes?ref=stream [14:36] mterry, we just need unity8 to listen for it [14:36] mterry, it's there in powerd [14:36] Hey guys. When are you going to introduce a decent multiple screen support? I'm tired of this bugs that come since 12.04 [14:38] PedroGomes, did you file reports for those bugs? [14:38] Saviq: AFAIK, one of them is widely known, the one where you take one of the screens and you windows go to random places. [14:39] Saviq: I know that is better now, but even so there is no logic in the after location === alan_g|tea is now known as alan_g [14:40] PedroGomes, if there's a bug filed, there's a better chance of getting it fixed [14:40] PedroGomes, "widely known" is not really useful [14:42] Saviq: widely known as the one of the guys here some months back that this was know [14:43] Saviq: s/that this/ said that this/ [14:43] s/know/known [14:43] PedroGomes, did you look for the bug report? [14:43] mterry, hey [14:44] seb128, mterry has huge IRC issues today [14:44] Saviq, oh, I saw that you tried to talk to you as well [14:44] Saviq, maybe he just doesn't like you and pretended having IRC issue to avoid having to reply :p [14:44] mterry, talk to me! :p [14:44] seb128, yeah, it's almost a week here already, people start talking to themselves [14:44] Saviq, thanks ;-) [14:45] seb128, nothing to point fingers about! [14:45] Saviq: https://bugs.launchpad.net/compiz/+bug/763148 [14:46] Launchpad bug 763148 in Compiz Core "Adding/Removing an external monitor causes open windows to move to another workspace" [Medium,Fix committed] [14:46] Saviq: what? [14:46] Saviq: do you care to translate this to me? I see fix released/commited [14:46] Saviq: mir broke unity-mir? [14:47] tsdgeos, yeah [14:47] tsdgeos, looks like http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/906 [14:47] Saviq: ok, want me to have a look? [14:47] PedroGomes, this bug is fixed, looks like it got reintroduced, or there's actually a different bug [14:48] PedroGomes, what version of Ubuntu are you running? [14:48] PedroGomes, if there isn't a newer / open one, file one with `apport-bug` ideally [14:48] 13.04 [14:49] didrocks, ugh, we need unity-api to get into distro, too [14:49] didrocks, will it get released with the whole stack or? [14:49] Saviq: wholeeeeeee stack of course! :) [14:49] unity8, unity-notifications and unity-api [14:50] didrocks, ok good, didn't know whether the target thing is per-stack or per-source [14:50] Saviq: I have still enough coffee in my brain to have thought about it :) [14:50] didrocks, thanks ;) [14:50] yw! [14:54] tsdgeos, what'd you have to interrupt for looking into it? [14:54] seb128, hi [14:54] seb128, that one was mostly just me grabbing a drink while autopilot ran :) [14:55] Saviq, when will I be able to apt-get it [14:55] Saviq: well i'm doing some work on the LVWPH to support the expanding shell categories [14:55] minutes, hours, tomorrow [14:55] olli_, hours [14:55] Saviq: but almost done [14:56] mterry, hey [14:56] Saviq, coolio [14:56] mterry, you are the greeter man right? ;-) [14:56] olli_, not even [14:56] k, thx [14:56] mterry, greeter/lock screen [14:57] mterry, I'm trying to figure out if the options listed on that panel are supported, and if they are, through what config/interface: [14:57] https://wiki.ubuntu.com/SecurityAndPrivacySettings?action=AttachFile&do=get&target=phone-security-privacy.png [14:57] mterry, e.G the "when locked allow: launcher/camera/notepad", "stats on welcome screen", "messages on welcome screen" [15:06] seb128, Yup, greeter guy [15:13] mterry, can you reply to the questions then? ;-) [15:20] olli_, indicators-client-autopilot is obsolete - it's built into unity8-autopilot [15:22] tsdgeos, lp:platform-api/mir seems to be broken too [15:22] tsdgeos, with the events refactor in mir [15:26] :/ [15:26] Saviq: ok, i'll start updating the phone for unity-mir development again [15:26] and have a look tomorrow morning [15:26] since it's not going to finish that fast :D [15:27] tsdgeos, thanks [15:27] Saviq: so the LVWPH sectionHeaders now know to which index they belong with https://code.launchpad.net/~aacid/unity8/lvwph_sectionHeaderIndex/+merge/178099 [15:27] so i can map sectionHeader -> index without having to depend on the section name to be unique [15:28] tsdgeos, cool [15:28] the best thing is that it's not much code [15:37] dednick: there's no such thing as an "action type" [15:38] dednick: an action can have state (which is typed), and when you activate an action, you can pass a parameter (which is also typed) [15:38] dednick: the two do *not* need to match. In fact, they often don't [15:39] dednick: the problem you're hitting is probably that the menu item's "target" (which is passed as parameter when activating the action) does not match the actions parameter type === jhodapp is now known as jhodapp|lunch [15:39] dednick: unitymenumodel doesn't know what to do in that case, so it reports the menu item as not activatable [15:50] olli_, you can install from ppa:ubuntu-unity/daily-build already [15:50] olli_, it's building for armhf still [15:56] tedg: ^ so you needed to set the menu items target type to match the action parameter type? [15:57] larsu, But we're talking about for switch items. Which seems they shouldn't have a target at all. Just a state of type b. [15:57] I think that the switch item is trying to use the target type for the state. [15:57] tedg: but then shouldnt the action parameter also be empty? and you set the state? [15:57] (perhaps others, but that one in particular) [15:58] dednick, Correct, and if I set the target type to null (unset) the UI doesn't seem to lookup the state. [15:58] If I set the target type to 'b' then it's happy. [15:58] tedg: right, you have two options: [15:59] (a) set parameter_type to NULL on the action [15:59] tedg: probably because the x-canonical-type isnt set [15:59] (b) set the right target [15:59] larsu, What do check boxes do, I think that the switches should match check items. [15:59] for a switch menu item, I'd not set a target [15:59] cause activating that item should simply toggle the switch [15:59] which in turn toggles the action state [16:00] tedg: check boxes work the way I just described (no parameter, activate toggles) [16:00] larsu, dednick, Also (tangent) I added two proposed props to the root item. Thoughts? https://wiki.ubuntu.com/SystemComponents [16:00] larsu, I think that the problem dednick is having is that something is checking that target type, and if it doesn't match the state, is getting confused. [16:01] Do we have any item types that need a target? [16:01] * tedg thinks no [16:01] This might make the whole thing clearer if we just said code that used it was wrong (for now) :-) [16:01] tedg: i think the way unity8 currently gets around the switch is with setting the target=NULL, and it works because the menu is typed with "com.canonical.indicator.switch" which assumes a state. [16:01] tedg: I like the "icons" property, but it should be av, not ay (g_icon_serialize may return any kind of variant) [16:02] larsu, Ah, okay, I wasn't sure what the type was there. [16:02] tedg: I don't understand the pre-label one, isn't that the same semantics as a normal label? [16:02] larsu, So then icon should be 'v' as well? [16:02] larsu, No the normal label goes after the icon. [16:02] tedg: yes [16:02] tedg: i think the chewie network needed a target [16:02] tedg: ah! I misread it's for the "other" side. Sounds good to me [16:02] tedg: thanks for documenting it [16:03] dednick, Hmm, I wonder why. We don't anymore :-) [16:03] dednick, Should we have a new type? [16:03] tedg: my problem - ACTION ADDED :indicator.network-status , action_target:(nil), parameter_type:0x269b370 [16:04] sounds like dednick has the right idea :) /me needs to go, bl [16:04] bbl [16:05] dednick, That sounds right, why is that a problem? [16:06] because it doesnt fetch an action state for that condition. [16:06] tedg: why is the root item action parameter type set? we're never going to activate it are we? [16:07] tedg: shouldnt it just have a action state for the connection state info? [16:08] tedg: re root item proposal - do we need labels on both sides? [16:09] dednick, It should still get the state even if the target is null. They're independent. [16:09] dednick, The type is just so we can extend it later, but sure, on the root item the type isn't that important. [16:09] dednick, Yes, we need the label on one side for power and the other for network. [16:09] tedg: target being null isnt the issue, it's that the target does not match the actions parameter type [16:10] dednick, And that's fine, as they're independent. The state and the target shouldn't effect each other. [16:10] tedg: but i guess maybe it should get it anyway [16:12] larsu: ^ should set state even if not activatable? [16:15] tedg: but anyway, if we extend, we can change both? i dont think it makes sense that they dont match. [16:15] tedg: since you cant activate if they're not anyway. [16:15] dednick, What do you mean by both? [16:16] target and action parameter type [16:17] Yes, they could not match. [16:20] mzanetti_, [16:20] + print("fpppppppppppppppppppppppp1") [16:20] checkRightEdgeDragWithNoRunningApps(); [16:20] [16:20] + print("fpppppppppppppppppppppppp2") [16:20] dragLauncherIntoView(); [16:20] [16:20] + print("fpppppppppppppppppppppppp3") [16:20] ;) [16:21] + print("baaaaaaaaaaaar1") [16:21] + print("trying to find child \"launcher\" from shell") [16:21] var launcherPanel = findChild(shell, "launcherPanel"); [16:21] + print("baaaaaaaaaaaar2") [16:21] verify(launcherPanel.x = - launcherPanel.width); [16:21] + print("baaaaaaaaaaaar3") [16:21] swipeFromLeftEdge(); [16:21] + print("baaaaaaaaaaaar4") [16:21] tryCompare(launcherPanel, "x", 0); [16:21] + print("baaaaaaaaaaaar5") [16:21] Saviq: already removed [16:21] :D [16:21] mzanetti_, ;) [16:21] the art of debugging [16:21] :D [16:22] Saviq: I think this commit fixes the few "Job killed after 60 mins" we've seen lately [16:22] Saviq: it speads up searching Shell.qml to no-time while searching the whole tree took multiple seconds here and with the invisible childs enabled it wouldn't finish any more [16:32] mzanetti_, cool [16:57] Saviq: when you have a minute, please respond on my comment here: https://code.launchpad.net/~macslow/unity8/notification-autopilot-tests-dbus/+merge/177780 === alan_g is now known as alan_g|EOD [17:30] tedg: ping [17:32] Howdy dednick [17:33] tedg: hi again :) just a quick question. the root item uses (sssb) type. will that be updated to a{sv} ? or it is to stay? [17:33] tedg: talking network indicator [17:33] dednick, I think many of the indicators have already gone to a{sv}, network will join. [17:34] Not sure how many are still using sssb [17:34] I'd consider that deprecated, but not forgotten. [17:34] tedg: cool. thanks. i think only session and network remain. [17:34] Hmm, charles, do you have session open? ^ [17:34] We could perhaps exterminate. [17:34] tedg: yeah, i have support for it. but the icons are strings instead of serialised data, so need to update [17:35] tedg, session is still using sssb [17:35] imo all of them should be using a{sv} [17:35] tfb i'll leave in the support. [17:35] charles, I remembered you had a couple session things on your TODO. When you have it open, do you want to move it over? [17:36] That should be a small MR :-) [17:36] tedg, yes, I'll exterminate it [17:36] Woot! [17:36] tedg: you think you'll get a small MR out of me?! ha ha hahaha [17:36] No reformatting or dropping returns! [17:36] ;-) [17:36] * charles looks for a way to bloat the header action type MR to 100s of lines [17:37] tedg: I'll add "return;" everywhere [17:37] +1 [17:37] at the ends of functions [17:37] at the beginnings of functions [17:37] everywhere [17:38] tedg: if I add the to the beginning of both the code /and/ the tests, there won't be any regressions either [17:38] I need to get a better way to show exits from functions in VIM. I like the return because there's a big yellow marker there. [17:38] Perhaps some marker that is universal to no matter how you exit. [17:39] Wow, need a gtk_box. I haven't done GTK in so long. [17:40] Wait, grid. [17:40] :-) === naee is now known as eeanm === jhodapp|lunch is now known as jhodapp [18:47] sil2100, ping [21:07] bschaefer: ping! [21:07] bschaefer: hi! [21:07] bschaefer: sorry it took so long, but I have a massacre with the new flat [21:09] bschaefer: any luck with the new ibus? [21:12] sil2100, yeah, I was hoping to get someone to restart the daily build stuff to test it! [21:12] and now worries! [21:12] no* [21:13] sil2100, as I've pushed in a change to remove the gconf stuff we have in the ap tests, which should get around that error, but I wasn't able to reproduce on my machine [21:14] sil2100, well restart the AP tests for the daily build [21:23] Doing! [21:24] bschaefer: stack restarted [21:24] sil2100, awesome thanks! [21:24] * bschaefer hates not being able to reproduce errors on his machine === salem_ is now known as _salem