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