[09:04] <Mirv> mzanetti: hey! we're seeing a crash and failing tests on utopic, could you take a look at that? http://ci.ubuntu.com/smokeng/utopic/touch/mako/267:20141003:20140929.1/10782/unity8/
[09:05] <tsdgeos> Mirv: he's not here today
[09:06] <tsdgeos> pstolowski: another upstream relase of unity-scopes-shell, can you merge again?
[09:06] <pstolowski> tsdgeos, yep
[09:07] <tsdgeos> Mirv: i'm having a look at those
[09:08] <tsdgeos> but honestly autopilot is awful and we should just not be using it is my answer every time an autopilot test fails
[09:08] <tsdgeos> no offsense to the autopilot developers
[09:12] <Mirv> tsdgeos: ok, thanks. maybe check the crash then instead :)
[09:17] <Cimi> tsdgeos, +1
[09:18] <Cimi> it can do some pretty cool things, but for us gives more false fails than real ones
[09:18] <Cimi> we don't pay attention to its failures anymore
[09:18] <Cimi> 90% is something broken in ap
[09:19] <tsdgeos> Cimi: can you do https://code.launchpad.net/~aacid/unity8/base_not_clickable/+merge/236835 https://code.launchpad.net/~aacid/unity8/overviewPreviewHideGotoScope/+merge/236926 ?
[09:19] <Cimi> only few times is a real test failing...
[09:19] <Cimi> tsdgeos, yes I can, I am out of features to work on today (finished yesterday)
[09:19] <Cimi> tsdgeos, throw me reviews/bugs
[09:50] <pstolowski> tsdgeos, yesterday's hotfix hasn't been merged yet into trunk, i'll updated feeds when it happens (should be soon)
[09:50] <tsdgeos> ok
[09:54] <pstolowski> tsdgeos, btw i'm working on displaying child feeds now, but that should be transparent for you
[09:54] <tsdgeos> pstolowski: not really, i'll have to paint them :D
[09:54] <tsdgeos> i'm not using a card in there, was not as flexible as we needed
[09:54] <pstolowski> tsdgeos, hmm, so we don't have subtitle already?
[09:54] <pstolowski> ah
[10:49] <tsdgeos> does anyone know at what point the SessionAuthorizer is created for qt apps?
[10:55] <Cimi> tsdgeos, first needs fixing, second approved
[10:57] <tsdgeos> Cimi: nah, it doesn't need fixing :P
[10:58] <Cimi> tsdgeos, oh yes it does :P
[11:06] <Cimi> tsdgeos, what you mean is a bugfix?
[11:06] <tsdgeos> Cimi: i mean i don't want to remove 100 lines of code to fix a thing when i can remove 1
[11:06] <tsdgeos> because removing 1 is easy
[11:06] <Cimi> tsdgeos, if we decide we don't want previews anymore in unity, we remove the previews, not we keep them but we remove the mouse area to enable them :)
[11:06] <tsdgeos> removing 100 makes lots of things break
[11:07] <tsdgeos> Cimi: that's a bad example
[11:07] <tsdgeos> but wathever
[11:07] <tsdgeos> you don't like it
[11:07] <tsdgeos> review the other MR
[11:07] <tsdgeos> and land them together
[11:07] <tsdgeos> it's not that hard, is it?
[11:07] <Cimi> tsdgeos, I much rather do...
[11:09] <tsdgeos> damnit i'm getting old
[11:09] <tsdgeos> does anyone remember the name of the function that tells you if there's anyone connected to a signal
[11:09] <tsdgeos> can't find it
[11:10] <tsdgeos> it is totally discouraged
[11:10] <tsdgeos> but i awnt it
[11:10] <Cimi> tsdgeos, qml, qt?
[11:10] <Cimi> I can help you googling :)
[11:11] <tsdgeos> qt
[11:12] <tsdgeos> i even remmeber the damn docu
[11:12] <tsdgeos> saying this can be used to save you for doing something heavy if noone is connected to your signal
[11:13] <Cimi> tsdgeos, you can see that from slots?
[11:13] <tsdgeos> foundit
[11:13] <tsdgeos> damnit
[11:13] <tsdgeos> bool QObject::isSignalConnected(const QMetaMethod & signal) const [protected]
[11:14] <Cimi> cool
[11:14] <tsdgeos> Cimi: see what?
[11:14] <Cimi> tsdgeos, neverming
[11:15] <Cimi> tsdgeos, anyway, can you resubmit the branch killing base without that prerequisite?
[11:15] <tsdgeos> no?
[11:15] <tsdgeos> why
[11:16] <Cimi> tsdgeos, because we don't need the first if we do the latter, no?
[11:17] <Cimi> tsdgeos, I see your point of bugfixing and stuff, I always been told from saviq that if we remove a feature, we do it completely (removing all unneeded code)
[11:17] <tsdgeos> well we do because it's a prerequisite :D
[11:18] <Cimi> tsdgeos, what is your opinion?
[11:19] <tsdgeos> my opinion is that there is one liner that fixes a bug
[11:19] <tsdgeos> and then there's a MR that cleans up shit copied and pasted code we have from god knows where
[11:19] <Cimi> tsdgeos, it is one liner but implies that we should get rid of all this shit code with it anyway...
[11:20] <tsdgeos> Cimi: not really
[11:20] <tsdgeos> we could remove the highlighter
[11:20] <tsdgeos> without removing the abstractbutton
[11:20] <tsdgeos> or leave the hightlighter and remove the abstractbutton
[11:20] <Cimi> I think we should do both at the same time no?
[11:20] <Cimi> change to Item and remove highlight
[11:20] <tsdgeos> why?
[11:21] <tsdgeos> why in your mind is not valid to have an Item with highlight?
[11:21] <dandrader_> tsdgeos, that launcher test is driving me nuts. I don't understand why it sometimes refuses to flick. will check if reverting the test refactoring make this instability go away. very frustrating
[11:21] <Cimi> because if we don't want the highlight we don;'t need the button and we don;t need the style for the highlight
[11:21] <tsdgeos> Cimi: but as you can see the highlight is not related at all with the button
[11:21] <tsdgeos> so they are two separate things
[11:22] <tsdgeos> one could higlight based on the moon phases
[11:22] <tsdgeos> wihtout the need of a button
[11:22] <Cimi> :)
[11:22] <Cimi> I like your humor :)
[11:22] <dandrader_> tsdgeos, but that tip of running xvfbtest in a loop until it fails is a great one. I noticed xvfbtest is siginificantly slower than the regular test
[11:22] <tsdgeos> Cimi: thank you
[11:22] <tsdgeos> Cimi: but really
[11:22] <tsdgeos> pressed: emptyListItem.selected
[11:23] <tsdgeos> and then
[11:23] <tsdgeos>  property bool selected: false
[11:23] <tsdgeos> it is a spearate thing
[11:23] <tsdgeos> sure your mind tells you it will be linked to a button and thn you see the button remove dna you say to remove it
[11:23] <tsdgeos> but it's not really linked
[11:24] <tsdgeos> no?
[11:24] <tsdgeos> actually wait
[11:24] <tsdgeos> because i may be lying :D
[11:32] <Cimi> tsdgeos, I am just checking if we can remove it
[11:32] <tsdgeos> remove what? the higlighter?
[11:32] <tsdgeos> it's removed in the other MR
[11:32] <Cimi> tsdgeos, since grepping for ListItems reveals imports in panel and launcher
[11:32] <tsdgeos> yeah
[11:32] <tsdgeos> but not used there
[11:32] <tsdgeos> but pelase double check
[11:34] <Cimi> tsdgeos, so we can remove those imports as well :)
[11:35] <tsdgeos> Cimi: no
[11:35] <tsdgeos> and even if we could
[11:35] <tsdgeos> they have nothing to do with this
[11:35] <tsdgeos> if you continue like that
[11:35] <tsdgeos> i will have to fix all of the current bugs and put them in a single MR
[11:40] <Cimi> tsdgeos, ahah ok I stop
[11:40] <tsdgeos> Cimi: but actually you where right the first one is not totally correct
[11:41] <tsdgeos> i've fixed it now so that highlight is actually dependent on the selected property only
[11:41] <tsdgeos> and not on a possible pressed state since it can't be pressed anymore
[11:41] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/base_not_clickable/+merge/236835
[11:41] <tsdgeos> now the guy that devided to call the root of that item emptyListItem
[11:41] <tsdgeos> bad naming :D
[11:42] <Cimi> tsdgeos, did you bzr blame? :)
[11:43] <tsdgeos> nah
[11:43] <tsdgeos> it may even be me
[11:43] <tsdgeos> doon't think so though
[11:43] <tsdgeos> and i'd say this was copied from the sdk
[11:43] <tsdgeos> or smeels like it
[11:44] <Cimi> tsdgeos, saviq
[11:44] <Cimi> tsdgeos, but at revision 1
[11:44] <Cimi> so...
[11:44] <Cimi> it doesn't say
[11:44] <Cimi> anyway
[11:44] <Cimi> much better now
[11:44] <tsdgeos> this history is new anyway
[11:44] <tsdgeos> we moved repo like 3 times
[11:44] <tsdgeos> losing history afair
[11:46] <Cimi> tsdgeos, it was done on purpose to forget the past :)
[11:47] <Cimi> we cannot blame anyone anymore :)
[11:48] <tsdgeos> :)
[12:03] <Cimi> tsdgeos, was it actually working before?
[12:03] <Cimi> pressed: (emptyListItem.selected || (emptyListItem.highlightWhenPressed && emptyListItem.pressed)) ? "pressed" : ""
[12:03] <Cimi> pressed is a bool, not a string :)
[12:03] <Cimi> unless "pressed" evaluated true
[12:38] <mterry> dednick, heyo!  Got a moment to talk indicator UI code?
[12:40] <mterry> dednick, I'm trying to allow the indicators to swap between two different profiles (essentially two different menuObjectPaths).  I've done some work to cache the menus from dbus.  But now I'm hitting what looks like a delay in populating the UI elements inside the indicator menucontent
[12:45] <tsdgeos> Cimi: it's javascript
[12:45] <tsdgeos> it does magic
[12:45] <dandrader_> tsdgeos, tst_Launcher should finally work reliably in touchOverview branch
[12:45] <tsdgeos> dandrader_: cool
[12:46] <dandrader_> tsdgeos, did you test pressing the top left key in the vkb?
[12:46] <dandrader_> tsdgeos, that was the most prominent case this MP solves
[12:47] <tsdgeos> dandrader_: shouldn't it also fix what i mention as a comment?
[12:47] <dandrader_> tsdgeos, I replied to it
[12:47] <tsdgeos> ah
[12:47] <tsdgeos> just came back from lunch
[12:47] <tsdgeos> ^_^
[12:47]  * tsdgeos reads
[12:47] <tsdgeos> AlbertA: ping
[12:48] <dandrader_> tsdgeos, actually, now that I checked the code. it seems PhoneStage animates the right edge as soon as the drag starts, regardless of whether the EdgeDragArea has already recognized is and an edge-drag or not
[12:48] <tsdgeos> may be
[12:49] <dandrader_> tsdgeos, but the problem is that the right-edge animation moves the ap window away
[12:49] <dandrader_> tsdgeos, so the tap ends up as a short drag from the app window's point of view. which aggravates the issue
[13:35] <mterry> If I pass an object from C++ to Qml, Qml owns that object, right?  And will delete it at will?  But what if that object has a parent?  Then will Qml back off?
[13:47] <dandrader> tsdgeos, fixed the "tapping on the right edge of the screen" issue
[13:47] <dandrader> tsdgeos, you can now easily tap on the category selector button in the dash for instance(that down-pointed arrow on the far right)
[13:47] <tsdgeos> mterry: http://qt-project.org/doc/qt-5/qtqml-cppintegration-data.html#data-ownership
[13:47] <tsdgeos> dandrader: cool
[13:47] <tsdgeos> let's rebuild the ppa
[13:47] <tsdgeos> pstolowski: how's the merge going?
[13:48] <mterry> tsdgeos, nice so it won't touch an object with a parent, makes sense
[13:48] <dandrader> tsdgeos, so now that right-edge animation only starts to move the app window once the gesture has been recognized
[13:48] <tsdgeos> which i guess makes sense
[13:50] <tsdgeos> pstolowski: no merge from trunk yet? :/
[13:50] <pstolowski> tsdgeos, merge still didn't happen
[13:50] <tsdgeos> pstolowski: but trunk has a newer version than our packages
[13:50] <pstolowski> ted, line #78 in the ci sheet
[13:50] <tsdgeos> pstolowski: so it won't get picked from ppa unless you merge, no?
[13:50] <pstolowski> tsdgeos, do you have the changes i put yesterday?
[13:51] <tsdgeos> pstolowski: i have everything from the feeds branch
[13:51]  * ted Is confused, did you mean tsdgeos ?
[13:51] <pstolowski> ted, sure, sorry ;)
[13:52] <pstolowski> tsdgeos, i merged trunk into feeds yesterday as we landed some stuff. after that we requested one more MP, but it's not merged yet
[13:52] <tsdgeos> pstolowski: then why is feeds older than trunk?
[13:53] <tsdgeos> hmmm
[13:53] <tsdgeos> because i may be missing a rebuild :d
[13:53]  * tsdgeos clicks the button
[13:54] <pstolowski> tsdgeos, ah, good. http://pastebin.ubuntu.com/8486034/
[13:55] <tsdgeos> yeah i saw :/
[13:55] <tsdgeos> sorry for the noize
[13:55] <pstolowski> (and of course nothing to push)
[13:55] <pstolowski> tsdgeos, np
[13:59] <pstolowski> tsdgeos, can you start displaying subtitle role if not empty (will be empty for a while in all cases, but i'm working on a separate branch that will populate it)
[14:00] <pstolowski> ?
[14:02] <tsdgeos> pstolowski: i am juggling lots of things atm, will try to get it done before eod, if not on monday
[14:02] <pstolowski> tsdgeos, ok, no worries, next week is fine
[14:05] <tsdgeos> dednick: is it possible that all the ap tests for indicators are borked?
[14:06] <dednick> tsdgeos: it is always possible.
[14:07] <tsdgeos> dednick: looking for objectName in DefaultIndicatorPage objects
[14:07] <tsdgeos> and from a quick grep i think you don't set that anymore?
[14:07] <tsdgeos> dandrader: you're reviewing the wrong MP :D
[14:08] <dandrader> crap
[14:09] <dednick> tsdgeos: erm. i don't rember changing it, but i can see that it should be set.
[14:09] <dednick> tsdgeos: got a link?
[14:09] <tsdgeos> to the failures? it was a local fail let me see if there's something in the internets
[14:10] <dandrader> tsdgeos, mind if I delete that proposal then?
[14:10] <tsdgeos> dandrader: well it's clearly marked as superseeded and has a link to the other, but as you wish
[14:12] <dandrader> tsdgeos, still does it rely on an unreleased unity-api?
[14:12] <dandrader> tsdgeos, becaue of "libunity-api-dev (>= 7.92),"
[14:13] <tsdgeos> dandrader: yes and no
[14:13] <dandrader> tsdgeos, speak
[14:13] <tsdgeos> only because i decided to base it on top of that other branch that we are landing as part of silo19
[14:13] <dandrader> tsdgeos, ah, it has a prerequisite
[14:13] <tsdgeos> which i am pretty sure doesn't really need to be based off, but helps with potential conflicts
[14:14] <tsdgeos> dandrader: yeah
[14:14] <tsdgeos> as marked in the MR
[14:14] <tsdgeos> :D
[14:14] <dandrader> yes, just noticed it
[14:16] <tsdgeos> dednick: using silo 19 i get stuff like http://paste.ubuntu.com/8486151/
[14:18] <dednick> tsdgeos: ok. i'll take a look. something obviously isn't connected up correctly anymore
[14:23] <tsdgeos> dednick: cool tx
[14:25] <AlbertA> tsdgeos: pong
[14:25] <tsdgeos> AlbertA: did you ever get to record the video for the screen capture you promised in the bug?
[14:27] <AlbertA> tsdgeos: oh sorry no...I got pulled into some bug hunting/fixing...
[14:27] <AlbertA> lemme try and do that right now
[14:55] <tsdgeos> dandrader|afk: if you have some time i fixed your comment in https://code.launchpad.net/~aacid/unity8/fix_left_swipe_temp_scope_overview/+merge/236552
[15:09] <paulliu> dednick: I've add a comment on the merge request https://code.launchpad.net/~nick-dedekind/unity8/lp1336715-checkable-bindings/+merge/234503
[15:12] <dednick> paulliu: ta. so you were still able to get the flight-mode out of sync? or was it that flight mode & wifi were both turned on?
[15:14] <paulliu> dednick: yes. But very hard.
[15:15] <paulliu> dednick: Yes, that's flight mode & wifi both turned on after non-sync.
[15:15] <dednick> dednick: but still in sync with the flight mode in system settings?
[15:15] <dednick> paulliu: ^
[15:16] <paulliu> dednick: Not sure. Let me try again.
[15:16] <dednick> paulliu: ok, if you get it out of sync, can you run a command on ssh for me?
[15:16] <paulliu> dednick: Because have to do that very fast. I just pull the full indicators down.
[15:16] <paulliu> dednick: sure.
[15:16] <dednick> give me a sec
[15:17] <paulliu> Wait. I found we can turn on Flight mode and then turn on WiFi.
[15:17] <paulliu> What's that?
[15:20] <dandrader> tsdgeos, ok
[15:20] <paulliu> dednick: rfkill list tells me that turn on WiFi will turn off the Soft block of WiFi.
[15:21] <dednick> paulliu: dbus-send --print-reply --session --dest=com.canonical.indicator.network /com/canonical/indicator/network org.gtk.Actions.DescribeAll
[15:21] <dednick> paulliu: yeah, i think if you manually turn on wifi when flight mode is on, then it allows it to be on.
[15:28] <paulliu> dednick: http://paste.ubuntu.com/8486539/
[15:29] <paulliu> dednick: Settings flight mode is off. Indicator flight mode is on. And it automatically connects to WiFi.
[15:32] <paulliu> dednick: http://tinyurl.com/nq3txw9
[15:35] <dednick> paulliu: and thats with my branch?
[15:36] <paulliu> dednick: yes.
[15:36] <dednick> paulliu: doh. thanks
[15:37] <dednick> kgunn: ^ still seems to be a problem with the flight mode switch. going to need more investigations
[15:38] <paulliu> dednick: I've installed MenuItemFactory.qml to /usr/share/unity8/Panel/Indicators md5sum is df4600201f8fdfbd46c4d281f8a7b5f5
[15:39] <paulliu> dednick: You have to push indicators very fast to get it non-sync.
[15:40] <paulliu> dednick: Faster than any rhythm games I think.
[15:40] <dednick> paulliu: heh. yeah still a but though :/
[15:42] <kgunn> tah
[15:43] <kgunn> mterry: looks like dednick might be reworking that checkable-bindings branch ^
[15:43] <mterry> kgunn, hah!  procrastination for the win
[15:43] <kgunn> :)
[15:45] <dednick> hm. one possiblity is that the server didnt respond to the change in the check status from the indicator
[15:46] <dednick> only way to know that is if the system settings one does the same thing though...
[15:47] <dednick> there's no validation on update.
[15:47] <dandrader> racarr, would you have some time to review that? https://code.launchpad.net/~dandrader/platform-api/removeMirClipboard/+merge/237094
[15:47] <dandrader> racarr, not high priority though
[15:47] <dednick> other possibility is that my code is shit. but that cant be right...
[18:15] <dandrader> racarr, thanks for the review. you can top-approve as well
[18:28] <racarr> dandrader: Np