[08:55] <pstolowski> Cimi, morning! did you have a chance to test fix-temp-scopes branch of shell plugin?
[09:12] <tsdgeos> Saviq: so what do we do with https://code.launchpad.net/~ted/unity8/delay-indicator-start/+merge/241124 ? ask ted for improvements? approve? discard
[09:12] <tsdgeos> ?
[09:13] <tsdgeos> Cimi: what's missing for a top approval in https://code.launchpad.net/~mterry/unity8/tutorial-refactor/+merge/239874 ?
[09:15] <Saviq> tsdgeos, I think we can discard, will talk to Ted later today
[09:15] <tsdgeos> oki
[09:26] <Cimi> pstolowski, all looks fine
[09:26] <Cimi> thanks :)
[09:27] <Cimi> tsdgeos, I need to re-review the latest changes
[09:27] <Cimi> tsdgeos, it was on hold for design
[09:27] <tsdgeos> i see
[09:30] <Saviq> seb128, bug #1415141 and bug #1417773
[09:32] <seb128> Saviq, not sure, have a "t a a bt" rather than "bt" would be more useful
[09:32] <seb128> rsalveti, ^
[09:32] <seb128> mine had libqnmbearer.so in the bt
[09:32] <seb128> https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1417525 btw
[09:38] <dandrader> tsdgeos, hey
[09:38] <dandrader> tsdgeos, about lp:~dandrader/unity8/indicatorsBarEatsAllInput
[09:38] <dandrader> tsdgeos, you mean that you open the indicators (on a tablet)
[09:38] <dandrader> tsdgeos, then tap several times on the greyed out area
[09:38] <dandrader> tsdgeos, the first tap will make the indicators panel close
[09:38] <tsdgeos> no no
[09:39] <tsdgeos> not the greyed out area
[09:39] <tsdgeos> the top bar
[09:39] <dandrader> tsdgeos, and the subsequent ones will make the foreground app blink
[09:39] <tsdgeos> basically if you press just in the between of the top bar and the greyed area
[09:39] <tsdgeos> but since that's hard that i do is start pressing in the middle of the top bar and then go slowly done
[09:39] <tsdgeos> down
[09:39] <tsdgeos> so eventually i get to the right place
[09:40] <dandrader> greyback, https://launchpadlibrarian.net/196557582/buildlog_ubuntu-vivid-amd64.unity8_8.02.4%2Bbzr1570~ubuntu15.04.1_FAILEDTOBUILD.txt.gz
[09:41] <tsdgeos> dandrader: does that make sense? or want a video?
[09:44] <dandrader> tsdgeos, video
[09:44] <dandrader> tsdgeos, but its it the same thing as what I explained? do you also get this issue? isn't it the same thing?
[09:44] <tsdgeos> it is the same thing
[09:44] <dandrader> tsdgeos, like just tapping in the center of the greyed-out area
[09:45] <tsdgeos> there's just one pixel instead of whole area from before
[09:45] <dandrader> tsdgeos, so what you're hitting is just the very edge of the greyed out are I guess
[09:45] <tsdgeos> guess so yes
[09:45] <dandrader> tsdgeos, its very first, top, row of pixes
[09:47] <tsdgeos> dandrader: let me try to record the video
[09:54] <tsdgeos> dandrader: it's uploading, will tell you once my poor upload link is done
[09:56] <tsdgeos> dandrader: https://www.youtube.com/watch?v=zfsdVA1ZyC8
[10:02] <dandrader> tsdgeos, would you get the very same behavior (and bug) if you tapped right in the middle of the app area not covered by the indicators bar?
[10:03] <tsdgeos> you mean "over the app"?
[10:03] <dandrader> tsdgeos, yes
[10:04] <tsdgeos> no, over the app is fine
[10:04] <tsdgeos> just hides the indicators and that's it
[10:04] <dandrader> tsdgeos, weird. that's not what I get
[10:05] <dandrader> tsdgeos, even if you tap fastly, multiple times ?
[10:05] <tsdgeos> ah you're right, it does happen ^_^
[10:05]  * dandrader wonders if the bug is more evident in the shellRotation branch...
[10:05] <tsdgeos> so it's not just one pixel, it's just pressing fast two times
[10:06] <tsdgeos> so you're right this may be a different bug
[10:06] <dandrader> tsdgeos, so it's the indicator's darkened area that lets input go through while the closing animation is playing
[10:06] <tsdgeos> dandrader: do you want me to check if this happened before and we treat it as a different bug or want to fix it together?
[10:07] <dandrader> tsdgeos, also the flicker is more evident if you have only unity8-dash running
[10:07] <dandrader> tsdgeos, as it will flicker between the white dash ui and the black background
[10:08] <tsdgeos> lol yeah
[10:09] <Saviq> duflu, dandrader http://doc.qt.io/qt-5/qml-qtquick-propertyanimation.html#easing.type-prop
[10:09] <dandrader> tsdgeos, so will you approve the branch then? :-)
[10:10] <tsdgeos> dandrader: sure i'll have another look and open a separate bug for the other thing
[10:10] <dandrader> tsdgeos, ok, thanks!
[11:29] <tsdgeos> damn this internal compiler error
[11:29] <tsdgeos> Saviq: i guess it's making us unlandeable?
[11:29] <Saviq> tsdgeos, yes
[11:29] <Saviq> tsdgeos, people are working on it
[11:29] <tsdgeos> :/
[11:29] <tsdgeos> :)
[12:01] <tsdgeos> Cimi: ping
[12:02] <tsdgeos> Cimi: unping
[12:02] <Cimi> tsdgeos, lol
[12:19] <Cimi_> tsdgeos, https://code.launchpad.net/~cimi/unity8/fix-open-new-scope-from-tmp/+merge/248538
[12:20]  * tsdgeos clicks the button
[12:40] <Saviq> larsu, just so you know https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1385331/comments/9
[12:40] <larsu> thanks
[13:20] <Saviq> @unity: I've a workaround for the armhf compile error, want to just check it in to trunk so that no one has to wait, any opposition http://paste.ubuntu.com/10053410/ ?
[13:21] <mzanetti> +1
[13:21] <mterry> Saviq, +1
[13:21] <mterry> Saviq, make sure you don't have tags  ;)
[13:21] <Saviq> mterry, ;)
[13:21] <Saviq> mterry, I actually do (thanks to colo), but I'll strip them right after
[13:23] <Saviq> @unity: we're back in (unity8 on armhf) building business
[13:23] <dandrader> nice
[13:40] <Saviq> olli, FYI, got a workaround from doko+slangasek for the unity8 build issue, we're unblocked
[13:40] <olli> saweet, what was the issue?
[13:40] <olli> sumding in the toolchain?
[13:40] <olli> Saviq, ^
[13:41] <Saviq> olli, yeah, new gcc release
[13:42] <Saviq> olli, would've known that yesterday already if I realized that silos have proposed enabled (and I was having trouble reproducing, because the new gcc was in proposed still, is moved to release now)
[13:42] <Saviq> s/realized/remembered/
[13:46] <olli> Saviq, thx
[13:46]  * olli takes notes
[14:43] <om26er> MacSlow, Hi!
[14:43] <MacSlow> om26er, hey there
[14:43] <om26er> MacSlow, is there a way to disable the OSD during testing ?
[14:44] <MacSlow> om26er, the tests themselves or the daemon?
[14:44] <om26er> I am trying to fix an Autopilot test for messaging-app and the notifications block the searchbar
[14:44] <om26er> MacSlow, the daemon
[14:45] <MacSlow> om26er, hm...
[14:46] <MacSlow> om26er, can you recompile?
[14:46] <om26er> MacSlow, ahm, no the tests are supposed to run on production
[14:47] <om26er> MacSlow, can't I just stop the notifications service ?
[14:47] <MacSlow> om26er, that would probably be the best idea
[14:47] <MacSlow> but it's a plugin in unity8...
[14:48] <MacSlow> om26er, so it's different from the regular (old-school) desktop notify-osd
[14:48] <om26er> MacSlow, right, I'll try to find other solutions then.
[14:48] <MacSlow> om26er, wait there's a way... once sec
[14:50] <om26er> great :)
[14:51] <MacSlow> om26er, hm... getting rid of /usr/share/dbus-1/services/org.freedesktop.Notifications.service (move it some where else) and restart dbus
[14:51] <MacSlow> om26er, I think that should do the trick
[14:52] <MacSlow> om26er, wait...
[14:54] <MacSlow> om26er, the first idea just disables (old) notify-osd...
[14:54] <Saviq> om26er, I imagine you're talking about an automated, reliable way to do this?
[14:55] <MacSlow> Saviq, I'm wondering if one can disable a single unity8 plugin at runtime
[14:55] <Saviq> MacSlow, I'd say that's the wrong direction
[14:55] <om26er> Saviq, yeah, something like that. Perhaps a gsetting key or some kind of thing
[14:55] <Saviq> om26er, that sounds like we want an autopilot emulator for notifications, where you can actually verify the notification is showing up, and wait for it to close (or interact with it)
[14:56] <MacSlow> Saviq, I know of nothing in unity-notifications that would allow it being disabled at runtime... just uninstaling it, but that's not an option for om26er's needs
[14:56] <om26er> Saviq, that can take a while in cases where we rush 5-6 notifications together. But yes, sounds like a solution in the end.
[14:57] <om26er> initctl stop unity8-notifications :D *dreams*
[14:59] <MacSlow> om26er, but you want something that works for now right
[15:00] <om26er> MacSlow, indeed.
[15:00] <MacSlow> Saviq, I guess that "initctl stop unity8-notifications" is another bullet-point on the nice-to-have list then?!
[15:03] <Saviq> MacSlow, not really, we don't (and I don't imagine we will) have a notification daemon
[15:04] <Saviq> om26er, that helper might have an option to disable it for a while if you need it
[15:04] <MacSlow> Saviq, well in the long run... but currently we kind of still have
[15:04] <Saviq> om26er, or just "consume" them all as they come in
[15:04] <Saviq> MacSlow, no, it's part of the shell
[15:05] <MacSlow> om26er, btw... you just want them to now show up (and block input to surfaces below), right?
[15:05] <MacSlow> s/now/not
[15:05] <Saviq> MacSlow, and it will remain that, even if we'll get the post office in between
[15:05] <Saviq> in which case it might be possible to stop the post office, but that still feels like the bad solution to me ;)
[15:06] <om26er> Saviq, yes I think if we can disable it for a few seconds our purpose will fulfill
[15:06] <om26er> MacSlow, exactly.
[15:06] <Saviq> om26er, if you don't care about the process, couldn't you just prepare the history db before starting the test?
[15:07] <om26er> Saviq, thats one option I was going to look into.
[15:07] <om26er> or create messages before the app starts.
[15:08] <Saviq> om26er, I think there's other, better solutions for this issue indeed :)
[15:10] <MacSlow> om26er, I currently can't think of a way to disable the notifications without messing around with the sourcecode.
[15:11] <om26er> MacSlow, that's fine, I'll discuss with the messaging-app devs for a solution at the history service's end.
[15:11] <MacSlow> om26er, one could change the dbus-interface name and recompile unity-notifications... or - on the unit8-side/QML - make the notification-renderer swallow all notifications
[15:12] <MacSlow> om26er, sorry for the touble
[15:36] <Saviq> MacSlow, has there been a design review of swipe-to-dismiss?
[15:37] <MacSlow> Saviq, yes... that happened looong ago
[15:38]  * Saviq hopes that we'll get the ability to dismiss sds just as well (i.e. dismiss, not reject, in terms of an incoming call)
[15:39] <MacSlow> Saviq, an expanded snap-decision can't be dismissed (closed)... that's by design... collapsed snap-decisions can though
[15:39] <Saviq> oh ok
[15:40] <MacSlow> Saviq, and that's also covered in the qmltest for them
[16:07] <dandrader> tsdgeos, how do I get rid of this silliness? paste.ubuntu.com/10055796/
[16:08] <tsdgeos> export LC_ALL=C ?
[16:08] <dandrader> it's the most diehard qmltest failure we have
[16:08]  * dandrader tries
[16:08] <tsdgeos> or en_US
[16:08] <tsdgeos> or something don't remember
[16:08] <tsdgeos> i usually just run with -i -k
[16:08] <tsdgeos> and then serach for the fail! and if they're this i ignore them :D
[16:09] <tsdgeos> lazy man
[16:16] <Saviq> MacSlow, testNotifications fails for me fairly often: http://paste.ubuntu.com/10055920/
[16:16] <Saviq> (the new one)
[16:17] <Saviq> MacSlow, looks like that failure https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/360/testReport/junit/%28root%29/qmltestrunner/NotificationRendererTest__test_NotificationRenderer/
[16:17] <tsdgeos> Saviq: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1411748 doesn't affect rtm since the code it's fixing is not part of rtm (or wasn't last time i checked)
[16:18] <Saviq> tsdgeos, hmm hmm... news scope on arale, though, not there outside of rtm?
[16:18] <tsdgeos> arale is vivid-based i've been told
[16:18] <Saviq> tsdgeos, ok then I've no way to see that bug
[16:19] <tsdgeos> Saviq: why not? just install vivid on a krillin?
[16:19] <Saviq> and well, there is an rtm channel for it (I'm using... trying to...)
[16:19] <Saviq> tsdgeos, no news scope
[16:19] <Saviq> or is there?
[16:19] <MacSlow> Saviq, yeah... I will look into that.
[16:19] <Saviq> don't think there is
[16:19] <tsdgeos> maybe not
[16:19] <tsdgeos> Saviq: what i did was just get krillin rtm, add the patch that breaks this and then add the patch that fixes it
[16:20] <tsdgeos> ^_^
[16:20] <Saviq> tsdgeos, ;)
[16:26] <mzanetti> kdub: libevdev2 libmirplatform6 libmirserver29 mir-platform-graphics-android mir-platform-graphics-mesa
[16:26] <mzanetti> sorry... should have been kgunn..
[16:26] <kdub> :)
[17:12] <seb128> Saviq, qtmir update in vivid today? ;-)
[17:12] <seb128> I could use a working desktop daily tomorrow
[17:13] <Saviq> seb128, out of my hands, camako and racarr are landing new mir with qtmir now...
[17:13] <seb128> k
[17:13] <Saviq> seb128, let me know if you want just a fixed qtmir package
[17:13] <seb128> well, depending when the other set lands
[17:14] <seb128> I would like to see the gtk fix to land this week
[17:14] <seb128> it would make some of our testing/work easier
[17:14] <seb128> up to you what form that landing takes
[17:15] <Saviq> seb128, I'll find out how the guys are doing and land it myself if needed, before the end of the week
[17:15] <seb128> thanks
[18:24] <tvw> I am using Unity on ubuntu, since I am more a terminal user than a gui-user. No I wonder what desktop environment is best for people who prefer to use a mouse and a gui interface?
[23:39] <mterry> Is anyone familiar with what differences exist between tryTest and testTest?  I've got this problem where a DirectionalDragArea isn't working in testTest but does in tryTest...  :(