[00:20] <kgunn> lpotter: whachya need ?
[00:21] <lpotter> just saying hello :)
[00:25] <lpotter> actually kind of wondering how that InputDevice thing is working
[00:32] <kgunn> lpotter: been working quite well afaict, we're using it pretty heavily for switching in/out of our windowed mode
[00:33] <lpotter> ya I noticed the windowed mode when I connected a bluetooth keyboard recently
[00:35] <lpotter> am I correct that mako has hdmi support?
[00:36] <lpotter> via usb->hdmi adaptor
=== pete-woods1 is now known as pete-woods
[09:40] <tsdgeos> dednick: you there?
[09:41] <dednick> tsdgeos: I am there.
[09:41] <dednick> I am everywhere
[09:42] <tsdgeos> dednick: you' ve been doing "frame painting" things lately right? I am investigating this issue in unity8-dash on the desktop in which it gets stuck without painting anything until you restart it. I've added some debug and i've confirmed the items are being created so it may be a "stuff is not getting put on screen" thing. Any idea where i'd put a debug to know if stuff is being asked to be painted?
[09:42] <tsdgeos> dednick: "All is All" re-zoolander 2 trailer by cumberbatch :D
[09:43] <dednick> tsdgeos: you can use the qt render loop debugging
[09:43] <tsdgeos> right
[09:44] <dednick> tsdgeos: QSG_RENDERER_DEBUG=render gives shed loads. cant remember the simple one..
[09:45] <dednick> tsdgeos: are you wanting to know if specific items are painting?
[09:45] <tsdgeos> no
[09:45] <tsdgeos> it just seems that something got stuck
[09:45] <tsdgeos> either the qt render loop
[09:45] <dednick> tsdgeos: whole shell?
[09:45] <dednick> tsdgeos: ah. k
[09:45] <tsdgeos> dednick: unity8-dash
[09:46] <dednick> tsdgeos: shell still responding?
[09:46] <tsdgeos> dednick: shell is fine
[09:46] <dednick> tsdgeos: right. you can test the client using  'restart unity8-dash QSG_RENDERER_DEBUG=render"
[09:47] <tsdgeos> dednick: nope, as said if i restart it, all is fine D:
[09:47] <tsdgeos> is just the first time that fails
[09:47] <dednick> tsdgeos: ah. k :/
[09:47] <tsdgeos> i'll put the QSG_RENDERER_DEBUG=render in the upstart file
[09:47] <dednick> put it in the upstart
[09:47] <tsdgeos> and see what's up
[09:47] <dednick> ok
[09:48] <dednick> tsdgeos: it could be qtmir surface item related if you're still seeing client render logs while you're giving the dash surface touch events..
[09:49] <dednick> we've been having a few issues getting it in states where it stops rendering recently.
[10:03] <tsdgeos> dednick: so it would seem from the output of QSG_RENDERER_DEBUG=render that it is actually rendering things
[10:03] <dednick> tsdgeos: what version of unity8 you running?
[10:04] <tsdgeos> dednick: xenial latest
[10:04] <dednick> tsdgeos: sorry, qtmir
[10:04] <tsdgeos> same :D
[10:04] <tsdgeos> 0.4.6+16.04.20151102-0ubuntu1
[10:05] <dednick> tsdgeos: ah. looks like updates havent landed in xenial.
[10:05] <dednick> i mean been released to image.
[10:06] <dednick> tsdgeos: 0.4.6+16.04.20151113-0ubuntu1 is latest.
[10:06] <tsdgeos> what's the point of having a development version
[10:06] <tsdgeos> that is outdated
[10:06] <tsdgeos> sigh
[10:06] <dednick> tsdgeos: 1102 still has the occlusion in it.
[10:06] <tsdgeos> dednick: can i just recompile qtmir and install it or will i need more stuff?
[10:07] <dednick> tsdgeos: i have no idea why things aren't getting updated in xenial
[10:07] <dednick> tsdgeos: yup
[10:07] <tsdgeos> sure not blaming you
[10:07] <tsdgeos> more than a wish setence :D
[10:07] <dednick> i think it's still compatible.
[10:07] <dednick> :)
[10:07] <tsdgeos> k, let me recompile and see if then it's gone
[10:08] <dednick> tsdgeos: remember -DNO_TESTS=1 . much faster
[10:09] <tsdgeos> too late :D
[10:16] <tsdgeos> damn the tests failed :S
[10:17] <tsdgeos> maybe that's why is still not on xenial ?
[10:17] <tsdgeos> dednick: greyback__: do you know if tests should succeed on xenail
[10:17] <tsdgeos> i have
[10:17] <tsdgeos> http://paste.ubuntu.com/13343660/
[10:18] <greyback__> tsdgeos: hmm, there's no reason I'm aware of that they shouldn't. Lemme check
[10:19] <greyback__> ltinkl: hey, did you see https://code.launchpad.net/~lukas-kde/qtmir/fixWheel/+merge/276252/comments/703276
[10:21] <dednick> tsdgeos: they should do. i always do tests on laptop.
[10:21] <tsdgeos> weird
[10:22] <tsdgeos> anyhow compiling without tests now D:
[10:22] <dednick> although the shared wakelock used to be a bit flaky i havent seen an issue lately
=== alan_g is now known as alan_g|test
=== alan_g|test is now known as alan_g
[10:41] <tsdgeos> dednick: yeah so the new qtmir fixes it
[10:41] <tsdgeos> *BUT* now i get a crash every time i log otu
[10:41] <tsdgeos> i didn't use to
[10:41] <tsdgeos> the crash backtrace is a bit unexplanatory, just quickitems destructors one after other
[10:41] <tsdgeos> greyback__: dednick: do you guys want it?
[10:42] <greyback__> tsdgeos: sure
=== greyback__ is now known as greyback
[10:42] <tsdgeos> let me repeat
[10:43] <greyback> did it look like this: https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8%3A11%3AQObject%3A%3AstaticMetaObject%3Acall%3AQMetaObject%3A%3Aactivate%3AQMetaObject%3A%3Aactivate%3AQQuickWindow%3A%3AframeSwapped
[10:44] <tsdgeos> don't think so
[10:45] <greyback> ok
[10:48] <tsdgeos> and now i can't make it crash :S
[10:48] <tsdgeos> i should have kept the backtrace when i got it
[10:49] <tsdgeos> it is still crashing
[10:50] <tsdgeos> but the backtrace is different
[10:50] <tsdgeos> log says
[10:50] <tsdgeos> *** Error in `unity8': free(): invalid size: 0x00007fd674119950 ***
[10:52] <tsdgeos> let's try valgrind maybe
[10:59] <pstolowski> mzanetti_, ping
[11:00] <mzanetti_> pstolowski, hey ho
=== mzanetti_ is now known as mzanetti
[11:00] <pstolowski> mzanetti_, hey, i've just found out you're going to land a bunch of changes with silo 60, namely the diff updates of unity-scopes-shell
[11:00] <mzanetti> hmm, you just found out? :)
[11:00] <mzanetti> pstolowski, didn't you ping me over those branches last week?
[11:01] <pstolowski> mzanetti, no i don't think so
[11:01] <mzanetti> hmm... I could swear you did :) anyhow, hope it's not an issue
[11:01] <pstolowski> mzanetti, well
[11:01] <mzanetti> O_o
[11:01] <pstolowski> mzanetti, it's great to land it (i had a silo myself with it), but it needs to wait for the release of all agregator scopes with ota8
[11:02] <mzanetti> nooo
[11:02] <mzanetti> darn
[11:02] <mzanetti> this silo has been waiting for QA since friday already
[11:02] <pstolowski> mzanetti, that's why i held back my silo some time ago
[11:02] <mzanetti> pstolowski, what is the issue? in my testing everything seemed to work
[11:02] <pstolowski> mzanetti, i know, and i see it's under testing now
[11:03] <pstolowski> mzanetti, with slow network the experience will be suboptimal in aggregator scopes
[11:03] <mzanetti> pstolowski, but wait, OTA-8 is being released this very moment
[11:03] <mzanetti> would that unblock it?
[11:03] <pstolowski> mzanetti, yes, but i was told that aggregator scopes will be upgraded via store
[11:04] <mzanetti> pstolowski, any ETA on that?
[11:04] <mzanetti> I mean, it's rc-proposed, a slightly suboptimal experience for a day would be ok I guess if the fixes are already in the queue
[11:04] <mzanetti> I'd hate to recompile it and wait for another week to get QA on it
[11:04] <pstolowski> mzanetti, probably
[11:04] <pstolowski> mzanetti, yes that' probably too much
[11:05] <pstolowski> mzanetti, forwarded you the email, that's all i know
[11:05] <mzanetti> ok, thanks.
[11:06] <mzanetti> pstolowski, so, sorry for the miscommunication, last week when I created the silo I had one that depended on a unity-scopes branch. I asked if I can land it and you gave me two more that should go together. But I might have misunderstood...
[11:08] <pstolowski> mzanetti, yeah, looks like a misunderstanding ;)
[11:08] <tsdgeos> greyback: dednick: i can't really reproduce the crash other than that line on the unity8.log
[11:09] <greyback> tsdgeos: ok, thanks for trying anyway
[11:09] <mzanetti> pstolowski, reading through that mail I get the impression that rc-proposed is fine... and that's where the silo is going. I guess if QA doesn't block on the suboptimal experience we're good. Just need to make sure all those scopes are released by OTA-9, which is january
[11:12] <tsdgeos> greyback: dednick: do you guys have a bug for that occlusion rendering thing i can duplicate the one for the dash not painting to it?
[11:12] <tsdgeos> 1515356 ?
[11:12] <pstolowski> mzanetti, i know where the misunderstanding came from
[11:13] <pstolowski> mzanetti, https://code.launchpad.net/~aacid/unity8/dash_reset_instead_of_fatal/+merge/274363
[11:13] <tsdgeos> it's weird because that one says "until touched"
[11:13] <pstolowski> mzanetti, it lists my branch as required :)
[11:13] <tsdgeos> maybe 1514556
[11:13] <mzanetti> yep, and I remeber I asked if I can/should land those
[11:13] <dednick> tsdgeos: https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1515356
[11:13] <ubot5> Ubuntu bug 1515356 in qtmir (Ubuntu) "After a boot the dash doesn't display until touched" [High,In progress]
[11:14] <dednick> or yeah, either on...
[11:14] <tsdgeos> dednick: but in my case was even if i touched it? (well clicked on it, there's no touch on my laptop)
[11:14] <dednick> *one
[11:14] <tsdgeos> i'll put it onto https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1514556
[11:14] <ubot5> Ubuntu bug 1514556 in qtmir (Ubuntu) "With occlusion detection, apps stop responding when switching from another app." [Critical,Confirmed]
[11:15] <dednick> or there is https://bugs.launchpad.net/qtmir/+bug/1517139
[11:15] <ubot5> Ubuntu bug 1517139 in QtMir "unity8 crash on running hellogl2 in qtbase5-examples" [Critical,In progress]
[11:15] <greyback> tsdgeos: that occlusion detection stuff was reverted
[11:15] <dednick> might be related.
[11:15] <pstolowski> mzanetti, the scopes will be released very soon, so ota9 will be fine for sure
[11:15] <tsdgeos> greyback: yes, and as i said, not landed into xenial
[11:15] <tsdgeos> greyback: so I still see it on the desktop unless i compile my own qtmir
[11:16] <greyback> tsdgeos: if any interaction with the dash (mouse or touch) makes the dash contents appear, then it's this occlusion bug
[11:16] <greyback> i.e. any single event to make it redraw
[11:16] <tsdgeos> greyback: no it does not make the contents appear
[11:16] <tsdgeos> greyback: but i have confirmed the new qtmir does not reproduce the bug anymore
[11:16] <greyback> tsdgeos: ok
[11:17] <tsdgeos> i.e. i can't reproduce the bug anymore when using 0.4.6+16.04.20151113-0ubuntu1 of qtmir while the bug is there with 0.4.6+16.04.20151102-0ubuntu1
[11:18] <tsdgeos> of course if someone else ahs time to double verify it's always a nice thing :)
[11:20] <tsdgeos> greyback: i think it would be good if we could get the lastest qtmir in xenial, no idea why it's old
[11:20] <greyback> tsdgeos: the issue I was seeing was different: I could interact with dash, but all I ever got was the + thing at the bottom of the screen. If I expanded that + thing, I could select a scope, and then it worked
[11:21] <greyback> tsdgeos: it's blocked in release due to a library problem
[11:21] <tsdgeos> oh
[11:59] <mzanetti> tsdgeos, hey, the bug about the dash not showing up in desktop
[11:59] <mzanetti> tsdgeos, that already happened before we had the occlusion branches landed
[11:59] <tsdgeos> mzanetti: define "not showing up"
[12:00] <mzanetti> tsdgeos, window is there, background image loaded, you can see the bottom edge hint, no content tho
[12:00] <tsdgeos> mzanetti: that goes away with the latest qtmir for me
[12:00] <mzanetti> hmm, ok
[12:00] <tsdgeos> i don't know if it happened before or not
[12:01] <tsdgeos> but i can't reproduce it anymore with my self compiled qtmir to the latest version
[12:01] <tsdgeos> mzanetti: if you can still reproduce it would be nice to know
[12:02] <mzanetti> tsdgeos, ack, will watch out for it and let you know
[12:04] <tsdgeos> dandrader: https://code.launchpad.net/~aacid/unity8/fix_cursor_noise/+merge/277982
[12:07] <dandrader> tsdgeos, wonder why you were getting the builtin cursor though
[12:07] <dandrader> tsdgeos, you should be getting the xcursors from DMZ white theme
[12:08] <dandrader> tsdgeos, (the ones Unity 7 use)
[12:08] <tsdgeos> dandrader: is that dependent on the user config?
[12:08] <dandrader> tsdgeos, no
[12:08] <dandrader> tsdgeos, what do you have in /usr/share/icons/default ?
[12:09] <tsdgeos> dandrader: http://paste.ubuntu.com/13344574/
[12:10] <dandrader> tsdgeos, ahh... so you're a KDE user?
[12:10] <dandrader> tsdgeos, so index.theme is a symlink to KDE's breeze theme
[12:10] <dandrader> tsdgeos, instead of DMZ-White
[12:10] <tsdgeos> dandrader: what does "being a KDE user" mean :D
[12:11] <tsdgeos> dandrader: still i should get that theme and not the builtin cursor, no?
[12:11] <dandrader> tsdgeos, yes and no
[12:11] <dandrader> tsdgeos, xcursor naming is a big hot mess
[12:12] <dandrader> tsdgeos, as is there's not much of a standardization to it
[12:12] <dandrader> tsdgeos, so code has to come up with a whole bunch of fallback names and what not for every single cursor shape
[12:12] <dandrader> tsdgeos, as every theme like to give different names for the cursor shapes
[12:13] <tsdgeos> i guess one can't configure the cursor theme in unity7, right?
[12:13] <tsdgeos> that'd be too much flexibility
[12:13] <dandrader> tsdgeos, I've a branch that improves the fallback list of xcursor names quite a bit
[12:13] <tsdgeos> since you can't configure it, why not hardcode it to the one we want to use?
[12:13] <Trevinho> tsdgeos: it can be changed using external tools (such as gnome/unity tweak)
[12:14] <dandrader> tsdgeos, ltinkl is about to report a unity8 bug about specifically this issue. that when he switches to breeze cursor theme unity8 doesn't pick up its cursors for some reason
[12:14] <dandrader> tsdgeos, because even with this naming mess, we still should get most if not all of them
[12:14] <tsdgeos> ok
[12:23] <ltinkl> tsdgeos: yup, just writing the BR (found out yesterday too)
[12:30] <ltinkl> tsdgeos, dandrader: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1517878
[12:30] <ubot5> Ubuntu bug 1517878 in unity8 (Ubuntu) "Non-default cursor themes fail to load" [Medium,New]
[12:32] <dandrader> ltinkl, let someone else set the importance. reset it to Undecided
[12:33] <dandrader> ltinkl, usually the team lead or manager sets it
[12:43] <ltinkl> dandrader, greyback_ sorry :)
[12:43] <dandrader> greyback_, what's the silo number?
[12:44] <greyback_> dandrader: 48
[12:44] <greyback_> https://requests.ci-train.ubuntu.com/#/ticket/661
[12:45] <dandrader> greyback_, fix will require a unity-api and  a unity8 branch
[12:45] <dandrader> greyback_, pretty simple ones, though
[12:46] <greyback_> dandrader: then we'll land separately
[12:46] <dandrader> greyback_, ok, pull it back from the silo then
[12:46] <greyback_> yep
[12:46] <greyback_> dandrader: for my info, what needs to be fixed?
[12:48] <dandrader> greyback_, mir mouse events are being sent from qtmir to the qml mouse pointer, so it decides what to do and synthesizes the Qt event, feeding the window where it lives with that event
[12:48] <dandrader> greyback_, wheel event should follow the same path
[12:48] <greyback_> ok
[12:49] <dandrader> cutting corners didn't work out so well
=== davidcalle_ is now known as davidcalle
=== dandrader is now known as dandrader|afk
=== alan_g is now known as alan_g|lunch
=== dandrader|afk is now known as dandrader
=== alan_g|lunch is now known as alan_g
=== nudtrobert1 is now known as nudtrobert
[14:43] <tsdgeos> mzanetti: any idea what's up with the ci links not working?
[14:44] <mzanetti> tsdgeos, jenkins completely down atm
[14:44] <tsdgeos> is it? i read something about being down for like 30 min only
[14:44] <tsdgeos> must have misread
[14:44] <mzanetti> hmm. let me check
[14:45] <tsdgeos> https://code.launchpad.net/~mzanetti/unity8/move-screenshots-to-tests/+merge/276798 just "finished" 34 min ago
[14:45] <tsdgeos> and all the links but the qmluitests ones work
[14:45] <tsdgeos> which is a bit fishy
[14:46] <mzanetti> tsdgeos, for me all the links give a 404
[14:46] <tsdgeos> mzanetti: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-vivid-touch/5259/ works
[14:46] <mzanetti> tsdgeos, this happens for me since 2 days now. I've pinged cihelp already but no reply so far
[14:46] <tsdgeos> it's the first on https://code.launchpad.net/~mzanetti/unity8/move-screenshots-to-tests/+merge/276798/comments/703590
[14:46] <tsdgeos> :/
[14:46] <tsdgeos> broken CI is not very useful
[14:47] <mzanetti> hehe
=== dpm is now known as dpm-afk
=== dandrader is now known as dandrader|afk
[15:41] <mterry> mzanetti, sudo gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User32011 --method org.freedesktop.DBus.Properties.Get com.canonical.unity.AccountsService DemoEdgesCompleted
[15:41] <mzanetti> mterry, (<['', 'left', 'bottom', 'top', 'right']>,)
[15:41] <mzanetti> is the '' intentional?
[15:42] <mterry> mzanetti, hrm... no?  depends, when setting it with tools, you need to specify an empty string, since none of the tools can handle an empty array!
[15:42] <mterry> mzanetti, but I doubt you did that
[15:42] <mterry> mzanetti, so that's A.  I'll look at that
[15:43] <mterry> mzanetti, but B, it looks like the tutorial THINKS you opened the right edge at some point
[15:43] <mzanetti> yeah... will try again
[15:44] <mzanetti> mterry, is it enough to set the other key to false?
[15:44] <mzanetti> or do I manually need to clear this one too?
[15:44] <mzanetti> qdbus --system com.canonical.PropertyService /com/canonical/PropertyService com.canonical.PropertyService.GetProperty edge
[15:44] <mzanetti> that one ^
[15:44] <mzanetti> erm... /me tries again
[15:44] <mterry> mzanetti, uh no, not if you use my instructions
[15:45] <mterry> mzanetti, that is a meta property that will clear the other properties, if you use it
[15:45] <tsdgeos> mzanetti: https://code.launchpad.net/~mzanetti/unity8/move-screenshots-to-tests/+merge/276798 fails
[15:45] <mzanetti> mterry, well, I've read through through the phablet-tools merge and saw that one being reset
[15:45] <mterry> mzanetti, yeah.  phablet-tools calls that, which then sets the two AS fields
[15:45] <mzanetti> tsdgeos, ack, thanks, will check it
[15:46] <mterry> mzanetti, but my instructions don't rely on you having my phablet-tools branch, so they include instructions for resetting everything manually even if you have old tools
[15:46] <mterry> mzanetti, but if you do use those tools, you'll get an empty string in your list.  So maybe that's where it's from -- I'm guessing you cleared your settings before testing
[15:46] <mzanetti> mterry, but the new phablet-tools branch doesn't do anything magic, it just drops the check, doesn't it?
[15:46] <mterry> mzanetti, i.e. my instructions leave you with an empty string
[15:46] <mzanetti> mterry, I used the old phablet-tools (before I saw your branch) and it worked to enable it
[15:47] <mzanetti> at least for 3 eges :D
[15:47] <mterry> mzanetti, but there's another patch, not in VCS but in that silo (patch for dbus-property-service) that adds the extra clear for DemoEdgesCompleted
[15:47] <mterry> mzanetti, but if you also used my instruction for manually clearing DemoEdgesCompleted, you'll end up with an empty string
[15:47] <mzanetti> oh, I see
[15:48] <mzanetti> ok, so I did:
[15:48] <mterry> mzanetti, between the three tools, dbus-send, gdbus, and qdbus, none of them worked perfectly for setting an empty array
[15:48] <mzanetti> qdbus --system com.canonical.PropertyService /com/canonical/PropertyService com.canonical.PropertyService.SetProperty edge true
[15:48] <mterry> mzanetti, some couldn't do arrays, and those that could, couldn't do an empty one
[15:48] <mterry> mzanetti, did you install silo 33?
[15:48] <mzanetti> yes
[15:48] <mterry> mzanetti, then the empty string is expected
[15:48] <mzanetti> ack
[15:49] <mterry> mzanetti, dbus-property-service uses gdbus with a empty-string-array
[15:49] <mzanetti> mterry, will that patch land too? or is that just for the silo?
[15:49] <mterry> mzanetti, because I couldn't find a better way to do it with shell!
[15:49] <mterry> mzanetti, that will land too
[15:49] <mzanetti> ack
[15:49]  * mzanetti reboots and hopes to see a right edge too :)
[15:49] <mterry> mzanetti, so normal users won't see the empty string.  But anyone that uses phablet-tools will
[15:50] <mzanetti> mterry, ack, wfm
[15:53] <mzanetti> mterry, ok. got the right edge this time... still a bit puzzled why I didn't see it at first
[15:54] <mterry> mzanetti, I hope it was just that you used the right edge and forgot...  :-/
[15:55] <mterry> mzanetti, it's easy to accidentally do
[15:55] <mterry> mzanetti, especially when you want to launch more apps -- I often go to the dash
[15:55] <mterry> mzanetti, and them hit my forehead  :)
[15:55] <mzanetti> probably... yes
[16:10] <tsdgeos> cimi: maybe you can review https://code.launchpad.net/~aacid/unity8/listviewforreviews/+merge/277428 ?
[16:10] <tsdgeos> cimi: and https://code.launchpad.net/~aacid/unity8/unfavorite_scope_test/+merge/277157
[16:10] <cimi> tsdgeos, ok
[16:12] <tsdgeos> cimi: also please remind me what's the satatus of https://code.launchpad.net/~cimi/unity8/new-shadows-1.3/+merge/271611
[16:12] <tsdgeos> is it good to go? or are we waiting on something?
[16:13] <cimi> tsdgeos, just review... design is approved
[16:13] <tsdgeos> ok
[16:17] <mterry> mzanetti, greyback: is it expected that u8 seems to restart when plugged into a monitor?  it does the dot-progress thing, so it looks intentional, since it's not a reboot.  I just didn't expect that
[16:17] <greyback> mterry: known issue
[16:17] <mterry> greyback, ok
[16:18] <greyback> https://bugs.launchpad.net/canonical-pocket-desktop/+bug/1513909
[16:18] <ubot5> Ubuntu bug 1513909 in mir (Ubuntu) "unity8 crash on unplug of monitor" [Critical,In progress]
[16:20] <mterry> oh duh, the dot-progress is what I see when it crashes  :)
[16:20] <mterry> I forgot we had dots on that screen, and I helped make that screen
[16:21] <tsdgeos> mzanetti: now that ota8 is out are we planning a landing? have like a zillion approved branches
[16:22] <mterry> mzanetti, if you're in a reviewing-mterry's-branches mood, https://code.launchpad.net/~mterry/unity8/warn-on-xapp/+merge/277915 might be up your alley, since it's basically a copy of your dialog branch
[16:28] <mzanetti> tsdgeos, silo 60 has just been approved by QA
[16:28] <mzanetti> tsdgeos, once it's merged I'll put together the next one
[16:28] <mzanetti> mterry, heh, ack
[16:29] <tsdgeos> mzanetti: cool
[16:29] <tsdgeos> cimi: can you merge unity8 into your branch? it merges fine but that way it'll also compile just after downloading :D
[16:30]  * mterry has a mental image of mzanetti shoveling coal into a furnace to keep the silos pumping
[16:30] <mzanetti> :D
[16:30] <tsdgeos> oh so we're landing the diff updates for scopes
[16:30] <tsdgeos> very cool
[16:31] <mzanetti> we are
[16:32] <mzanetti> although pawel seemed to be happy that I'm landing it. he said it'll my fault if it blows up, which gives me a slightly uncomfy feeling about it
[16:32] <mzanetti> it was working great in my testing tho, and apparently QA didn't find issues either
=== dandrader|afk is now known as dandrader
[16:55] <mzanetti> mterry, weird... the diff seems to show the prereq's prereq's changes, doesn't it?
[16:55] <mzanetti> https://code.launchpad.net/~mterry/unity8/warn-on-xapp/+merge/277915
[16:55] <mterry> mzanetti, no, that's all my changes
[16:56] <mzanetti> the isTouchApp too?
[16:56] <mterry> mzanetti, yeah -- that's how we know whether to show the dialog
[16:56] <mterry> mzanetti, isTouchApp was added for ApplicationInfoInterface
[16:56] <mzanetti> mterry, yes, but didn't you add thos to the no-touch-no-lifecycle branch?
[16:56] <mterry> mzanetti, but this is for LauncherInterface (i.e. before app is launched)
[16:56] <mterry> LauncherItemInterface rather
[16:56] <mzanetti> ohhh. right
[16:57] <mterry> mzanetti, I have an associated unity-api branch too
[16:57] <mterry> linked in description
[16:57] <mzanetti> mterry, I see... how would that apply to dash launches then?
[16:58] <mterry> mzanetti, good question, this branch doesn't address that right now, since dash never shows legacy apps (yet), right?
[16:58] <mterry> mzanetti, how does app scope launch apps now?  by itself?  or does it ask unity8 to launch them for it?
[16:58] <mzanetti> yeah, doesn't atm...
[16:58] <mzanetti> mterry, Qt.openUrlExternally()
[16:58] <mterry> mzanetti, that's what I feared
[16:58] <mterry> mzanetti, so that means u8 isn't involved at all, and it would be difficult to show this same dialog for them
[16:59] <mterry> mzanetti, when we add support for showing legacy apps in dash, maybe we want to add a call to dashcommunicator?
[16:59] <mterry> mzanetti, but ultimately, any app can cause another app to open
[16:59] <mterry> via openUrlExternally
[16:59] <mterry> not just a dash problem
[16:59] <mzanetti> I'm wondering if we shouldn't rather add something to allow as rejecting an app with ApplicationManager
[17:00] <mzanetti> hmm...
[17:00] <mzanetti> mterry, will talk to gerry when he's on tomorrow
[17:01] <mzanetti> mterry, however, your branch would still apply if we need to show the icons somehow differently
[17:01] <mterry> mzanetti, so putting logic in qtmir, u8 sees denial code from AppManager, and shows dialog?  could work.  But would have to be careful to be able to open the app up again when docked (so save arguments and such)
[17:01] <mterry> mzanetti, yeah LauncherItemInterface changes and all that still make sense
[17:01] <mterry> mzanetti, as does the dialog.  Just the connection of the two might need adjusting
[17:02] <mzanetti> mterry, I'm thinking rather of qtmir emitting something like "iWantToStartApp(appId)" and we accept or reject it
[17:02] <mzanetti> but need to be careful to not slow down app startup time
[17:02] <mzanetti> needs a word with gerry definitely
[17:02] <mterry> mzanetti, yeah
[17:02] <mterry> mzanetti, right, of course qtmir couldn't accept/deny on its own
[17:03] <mterry> mzanetti, also... does qtmir even get involved before the exe is run?
[17:03] <mterry> mzanetti, we probably want to prevent the exe from being run at all if possible
[17:03] <mterry> to avoid any side effects
[17:03] <mzanetti> yep, u-a-l already asks qtmir for permission before launching the binary
[17:04] <mterry> mzanetti, oh neat
[17:05] <mzanetti> we even have means of knowing that... the application item will be added to the model at that point already
[17:05] <mterry> mzanetti, I'm going to change the tutorial branch -- keep track of a separate bottom field for each app -- so "[top, bottom-dialer-app, bottom-messaging-app]" etc
[17:05] <mterry> mzanetti, oh ah.  So the LauncherItemInterface change will be purely potential-future-proofing
[17:05] <mzanetti> yep. but I'm quite confident we'll need it
[17:06] <mterry> mzanetti, would be nice to get alexm to weigh in
[17:06] <mzanetti> yes. putting a design chat regarding this on my todo list too
[17:06] <mterry> mzanetti, I also just made up the text for the dialog: "Dock your device to open this app"
[17:06] <mzanetti> mhm
[17:07] <mzanetti> ok, seems not so straigth forward as a review either :D
[17:07] <mterry> Ah well
[17:07] <mzanetti> what's the reason for changing the list (re tutorial)
[17:08] <mterry> mzanetti, design -- they want separate text for each app and they want the coach mark for each app (instead of once for any of them)
[17:08] <mzanetti> ah, /me likes
[17:08] <mterry> mzanetti, they had been happy with just the dialer-app, but I had to open my big mouth  :)
[17:08] <mzanetti> haha
[17:38] <dandrader> mzanetti, https://code.launchpad.net/~dandrader/unity8/mouseEdgePush/+merge/276306 is not following the design spec
[17:38] <dandrader> mzanetti, s/not/now
[17:39] <mzanetti> dandrader, awesome!
[17:40] <dandrader> mzanetti, it boiled down to just adjusting the gradient values. width was already right
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== charles_ is now known as charles
[20:39] <mzanetti> mterry, heh, regarding the width/height values. I didn't even realize they were swapped. The question was really why it's those huge integers?
[20:39] <mzanetti> mterry, I guess it's the image file dimensions, but do we really want to set that for the sourceSize?
[20:39] <mterry> mzanetti, maybe I don't grok sourceSize or whatever.  But those are the sizes of the underlying png files
[20:39] <mterry> mzanetti, I thought it was an optimization to specify those
[20:40] <mzanetti> mterry, no, it's the size you want to keep in memory. when it loads the file, it scales it to sourceSize in memory
[20:40] <mzanetti> it is used to prevent constant rescaling of the image
[20:40] <mterry> mzanetti, yeah, so that's good right?  like, screen might become bigger, so you keep the original size around
[20:40] <mzanetti> mterry, I'd set it to the screensize then
[20:41] <mterry> mzanetti, but if they plug in a new monitor
[20:41] <mzanetti> if the image is bigger, we can save some memory
[20:41] <mzanetti> hmm
[20:41] <mterry> mzanetti, actually those images should ideally be rotated if they plug in a landscape monitor...
[20:42] <mterry> mzanetti, but design specified crazy specific orientations for those bg images (each one is technically different)
[20:42] <mzanetti> mterry, right, I'd say plugging a monitor is seldom enough to rescale in that case, but save memory in the normal case
[20:42] <mterry> mzanetti, so I don't have guidance on the landscape issue
[20:42] <mterry> mzanetti, yeah.  OK so I drop the lines?
[20:42] <mzanetti> hmm
[20:42] <mzanetti> well, they will be dropped from memory anyways after the wizard
[20:43] <mzanetti> on a second thought it might even be better to keep the full size then
[20:43] <mzanetti> not sure. you have a point there
[20:44] <mzanetti> ok, works for me then. makes sense now :)
[20:46] <mterry> yay for not making any changes  ;)
[20:46] <mzanetti> good I cought the wrong aspect ratio then :D
[20:47] <mzanetti> pure luck