[07:43] <veebers> mzanetti: ping
[07:45] <mzanetti> veebers: hi
[07:46] <veebers> mzanetti: hey, last week I think you mentioned that you wanted to sync tonight/nowish?
[07:46] <mzanetti> veebers: yeah... if that's ok for you
[07:46] <mzanetti> veebers: https://plus.google.com/hangouts/_/88c14f801dd860966b7acae71497df586a31360e
[07:47] <veebers> mzanetti: sweet, one moment moving to office
[08:34] <larsu> is autolanding in unity8 failing for everyone or just my branch? https://code.launchpad.net/~larsu/unity8/lp1219057/+merge/184622
[08:38] <dednick> larsu: been happening for me as well. it's pretty flaky.
[08:43] <larsu> dednick: ah, good to know, thanks
[08:43] <mzanetti> larsu: hmm... there seems to be some breakage
[08:43] <mzanetti> larsu: as the test results for your job contains all sorts of results of the apps
[08:44] <mzanetti> veebers: fyi: https://code.launchpad.net/~larsu/unity8/lp1219057/+merge/184622
[08:45] <mzanetti> veebers: I'll ask omer/fginter to check it when they show up as it's out of working hours. but just in case you have seen this before and know whats going on already, let us know
[08:56] <nic-doffay> mzanetti, is the right edge you mentioned rightEdgeDraggingArea in Stage.qml?
[08:56] <nic-doffay> Because I'm setting enabled and it's not making a difference.
[08:59] <nic-doffay> mzanetti, if you aren't sure do you have an idea who would know a bit more? Would save me a lot of time.
[08:59] <mzanetti> nic-doffay: I'm quite sure that's the one
[08:59] <mzanetti> nic-doffay: dandrader created that stuff
[09:00] <dandrader> o/
[09:00] <dandrader> nic-doffay, what do you want to do?
[09:01] <mzanetti> dandrader: he needs to disable the right edge drag when an overlay is open
[09:01] <mzanetti> dandrader: pretty much like the HUD, or the indicators do it
[09:01] <nic-doffay> dandrader, I'm busy setting enabled (line 443) in Stage.qml.
[09:01] <nic-doffay> To disabled the right edge behaviour.
[09:01] <nic-doffay> Doesn't seem to be affecting it.
[09:02] <nic-doffay> It's printing false but the drag behaviour persists.
[09:03]  * dandrader tries it out
[09:04] <dandrader> (but EdgeDragArea really shouldn't do anything if enabled:false || visible::false)
[09:04] <mzanetti> hmm... looking at that code I don't see anything hud or indicators related in there
[09:04] <mzanetti> maybe they do it somewhere else...
[09:04] <dandrader> as per DirectionalDragArea.cpp:461
[09:05] <mzanetti> nic-doffay: have you tried adding your stuff in Shell.qml at line 501 ?
[09:05] <mzanetti> nic-doffay: that kinda looks like how the others disable that
[09:07] <dandrader> nic-doffay, disabling that DragArea makes you unable to switch between apps. but it does not affect the right-edge drag behavior when Dash is on foreground (the behavior that restores the last minimized app to foreground)
[09:07] <dandrader> as this is done by another DragArea
[09:07] <nic-doffay> dandrader, yeah that's what I suspected.
[09:07]  * dandrader searches for it
[09:07] <nic-doffay> mzanetti, no I haven't will try now quickly...
[09:12] <dandrader> nic-doffay, it's the DragHandle in Shell.qml:395
[09:14] <nic-doffay> dandrader, spot on, ta!
[09:17] <dandrader> mzanetti, I'm still getting failures in notification autopilot tests :( https://code.launchpad.net/~dandrader/unity8/MouseTouchAdaptor_MultiWindow/+merge/185820/comments/423184
[09:17] <nic-doffay> dandrader, there still seems to be a component interfering. I've disabled both the rightEdgeDragging area in Stage.qml and the aforementioned one in Shell, however when I click that area the filters are dismissed.
[09:17] <nic-doffay> Any idea what might be affecting this now?
[09:18] <mzanetti> dandrader: hm... this is weird
[09:18] <mzanetti> MacSlow: any idea? https://code.launchpad.net/~dandrader/unity8/MouseTouchAdaptor_MultiWindow/+merge/185820/comments/423184
[09:19] <dandrader> nic-doffay, what "filters"?
[09:19] <dandrader> mzanetti, btw, that MP still needs your review :)
[09:20] <mzanetti> dandrader: yeah... I'm using it right now in my branch... functionality looks ok. still gotta read through the code
[09:20] <nic-doffay> dandrader, that's something I'm working on. It's part of the PageHeader.
[09:21] <nic-doffay> So it appears the PageHeader is dismissed.
[09:21] <nic-doffay> When clicking that right edge once both of the respective components "enabled" properties are set to false.
[09:24] <dandrader> nic-doffay, hmm, hard to say
[09:41] <nic-doffay> dandrader, strange an inverseMouseArea was interfering.
[09:41] <nic-doffay> once those were disabled.
[09:47] <nic-doffay> mzanetti, that's the last one ticked off the list then. Feel free to take another spin. Going to try get someone from #sdk to land the other branch in the mean time.
[09:51] <nic-doffay> MacSlow, won't be able to land that branch atm.
[09:51] <nic-doffay> Autopilot issues.
[10:07] <MacSlow> mzanetti, looking
[10:09] <MacSlow> nic-doffay, ok
[11:19] <mzanetti> dandrader: very small nitpick comment on your merge... do you want to fix it or shall I approve as is? https://code.launchpad.net/~dandrader/unity8/MouseTouchAdaptor_MultiWindow/+merge/185820
[11:21] <dandrader> mzanetti, replied
[11:22] <mzanetti> dandrader: approved
[11:23] <dandrader> mzanetti, can you top-approve as well (and hope that the autolander has no issues with the autopilot tests)?
[11:23] <mzanetti> sure
[11:23] <dandrader> mzanetti, thanks!
[11:25] <mzanetti> nic-doffay: seriuosly dude... if you tell me that you fixed all the stuff I reall do expect you to have...
[12:50] <paulliu> mhr3: https://code.launchpad.net/~paulliu/unity8/movie-preview/+merge/181856
[12:50] <paulliu> mhr3: please help to review. Thanks.
[13:01] <mhr3> paulliu, there are still some traces of qtmultimedia
[13:01] <mhr3> i suppose you want to get rid of those? :)
[13:04] <mhr3> paulliu, also, `apt-get install unity-scope-video-remote` after restart you should see some online videos, try previewing them and see if things work
[13:06] <paulliu> mhr3: ok.
[13:07] <paulliu> mhr3: Yeah.. Let me remove those qtmultimedia stuff and try the new scope.
[13:09] <Saviq> mzanetti, I don't think what Satoris wrote was a Qt or QML API proposition ;)
[13:09] <Saviq> mzanetti, rather a lower level one
[13:09] <mzanetti> Saviq: it starts with ItemName {} :P
[13:10] <mhr3> sil2100, ping?
[13:10] <mhr3> sil2100, you know what i'm going to ask, don't you? :)
[13:11] <sil2100> mhr3: yes! But fear not! We have it planned :)
[13:11] <mzanetti> Saviq: https://code.launchpad.net/~unity-team/unity8/split-surfaces
[13:11] <sil2100> mhr3: we will try landing it... TODAY!
[13:11] <sil2100> Later today
[13:11] <mzanetti> Saviq: the launcher is so to say "done"
[13:11] <Saviq> mzanetti, cool!
[13:11] <mhr3> sil2100, awesomeness :)
[13:11] <mzanetti> Saviq: I won't do all the other overlays right now, or?
[13:12] <mhr3> ssweeny, ^^^
[13:12] <mzanetti> Saviq: better way for a) if that'll work on mir and b) if we're actually using it
[13:12] <Saviq> mzanetti, answer to b) is "yes"
[13:15] <ssweeny> mhr3, \0/
[13:27] <bregma> latest Unity7 daily just failed because of the new xpathselect-dev package, with new features added and old features removed...  WEEKS after feature freeze
[13:28] <bregma> why both having a feature fereze?
[13:32] <mzanetti> Saviq: you joining the standup?
[13:43] <greyback> dednick: I couldn't follow the first thing you said. Could you add it yourself?
[13:43] <greyback> dednick: or write it here and I'll add it
[13:44] <dednick> greyback: yeah, i'll add it
[13:44] <greyback> dednick: appreciated, thanks
[13:50] <nic-doffay> mzanetti, regarding your comment, the best way to sort that out would probably be to disable dash clicks.
[13:50] <nic-doffay> Do you know if this is done elsewhere?
[13:51] <mzanetti> nic-doffay: I'd say you just anchors.fill the overlay with a MouseArea doing nothing
[13:52] <mzanetti> nic-doffay: also, make sure that you have read all the other comments above... I'm not happy with the way you do the launcherShown thingie
[13:52] <nic-doffay> mzanetti, I thought of that but it seems hacky
[13:52] <mzanetti> nic-doffay: nah... having a MouseArea to "eat" clicks is a quite common thing actually
[13:57] <pete-woods> MacSlow: hi - do you have a plan for when you're aiming to finish the extended snap decisions work? are we talking past the end of this week or more?
[13:58] <MacSlow> pete-woods, I'll be splitting up my branches... into what's working already and the remaining parts that are still in wip (wifi-selection)...
[13:58] <pete-woods> sounds like a good plan!
[13:58] <MacSlow> pete-woods, so I'll put pin-entry, password and user-authentication into a MR this week...
[13:58] <pete-woods> (as you can probably guess, I have pressure to get the revised network secret agent working)
[13:58] <nic-doffay> mzanetti, my reason for doing the launcherShown bool was to close the search popover too.
[13:59] <nic-doffay> Since I figured there's no point having that open with the launcher...
[13:59] <MacSlow> pete-woods, there's no security (white-list protection) yet
[13:59] <pete-woods> MacSlow: awesome news :)
[13:59] <mzanetti> nic-doffay: its good that you close that too. still read the comment on how to do it in a better way
[13:59] <MacSlow> pete-woods, I've pressure from all-sides... so welcome to the club :)
[14:00] <pete-woods> MacSlow: well thanks for the info, and good luck with this stuff :)
[14:01] <MacSlow> pete-woods, didn't I CC you too in my eMail earlier today...
[14:01]  * MacSlow looks...
[14:02] <pete-woods> I have an e-mail from yesterday, but it didn't have estimates in, unless I'm blind that is
[14:02] <nic-doffay> mzanetti, yeah but that's got nothing to do with the alias you mentioned.
[14:02] <nic-doffay> It's a popover
[14:02] <nic-doffay> Which is handled in PageHeader.qml
[14:02] <mzanetti> nic-doffay: so?
[14:02] <nic-doffay> mzanetti, so it shouldn't close when the filters close.
[14:02] <nic-doffay> It should be handled separately.
[14:03] <mzanetti> nic-doffay: ah... hmm... I see.. but wait... if its a popover you can't open the launcher while its open...
[14:04] <nic-doffay> mzanetti, why not?
[14:05] <mzanetti> because popovers have an inversemousearea round them that closes the popover if you tap somewhere outside of it
[14:06] <nic-doffay> mzanetti, so disable the launcher instead?
[14:06] <mzanetti> nic-doffay: no... just ignore the popup
[14:06] <mzanetti> nic-doffay: that's already handled correctly
[14:07] <nic-doffay> mzanetti, so you mean don't close the popup then?
[14:07] <mzanetti> nic-doffay: the popover will close itself if you try to open the launcher
[14:09] <nic-doffay> mzanetti, right cool
[14:13] <mzanetti> Cimi: can you do a review? https://code.launchpad.net/~mzanetti/unity8/launcher-fix-removal-of-running-app/+merge/185878
[14:14] <mzanetti> greyback: hey, I think we introduced another issue with the new app manager
[14:14] <greyback> mzanetti: a good issue? /me hopes
[14:15] <mzanetti> greyback: launching an app from the commandline seems only possible with --destkop_file_hint pointing to a desktop file located in /usr/share/applications/
[14:15] <mzanetti> greyback: which kinda breaks run_on_device scripts for apps
[14:15] <nic-doffay> mzanetti, pushed to the branch.
[14:16] <nic-doffay> However something is interfering with the filters being dismissed.
[14:16] <nic-doffay> No idea what.
[14:16] <nic-doffay> Check line 455 in the diff.
[14:16] <nic-doffay> This works but the filters remain on screen.
[14:17] <greyback> mzanetti: ok, that's quite possible, will look now
[14:17] <nic-doffay> mzanetti, wait I see, althought I'm unsure how to get around it.
[14:17] <greyback> mzanetti: you got this on mir or SF? (but I'll check both to be sure)
[14:18] <mzanetti> greyback: yeah... still using SF here... Mir freezes the device on starting apps here
[14:18] <kgunn> MacSlow: ping
[14:19] <greyback> mzanetti: I'd need to look into that too! Running app via command line on Mir causes it to freeze?
[14:19] <mzanetti> greyback: no... running an app from the dash
[14:19] <MacSlow> kgunn, pong
[14:20] <mzanetti> greyback: changes are > 80% here that it lock up when starting an app
[14:20] <mzanetti> greyback: chances...
[14:20] <greyback> mzanetti: well obviously that's not right. I don't have such a high fail rate here tho. Nexus4?
[14:21] <mzanetti> greyback: galaxy nexus
[14:21] <greyback> mzanetti: okay. I'll flash today's image to check.
[14:21] <mzanetti> greyback: I assumed you know about that and are working hard to get it fixed already. so I didn't complain
[14:21] <kgunn> MacSlow: hey...so, i have a note in our delivery sheet
[14:21] <mzanetti> greyback: I noticed that with yesterdays image
[14:21] <kgunn> that the designers look at to test
[14:22] <larsu> om26er: re bug #1226312, did you set mute the volume after restarting pulse? I can't find that in the log...
[14:22] <kgunn> and one of the blocks next to notifications says "user can see app install animations"
[14:22] <greyback> mzanetti: the main problem I see is due to focus switching, which is more a Mir issue. Most of time time, launching apps is ok for me.
[14:22] <larsu> om26er: or did you have problems because indicator-sound doesn't reconnect to pulse (known bug btw ;) )
[14:22] <om26er> larsu, yes I did set it to mute
[14:22] <kgunn> MacSlow: i think its just a mistake....or...is there supposed to be a notification when
[14:22] <kgunn> MacSlow: installing the app? (this is on touch)
[14:22] <MacSlow> kgunn, never heard of that before...
[14:22] <om26er> larsu, that could be the case that the sound menu didn't connect to pulse
[14:22] <kgunn> MacSlow: gotta be a mistake...
[14:23] <MacSlow> kgunn, that sounds like a thing happening in the launcher (on an icon there)?
[14:23] <kgunn> MacSlow: i think i'm going to replace it with something like "user sees notification upon recieving a msg"
[14:23] <mzanetti> greyback: could well be that it is related to focus switching
[14:23] <MacSlow> kgunn, I've not seen/heard anything like that in the recent design-doc regarding that
[14:23] <larsu> om26er: right. Can you try again please, but restarting indicator-sound-service after you've restarted pulse? So that the mute is definitly happening?
[14:23] <om26er> larsu, you need to get a Ubuntu phone dude, "ask your manager" :)
[14:23] <mzanetti> greyback: I have the feeling it freezes just when the app should become visible/usable
[14:23] <larsu> om26er: I have one, but no sim in there.
[14:24] <kgunn> MacSlow: yeah... i just need to replace it with a sensible user experience for notifications
[14:24] <mzanetti> greyback: so not directly when clicking on the icon... more like 1.5 secs later
[14:24] <larsu> om26er: do you know if I can fake phone calls somehow?
[14:24] <greyback> mzanetti: indeed. Quite likely. I'm hoping focus fixes in Mir will help. But I need to gather more data to help them.
[14:24] <greyback> mzanetti: just didn't want you to think we had no idea :)
[14:25] <om26er> larsu, on the phones I am not sure, on the desktop that was possible
[14:25] <om26er> larsu, I just tried this: restarted my phone, opened sound menu and changed to mute, made a call from another phone and there was no sound as expected but when I disconnected the call the sound menu automatically changed to unmute infront of my eyes
[14:26] <kgunn> MacSlow: ...yep, someone goofed...i just revision history in google docs (super handy)
[14:26] <MacSlow> kgunn, phew :)
[14:26] <larsu> om26er: right, but that could still be another process chaning the mute status with pulse. The sound menu listens to that
[14:26] <mzanetti> kgunn: fyi. the install app animation in the launcher doesn't match with the specs for the dash. so vesar is clarifying with design if we really need it
[14:27] <larsu> om26er: and I have no clue how it could ever change the volume when a call comes in - the sound menu doesn't know about incoming calls at all
[14:27] <om26er> larsu, do you think any other logs could help ?
[14:27] <om26er> right
[14:28] <larsu> om26er: can you send me the new log (of the process you just described, after you rebooted)
[14:29] <kgunn> mzanetti: thanks for the heads up
[14:29] <kgunn> mzanetti: kinda seems like overkill on phone to do launcher anim's for installs....imho
[14:29] <mzanetti> kgunn: the problem is that apps are not in the launcher while they are being installed
[14:30] <mzanetti> kgunn: and the dash has a button "Pin to launcher" after the installation completes.
[14:30] <mzanetti> kgunn: so even if we would automatically pin each and every app (which I'm strongly against btw) we would cause a clash with the dash spec
[14:31] <kgunn> mzanetti: yeah...makes sense with the "pin 2launcher" button in the dash not to just overpopulate launcher
[14:32] <mzanetti> +1
[14:33] <mzanetti> kgunn: I think that's where we will go. but vesa will clarify with John and Oren
[14:33] <om26er> larsu, http://ubuntuone.com/6zgwQ3FbtEIUeH4G2bPwBG
[14:33] <om26er> wow ubuntuone bug
[14:33] <om26er> its still uploading
[14:34] <om26er> larsu, http://ubuntuone.com/6zgwQ3FbtEIUeH4G2bPwBG
[14:34] <om26er> ah, its the same but now its working
[14:39] <vesar> mzanetti, kgunn: Yes I'm trying to sort out the design part of this. I also agree that adding the installed application to launcher is overkill. But apparently it is something that's seen very important on the desktop side.
[14:40] <mzanetti> vesar: yeah... but on the desktop you don't install 50 fart apps a day
[14:40] <mzanetti> luckily
[14:41] <vesar> mzanetti, :) true. but we have to think about the consistency between form factors.
[14:41] <mzanetti> vesar: yeah... remove that feature from the desktop too :D
[14:42] <larsu> om26er: thanks, I'll have a look
[14:42] <mzanetti> (just kidding)
[14:42] <vesar> mzanetti, kgunn : anyway I'm +1 for getting rid of it. but there are opposing opinions.
[14:42] <om26er> larsu, (Y)
[14:43] <vesar> mzanetti, kgunn : apparently user's haven't found their newly installed apps on desktop. Adding it to launcher automatically and alerting when installation finished has been to solution so far.
[14:43] <vesar> mzanetti, kgunn : anyway I'm on this.
[14:52] <ssweeny> mhr3, hey, i have a scope that works fine on its own but it doesn't show up when made into a subscope of a master. is there anything i need to do other than move the scope file into the right subdir?
[14:55] <om26er> how can I change timezones in touch_ro images ?
[15:00] <mhr3> ssweeny, yes, subscopes need to conform with the master scopes
[15:01] <ssweeny> mhr3, conform how exactly? :)
[15:01] <mhr3> ssweeny, most importantly, their category ids need be a subset of the master's
[15:01] <ssweeny> ah, ok
[15:01] <ssweeny> mhr3, those are the ones laid out in the .scope files?
[15:01] <mhr3> ssweeny, yes, master scopes define them in their .scope files, subscope in the code
[15:07] <ssweeny> mhr3, if no categories are defined in the master does that mean no filtering or would that not show anything?
[15:07] <ssweeny> (i tried removing the categories in case they were mismatched)
[15:07] <ssweeny> (this is my own master scope btw)
[15:08] <mhr3> ssweeny, if you didn't define any categories in the master, there's one default called "global"
[15:09] <mhr3> so you need to define at least that one in the subscope
[15:10] <ssweeny> ok
[15:15] <om26er> bug 1226650
[15:15] <om26er> anyone ?
[15:15] <om26er> popey, confirming bugs today ?
[15:15] <om26er> :)
[15:26] <ssweeny> mhr3, do i need to do anything to make a subscope always show?
[15:29] <mhr3> cwayne1, no, but we were promised that later today, see above (current_time - 2h15m)
[15:29] <mhr3> ssweeny, not sure what you mean
[15:30] <mhr3> ssweeny, still not getting any results?
[15:30] <ssweeny> mhr3, right. but i was wondering what the difference is between something like the "recently used" app scope which always shows up and the other scopes which only show when they have relevant results
[15:31] <ssweeny> mhr3, i have a subscope that basically just always returns the same results. they show when the scope is loaded by itself
[15:33] <mhr3> ssweeny, recent apps only show up on empty searches
[15:33] <ssweeny> ok
[15:33] <mhr3> so no, there isn't anything special
[15:33] <mhr3> ssweeny, do you have the code in a branch somewhere?
[15:34] <ssweeny> mhr3, sure. let me find it
[15:34] <mhr3> ssweeny, are you testing this on the phone itself?
[15:34] <mhr3> or using the desktop?
[15:34] <ssweeny> mhr3, on the phone
[15:34] <mhr3> ok, harder to debug :/
[15:35] <mhr3> ssweeny, but you're not putting the scope to /custom yet, are you?
[15:35] <ssweeny> mhr3, no this is all out of /usr/share/
[15:35] <mhr3> ok
[15:37]  * mhr3 waits for the branch
[15:38] <Saviq> greyback, mzanetti, so I'll take care of the .desktop file issues in unity-mir, ok?
[15:38] <mzanetti> Saviq: fine with me
[15:38] <Saviq> i.e. only supporting ones from /usr/share and not working with --desktop_file_hint from the console
[15:38] <mzanetti> Saviq: yep
[15:57] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/fix-preview-collapsing/+merge/186085
[15:57] <Saviq> mzanetti, cheers
[16:42] <mzanetti> Saviq: updated the branch
[16:50] <sil2100> bregma: ping
[16:50] <sil2100> bschaefer: ping ;)
[16:51] <bregma> sil2100, pong
[16:51] <bschaefer> sil2100, hello!
[16:56] <sil2100> bregma, bschaefer: so... it *seems* we have a FTBFS for unity
[16:56] <bschaefer> sil2100, well thats not good!
[16:57]  * bschaefer grabs truck
[16:57] <bregma> sil2100, yes, a new xpathselect landed and it;s not backward compatible
[16:57] <sil2100> https://launchpadlibrarian.net/150489792/buildlog_ubuntu-saucy-amd64.unity_7.1.0%2B13.10.20130917-0ubuntu1_FAILEDTOBUILD.txt.gz <- seems to fail for all archs
[16:57] <bregma> we're working on a possible workaround by pinning the version in the build-depends, but it takes a while to verify
[16:58] <sil2100> bregma: thanks!
[16:58] <bregma> landing new features in a library after feature freeze should be grounds for burning at the stake, expecially if the old features are removed
[16:59] <sil2100> bregma: uugh, how did that get past the release team? You know if they had a FFE for that?
[17:00] <bregma> I have no idea
[17:00] <sil2100> bregma: since if not, I guess we can force a revert
[17:00] <bregma> it's only in the daily PPA right now, and a dependency of autopilot
[17:01] <sil2100> grrr
[17:01] <thomi> bregma: sil2100: wait, xpathselect1.4 should *not* be in saucy
[17:01] <Saviq> mzanetti, thanks
[17:01] <thomi> we agreed to land that in 'T'.
[17:02] <sil2100> thomi: oh! Let me check then what's up
[17:02] <thomi> sil2100: thanks
[17:03] <thomi> sil2100: all the autopilot 1.4.X packages are targetted at 'T' - that includes the autopiot packages, libautopilot-*, xpathselect, etc.
[17:03] <sil2100> thomi: ok, so clearly we have something broken in daily-release
[17:03] <sil2100> thomi: the config is ok, but maybe someone didn't redeploy and we got this change in...
[17:04] <bschaefer> sooo far trunk is build fine for me on main saucy
[17:04]  * bregma is looking forward to an expedient resolution
[17:04] <thomi> sil2100: OK, can I leave it with you to back that out?
[17:04] <sil2100> thomi: right!
[17:04] <thomi> sil2100: lp:xpathsleect/1.3 is what should be landing in saucy
[17:08] <sil2100> thomi: confirming, the config is correct but stacks weren't redeployed - so the changes weren't actually running ;/
[17:08] <mhr3> Saviq, btw we don't have a generic music result grid
[17:09] <sil2100> Someone didn't redeploy...
[17:09] <mhr3> Saviq, do you have someone to work on that?
[17:10] <Saviq> mhr3, MusicFilterGrid not good?
[17:11] <thomi> sil2100: :(
[17:11] <mhr3> Saviq, oh, cool, so we're just missing a case in GenericScopeView
[17:11] <thomi> sil2100: well, good to know what went wrong anyway
[17:11] <sil2100> thomi: fixing... eh :<
[17:11] <Saviq> mhr3, right
[17:15] <mhr3> Saviq, https://code.launchpad.net/~mhr3/unity8/music-grid-renderer-support/+merge/186109
[17:16] <mhr3> aah
[17:16] <Saviq> mhr3, ubuntu-mono-dark? ;)
[17:16] <mhr3> Saviq, fixed
[17:17] <Saviq> mhr3, happroved
[17:17] <mhr3> tom
[17:17] <mhr3> hanks
[17:50] <bschaefer> mterry, heeey, soo i see one of your very old branches that is fixing a crash we are seeing :)
[17:50] <bschaefer> https://code.launchpad.net/~mterry/nux/null-ibus-config/+merge/129212
[17:51] <mterry> bschaefer, poke a nux maintainer to review it -- I've been waiting on a review
[17:51] <bschaefer> mterry, it has some conflict, so would you mind if I proposed my own branch? (Unless you would like to fix it up :)
[17:51] <mterry> bschaefer, oh that's fine if you've got a branch
[17:51] <bschaefer> bschaefer, i am a nux maintainer, and im sorry i missed it
[17:51] <bschaefer> opps
[17:51] <bschaefer> geez
[17:51] <bschaefer> mterry, ^
[17:51] <mterry> bschaefer, :)
[17:52] <bschaefer> mterry, cool, thanks just wanted to double check, also thanks for making that branch! (sorry again for missing it!)
[17:53] <mterry> bschaefer, awesome
[17:54] <Saviq> greyback, https://code.launchpad.net/~saviq/unity-mir/fix-desktopfile/+merge/186120
[18:13] <xjunior> hey, a question about unity: Is it planned to make multitouch gestures configurable?
[18:15] <bregma> xjunior, are you asking about the phone or the desktop?
[18:17] <xjunior> bregma, desktop
[18:18] <bregma> xjunior, not in Unity, but possibly for applictions
[18:19] <xjunior> bregma, just as an example
[18:19] <xjunior> four fingers swipe left/right now shows and hides the launcher
[18:19] <xjunior> making that change workspace would be more valuable
[18:19] <xjunior> bregma, isn't this kind of thing planned?
[18:19] <bregma> xjunior, no, we have no plans to make the 3- and 4-touch gestures in Unity configurable
[18:20] <xjunior> gotcha
[18:20] <bregma> xjunior, but support for gestures in Unity is still incomplete
[18:20] <xjunior> I see
[18:20] <xjunior> anyway, pretty good job y'all are doing. Keep it up
[18:20] <bregma> 14.04 is coming.....
[18:21] <xjunior> bregma, what's in there?
[18:22] <bregma> xjunior, no decisions yet, but improved gesture support in unity is a good candidate
[18:23] <xjunior> ohhhh, awesome :)
[18:23] <bregma> now that Windows 8 is catching up :)
[18:23] <xjunior> well, that's not my opinion yet :P