[13:10] <tsdgeos> davmor2: i can't reproduce https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1614070
[13:10] <tsdgeos> davmor2: it just rotates fine here :S
[13:11] <tsdgeos> Saviq: have you been able to reproduce ↑↑  ?
[13:11] <Saviq> tsdgeos, I've neither arale or turbo :/
[13:11] <Saviq> and it seems to be hw specific
[13:12] <davmor2> tsdgeos: what device are you on?
[13:12] <tsdgeos> davmor2: arale
[13:13] <davmor2> tsdgeos: arale is definitely doing it here
[13:14] <tsdgeos> davmor2: just to be sure what you're experiencing, is that the dash (or any app) doesn't rotate when rotating the phone, right?
[13:14] <davmor2> tsdgeos: anything but I tested and tailed on dash
[13:15] <davmor2> tsdgeos: ubuntu-device-flash touch --channel ubuntu-touch/rc-proposed/meizu.en --device arale --recovery-image ~/recovery-images/recovery-arale.img --bootstrap just to confirm we are flashing the same way
[13:17] <tsdgeos> davmor2: i'm not bootstrapping nor giving it a recovery image
[13:17] <tsdgeos> ubuntu-device-flash touch ubuntu-system --channel ubuntu-touch/rc-proposed/meizu.en
[13:17] <tsdgeos> here
[13:17] <tsdgeos> i cna try bootsrapping if you want
[13:17] <davmor2> tsdgeos: please you'll need the adb enabled recovery if you bootstrap
[13:18] <tsdgeos> davmor2: why?
[13:19] <davmor2> tsdgeos: without it it can't connect to recovery to do the flashing
[13:21] <tsdgeos> davmor2: i know it's a silly question, but just to make sure, you don't have the rotation lock enabled in the indicator, right?
[13:22] <davmor2> tsdgeos: nope and if you look at the paste in the bug you'll see it worked fine on the image before unity8 landed and died on the image after unity8 only change to the system was unity8
[14:00] <davmor2> tsdgeos: are you able to reproduce now?
[14:08] <tsdgeos> davmor2: nope
[14:09] <davmor2> tsdgeos: well we are reproducing it all over the place, turbo, krillin, arale, on fresh flashes jibel has reproduce on arale on upgrade but only after a reboot
[14:10] <tsdgeos> davmor2: must be the sun over here that makes it work
[14:12] <davmor2> rvr: is in the canaries I think sun has nothing to do with it ;)
[14:12] <davmor2> tsdgeos: ^
[14:12] <rvr> davmor2: he
[14:13] <tsdgeos> 26 (feels like 27) vs 28 (feels like 31)
[14:13] <tsdgeos> i still win
[14:20] <tsdgeos> davmor2: rvr: is something crashing?
[14:20] <tsdgeos> like the indicator or something
[14:23] <tsdgeos> i really can't reproduce
[14:23] <tsdgeos> rebooted like 10 times alrady
[15:09] <om26er> cimi, Hi!
[15:10] <om26er> cimi, I need to ask a bit about a recent change in unity8' artShapeLoader, in this branch: https://code.launchpad.net/~unity-team/unity8/unboxArtShapeLoader/+merge/298431
[15:13] <tsdgeos> om26er: ask
[15:14] <om26er> tsdgeos, the CroppedImageMinimumSourceSize in line 73, is that supposed to have visible:True when an image is being shown or False ?
[15:15] <om26er> tsdgeos, or to put should CroppedImageMinimumSourceSize be always visible when its parent artShapeLoader(line59) is visible ?
[15:16] <om26er> previously that was the case but with the above branch, CroppedImageMinimumSourceSize has its visible:False always. I thought thats a bug than intention.
[15:17] <tsdgeos> sorry? what do you mean CroppedImageMinimumSourceSize has visible: false always?
[15:20] <om26er> tsdgeos, the item CroppedImageMinimumSourceSize had its visible property `true` whenever its parent `artShapeLoader` was visible on screen. Today that is not the case.
[15:21] <om26er> CroppedImageMinimumSourceSize' visible property is always `false` now, which, I think is a bug.
[15:21] <tsdgeos> i don't know what you're talking about
[15:21] <tsdgeos> see 5.res
[15:21] <tsdgeos> there CroppedImageMinimumSourceSize visible property is true
[15:21] <tsdgeos> and i don't see how that branch changes anything
[15:21] <tsdgeos> since visible was and is
[15:22] <tsdgeos> visible: %4; \n\
[15:22] <tsdgeos> before and after the branch
[15:24] <om26er> tsdgeos, that's what I see in code after that branch our tests system-tests started to fail as they were selecting a visible CroppedImageMinimumSourceSize.
[15:24] <om26er> today if I do a autopilot search of the unity8-dash tree, none of the CroppedImageMinimumSourceSize has visible property as `true` anymore.
[15:25] <tsdgeos> none is a very strong word
[15:25] <tsdgeos> none of the ones you see
[15:26] <tsdgeos> and yes, only the concierge mode CroppedImageMinimumSourceSize should be set to true
[15:26] <tsdgeos> i'm sorry that you were using a wrong way to find stuff
[15:26] <om26er> I do dash.select_many('CroppedImageMinimumSourceSize', visible=True) it returns an empty list.
[15:27] <tsdgeos> correct
[15:27] <tsdgeos> what's the problem?
[15:28] <om26er> tsdgeos, I have to click a photo on the photo scope, based on its path on the device storage, I am filtering that by using `source` property of CroppedImageMinimumSourceSize
[15:29] <om26er> tsdgeos, a slightly different question: if artShapeLoader is visible, is the CroppedImageMinimumSourceSize also supposed to be `visible` ? Or it can vary.
[15:29] <om26er> ?
[15:30] <tsdgeos> om26er: it can vary
[15:30] <tsdgeos> that's why there's a
[15:30] <tsdgeos> visible: %4; \n\
[15:31] <tsdgeos> with %4 being isConciergeMode ? "true" : "false"
[15:32] <tsdgeos> om26er: so basically it should have almost ever been visible=true before either, may have been because some strange interaction, but basically you don't want to check for that
[15:33] <om26er> tsdgeos, good to know, I will change my code to artShapeLoader loader then, it has a artImage property which also contains the path of the image. Will that be fine ?
[15:34] <tsdgeos> om26er: artImage is the CroppedImageMinimumSourceSize
[15:36] <om26er> tsdgeos, right, thats correct, but artShapeLoader has a reference to artImage, see: http://paste.ubuntu.com/23064796/
[15:36] <tsdgeos> yes it has
[17:31] <mterry> Saviq: so about bug subscribers...  We currently have scripts that pay attention to unity-ui-bugs (rather than unity-ui-team).  Done because of a desire to avoid bugspam to team members.  We like to have bug subscribers for both a team that is in the scripts and a team that actually pays attention.  Ideally the same team.
[17:32] <mterry> If we don't mind the bugspam, we can switch scripts to look at unity-ui-team and sub them.  Else maybe just sub unity-ui-bugs and people can opt-in to bugs there
[17:43] <Saviq> mterry, ah you mean so that people can decide what they're subscribed to?
[17:44] <Saviq> sounds nice, we'll have to switch quite a bit of projects
[17:44] <Saviq> and make sure people know
[17:44] <mterry> Saviq: well I assume unity-ui-team is functional -- like we use that for LP permissions and what not.  If we are worried about bugspam to that team, we can use the existing opt-in team unity-ui-bugs.  (Though I don't know how anyone survives without heavy LP filtering anyway...)
[17:47] <om26er> When will application menus land in Unity8 ?
[17:50] <Saviq> om26er, under active work, some weeks out
[17:51] <om26er> Saviq, ok, are indicators also being worked on to be friendly on the desktop ?
[17:53] <om26er> another question: when will unity8 automatically scale on the desktop ? currently I have to add a environment variable
[17:56] <mterry> Saviq: it seems like unity-ui-team is already subscribed to most things.  In which case, the point of unity-ui-bugs is diminished.  The scripts might as well look at unity-ui-tea
[17:57] <Saviq> om26er, yes, pointer-friendly indicators are also under active work, will likely come before menus, as both need the same bits
[17:58] <Saviq> om26er, as for scaling we still need to decide a few things, especially wrt. how do clients request certain screen properties
[17:58]  * mterry goes afk
[17:59] <om26er> Saviq, thanks, a lot.
[23:49] <josharenson> Seeing a race in a test where a repeater says that its rendered (and the count is correct) but clicking a delegate isn't working sometimes... (a 1000 ms wait always fixes this). Anyone see anything like this?