=== salem_ is now known as _salem === mmrazik is now known as mmrazik|afk [07:07] thomi: answered FYI === mmrazik|afk is now known as mmrazik [07:24] tsdgeos, can't sleep? ;) [07:27] * thomi lurks in the shadows... [07:28] thomi, you can't sleep either? [07:33] its not that late yet... just 7:30 pm [07:40] Saviq: lol, sure i can :D === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [08:32] * mzanetti just had his first real (not only for testing) phone call using ubuntu phone :) [08:53] mzanetti, :) [08:53] hehe [08:53] mzanetti, dude, you stole my MR :P [08:53] I just happroved it [08:54] mzanetti, yeah, I was looking for it in "Waiting for review" [08:54] ah :) [08:56] mzanetti, btw, when there's a lock screen, the phone app would be launched in a lightdm/guest session anyway [08:57] Saviq: ah ok. will be interesting how the call history will then be merged into the other phone app [08:57] poor boiko :D [08:57] mzanetti, it won't [08:57] huh? [08:57] mzanetti, ah [08:57] mzanetti, yeah, that way it will [08:57] mzanetti, it's really the same with any "locked state" app [08:58] mzanetti, where we will need to transfer data created in the guest session to the user session [08:58] Saviq: yeah... but a camera taking a picture is easier to move than some parts of metadata in some database [08:58] mzanetti, did you see TpLogger's logs? ;) [08:58] mzanetti, it's just xml [08:59] no... didn't see that yet.. [08:59] mzanetti, better tell me which user will get that data if multiuser is enabled ;) [09:00] Saviq: next logged in [09:00] mzanetti, the first one to log in again? the most recently logged in one? the one that was selected in LightDM? [09:00] just a wild shot [09:00] mzanetti, maybe the one that has the number in his/hers phone book? ;) [09:01] I don't know... maybe thats a feature that will be disabled as soon as we have multiuser configured? [09:01] yikes, syntax error [09:01] "which the incoming call currently be the only [09:01] case when that's the case" [09:02] huh? where? [09:02] mzanetti, I wrote that on the bug [09:02] * Saviq needs a microSIM adapter [09:04] mmrazik, hey, any update on jenkins? [09:04] Saviq: should we depend on ubuntu-mobile-icons? [09:05] mzanetti, I don't think so [09:05] mzanetti, the theme should [09:05] Saviq: right now ubuntu-mobile is installed per default... but I do need icons from ubuntu-mobile-icons [09:05] mzanetti, and we depend on the toolkit / the toolkit recommends the icon theme... [09:06] ah ok [09:06] I _think_ so [09:06] makes sense at least [09:06] Saviq: nope :-/ As soon as I see somebody from US I'll bug them [09:06] mmrazik, k, thanks [09:06] mmrazik: there was an update to the ticket... [09:07] mmrazik: it has been moved over to another team or something like that :/ [09:07] mzanetti: yeah.. I didn't realize yesterday that chris sent it to the wrong queue [09:08] ah [09:08] Saviq: so... the lockscreens are done except the blurring. [09:09] mzanetti, cool === pete-woods1 is now known as pete-woods [09:09] Saviq: should I try to get the folding launcher merged as is and integrate with the backend API in a second step? [09:09] Saviq, you ok for me to MP what stands of the infographics? [09:12] mzanetti, sure [09:12] nic-doffay, didn't you already? [09:13] nic-doffay, [09:13] https://code.launchpad.net/~unity-team/unity/infographics-with-lightdm/+merge/163783 [09:13] Saviq, doh! Blame the long weekend. [09:13] nic-doffay, there's a bunch of conflicts to fix, though [09:15] Saviq, yeah I noticed, I'll sort that out then get to your comments... [09:15] nic-doffay, they were mzanetti's ;) [09:16] Saviq, ah I see now. [09:29] mzanetti, you mentioned the timer thing in your QML comments. How would you do that using transitions? [09:32] nic-doffay: hmm... its probably too much of a change now... but I believe not all of your animations and timers are actually used [09:32] paulliu, small comment on https://code.launchpad.net/~paulliu/unity/i18n-po-msgmerge/+merge/165899 [09:32] mzanetti, could you elaborate a bit? [09:32] nic-doffay: for example the signals dataAboutToChange and dataChanged. they both get fired withing very few milliseconds of time [09:32] nic-doffay: so it seems you are stiarting the hide and the show animations at the same time [09:34] nic-doffay: same with all the Component.onCompleted calls. they all do things but in the end only the very last call is actually useful because you seem to just overwrite previous things in newer onCompleted handlers [09:35] mzanetti, most of the OnCompleted called have been removed. [09:35] nic-doffay: yeah... just saying as an example. I think with some of the timers and animations happens more or less the same thing [09:36] mzanetti, how would you have done what you're suggesting with a transition? [09:36] Still now following 100%. [09:36] If it's pertinent I'd like to do it that way next time round. [09:36] nic-doffay: so, you have some items in the model that have a property, e.g. "shown" [09:36] nic-doffay: which would define if the dot is shown or not [09:37] Saviq: ok [09:37] nic-doffay: then instead of connecting a slot to dataChanged and checking if(shown) and starting a timer that in turn triggers a animation, you could just add a transition to the delegate [09:37] nic-doffay: that contains the animation [09:37] nic-doffay: so it would be automatically triggered and animated when the "shown" property in the model changes [09:39] mzanetti, I think that would work for the startup animation. [09:39] nic-doffay: not even needing a transition I guess... in the Dot just do { opacity: model.shown ? 1 : 0; Behavior on opacity { MyFancyAnimation {...} } } [09:39] nic-doffay: just as an example... [09:40] mzanetti, are there good examples of this anywhere? The docs don't really go that much into depth about using transitions in this manner. [09:42] nic-doffay: hmm... just search the shell's code for "Behavior" and "transition" [09:45] nic-doffay, make sure to read http://qt-project.org/doc/qt-5.0/qtquick/qtquick-statesanimations-animations.html#default-animation-as-behaviors too, if you haven't [09:46] nic-doffay, also, there's a set of default animation properties in the toolkit now [09:47] nic-doffay, see http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/UbuntuNumberAnimation.qml and http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/plugin/ucubuntuanimation.h [09:47] and http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/plugin/ucubuntuanimation.cpp for some docs [09:48] mzanetti, I think I'm getting the picture now. [09:48] nic-doffay: cool :) [09:48] Since the opacity is triggered on each mouse click you mean just trigger the animations then instead of using the timer to go through them all right? [09:48] mzanetti, ^ [09:49] nic-doffay: the mouse click animation might be a bit different... don't exactly know what its supposed to do... let me build your branch and try [09:49] mzanetti, because that's the thing. [09:50] The mouse click animation is the same as the startup one. [09:50] Basically. [09:50] I've reused it. [09:50] mzanetti, are you taking into account that the dots/circles are supposed to animate in sequence? i.e. each of them should start animation after a period of time after the previous one [09:50] true... that might indeed require a timer [09:52] mzanetti, yeah that's mandatory. [09:52] mzanetti, but I still learnt something from the comments. [09:53] mzanetti, well, it could be a number animation from 0 to $number_of_dots [09:53] mzanetti, that would trigger animations on the actual dots/circles after having passed each index [09:53] Saviq: yeah... not sure if thats more readable tho [09:54] but I can't find where the timers are actually delayed [09:54] mzanetti, might be more performant, though, if there's just one animation triggering the other animations (I didn't read the current code much, so might be wrong here) [09:54] Saviq: could be... [09:55] nic-doffay: why do you start the hideTimer in dataAboutToBeChanged and the showTimer in dataChanged? [09:55] mzanetti, I'll give it a go. [09:56] nic-doffay: no... I'd like to understand why [09:56] mzanetti, oh wait why [09:56] right [09:56] could be thats correct... I just don't see how right now [09:56] nic-doffay: those 2 signals will get fired basically at the same time (just one event loop run in between) which would render the hide and show animation running at the same time [09:56] (still testing the code it seems to do what it should. so I'm having troubles understanding how it works) [09:57] mzanetti, pete-woods can probably elaborate on that. [09:57] Better than I can at least. [09:59] hmm... there seems to be some hickup with this [09:59] if you increase the window to have the multiuser login list [10:00] then switch between Toomas and Anna, in one direction the hideAnimation is not completely played before the showAnimation kicks in [10:00] mzanetti, I'll sort that out quick... [10:01] works fine when switching Anna -> Toomas, but not so smooth when switching from Toomas -> Anna [10:18] Saviq: hmm... I continue to experience weirdness ever since we switched to the touch input thingie :/ [10:18] mzanetti, of what kind? [10:19] Saviq: at some point all my mouse input only goes to the directionaldragarea instead of the mouseareas above it [10:19] mzanetti, steps to repro? [10:19] Saviq: that state is there for like a minute until it recovers. switching to another app and then back to the shell restores a good state too [10:19] mzanetti, is that on the device, btw, or just desktop? [10:20] Saviq: I think just desktop... haven't played long enough on the device yet [10:20] Saviq: let me push my state... one sec [10:21] Saviq: lp:~mzanetti/unity/phablet-folding-launcher [10:21] Saviq: drag out the launcher and drag it up and down for a while [10:21] Saviq: at some point it will disappear whenever you click it (because the click is recognized by the directionaldragarea) [10:23] mzanetti, is there a reason why the DDA is enabled when the Launcher is out at all? [10:23] Saviq: to hide the launcher again when clicking outside of it [10:24] Saviq: I know can be done using some other MouseArea too... but still I don't feel comfy just working the weirdness around [10:24] mzanetti, k [10:24] mzanetti, yeah, should use InverseMouseArea for that [10:25] mzanetti, and the answer is also: "you should be able to slide the launcher back away" [10:25] which is not implemented atm [10:25] Saviq: where to grab it? [10:25] mzanetti, anywhere [10:25] mzanetti, launcher + some 2-3 GUs outside of it [10:27] mzanetti, the idea behind DDA is that you should be able to just put it on top of anything and it should only really react when the drag is a distinct directional one === malin_ is now known as Malinux [10:27] mzanetti, so yeah, the fact that it goes to recognized state is wrong [10:28] Saviq: ok. fine with me... But I believe it'll cause troubles at some point... eating _some_ mouse events _sometimes_ is the worst that can happen [10:28] mzanetti, hence the cancelling approach, and we just need to make sure to tweak the recognition accordingly [10:29] mzanetti, e.g. if you hold in one place for more than 20-30ms, that's probably not a swipe, so we should just ignore the touch [10:29] mzanetti, same if you drag in the other direction for more than a set threshold [10:30] yikes maguro is slow to build [10:31] mzanetti, wait, it goes to "rejected" state, so that's fine, the launcher should not react in any way? [10:31] Saviq: huh? [10:32] mzanetti, when the launcher is out, it should not react to events from the DDA [10:32] mzanetti, unless we're implementing the "swipe to hide" [10:32] mzanetti, in which case it should go back to fully out on state changed to rejected [10:33] Saviq: well, clicking outside the Launcher should cause the DDA to go to Undecided which makes the launcher hide [10:33] mzanetti, no, that's wrong [10:33] mzanetti, the DDA should be _on top_ [10:33] Saviq: however, the DDA sometimes goes to Undecided even though the click is on the launcher [10:33] Saviq: whats the reason for that? [10:34] mzanetti, because it needs to look at all the events to recognize a directional drag [10:34] mzanetti, or not, and ignore the touch [10:34] mzanetti, that's why I'm saying: if we're not implementing swipe-to-hide, DDA should be ignored when launcher is out [10:35] Saviq: still doesn't explain why you shouldn't put someting on top of the DDA [10:35] Saviq: it explains _that_ you shouldn't do it. but not _why_ [10:35] mzanetti, because if you want to use it [10:35] mzanetti, it needs to look at all the events in its area [10:36] mzanetti, and if you don't want to use it (like you don't, really), you shouldn't use it at all === mmrazik is now known as mmrazik|lunch [10:36] mzanetti, imagine that later we'll have a bunch of those gesture recognizers one of top of the other [10:36] mzanetti, and the first to say "that's mine" [10:36] mzanetti, will get the gesture [10:37] mzanetti, and own the touches that comprise that gesture [10:37] mzanetti, until they recognize it (or reject it), they're supposed to be transparent to input [10:37] mzanetti, but that assumes you're rarely using it until it gets to "recognized" state [10:38] Saviq: sure... but as it reveals the launcher, once the launcher is visible, I don't need that gesture functionality from it any more. so I would expect I could easily put the launcher on top of it. [10:38] mzanetti, sure, but that just means your launcher is transparent to input at some point [10:38] Saviq: no [10:38] mzanetti, you sure of that? [10:38] Saviq: outside the screen... which makes the DDA visible [10:39] mzanetti, ok, but that's correct [10:39] mzanetti, the weird behaviour that you're describing [10:39] mzanetti, suggests that the DDA gets some touch events [10:39] mzanetti, some that it shouldn't [10:39] Saviq: exactly [10:40] mzanetti, but that's not the DDA's fault, it's just an item behind the launcher [10:40] mzanetti, so that means the launcher lets some even through [10:40] mzanetti, and that's when the DDA reacts [10:40] Saviq: didn't have this problem when using the old DraggingArea in exactly the same way [10:48] mzanetti, it's even worse on the device [10:49] thats bad [10:49] bregma, you around? [10:53] mzanetti, but really, if the DDA gets the event, it reacts to it, it's not DDA's fault that it got the event when it shouldn't [10:54] mzanetti, it's just a QQuickItem with a touchEvent handler [10:55] Saviq: I think its the TouchProxy thingie [10:56] mzanetti, what TouchProxy? [10:56] mzanetti, you mean the mouse to touch? [10:56] Saviq: yes [10:56] mzanetti, it doesn't do anything on the device [10:56] mzanetti, it's not installed even [10:56] Saviq: the Launcher is a Flickable which is always interactive... I don't think that all of the sudden that starts to let events pass through [10:57] mzanetti, but it does [10:57] stating at the very same time we merge the DDA and touchadaptor [10:57] mzanetti, somehow the DDA gets the event [10:58] Saviq: anyways... I make the DDA now invisible as soon as the launcher is available... seems better [10:58] mzanetti, not invisible, "enabled = false" [10:59] mzanetti, let's not think of it in visible / invisible - it's never visible [10:59] mzanetti, would be good to have a test case to show the issue [11:01] Saviq: yes... I have the feeling that the issue is not solved yet by disabling the DDA... I think my drag'n'drop of icons has stopped working with the merge too... (which I really can't explain right now, but thats what it is) [11:01] anyways, I'll come back with this once I know more === malin_ is now known as Malinux [11:04] mzanetti, I think all the comments in the review should have been addressed now... [11:05] nic-doffay: ok. I'll review again in a bit [11:05] ta mzanetti === MacSlow is now known as MacSlow|lunch [11:22] mzanetti, with your pinlock branch how can I see that underlay running? [11:22] on the phone... [11:22] nic-doffay: yeah === mmrazik|lunch is now known as mmrazik [11:23] mzanetti, how do I navigate towards it etc [11:26] nic-doffay: ah... sorry [11:26] nic-doffay: that has changed today [11:26] nic-doffay: so... start the shell [11:26] nic-doffay: unlock it [11:26] nic-doffay: then press the power button [11:27] nic-doffay: the shell will lock and upon swiping the greeter away you will see the lock screen [11:28] mzanetti, cool [11:38] Saviq: should the launcher only jump between hidden and shown or should it follow the finger until you release and only onRelease jump to the final state? [11:38] mzanetti, latter [11:38] mzanetti, and it should only stick out after you've passed a certain threshold [11:39] sure [11:39] k [11:43] mzanetti, there's one thing missing from DDA for that - it doesn't let you know where did the gesture begin [11:43] mzanetti, but that difference should be minimal anyway [11:44] Saviq: yep... === alan_g is now known as alan_g|lunch [12:22] hey dandrader [12:23] Saviq, hi [12:23] dandrader, mzanetti discovered a potential issue with the DDA while working on the new launcher, would be good to have that tested [12:23] Saviq, "DDA"? [12:24] dandrader, DirectionalDragArea [12:24] ah === jhodapp is now known as jhodapp|dr [12:24] dandrader, the issue was that with a Flickable over a DDA the DDA received an event at some point [12:24] dandrader: I still experience that stuff I told you on friday [12:25] dandrader, and it seemed to somehow grab the input stack for some time (it settled after 10s or so) [12:25] Saviq: can you reproduce? [12:25] Saviq: the fact that it stops after a bit of time is the weirdest thing, isn't it? [12:25] mzanetti, yes indeed [12:25] Saviq: alt+tabbing away and back restores a good state too [12:26] dandrader, I was also wondering, looking at DDA.cpp, shouldn't the DDA accept the events when it's in Recognized state? [12:27] dandrader, you can reproduce with mzanetti's lp:~mzanetti/unity/phablet-folding-launcher branch [12:27] Saviq, I think events are accepted by default. [12:29] dandrader, can you verify that's true/ === _salem is now known as salem_ [12:31] dandrader, also, shouldn't it grabTouchPoints() in recognized state? === MacSlow|lunch is now known as MacSlow [12:36] mzanetti, Saviq, hmm, I'm looking at the source code of QQuickMultiPointTouchArea now. If I'll mimic what it does, such as "if e.g. a parent Flickable has the mouse grab, don't process the touch events" [12:36] s/If I'll/I think I'll [12:36] that should do it :) [12:36] dandrader, yeah, sounds like we're not doing enough with the events in the DDA [12:37] but it looks like this wholle Mouse vs Touch events story is far from obvious [12:37] Saviq: do we still need to be able to minimize apps by swiping from the left edge? [12:37] mzanetti, yes [12:38] mzanetti, the decision is to refine that behavior instead of dropping it [12:38] Is Jenkins working again? [12:38] dandrader, nope :/ [12:39] mzanetti, but, it should be "reversible", i.e. you should be able to drag back - the actual switch to RunningApps should only happen onRelease [12:40] Saviq: yay :) I thought I broke it but instead I fixed it [12:40] mzanetti, so there's a rework needed (and some design input) [12:40] Saviq, are we going to wait for Jenkins to be up again to merge stuff? any prospect on when is it going to be working again? [12:41] dandrader, yeah, we need CI for merging [12:41] dandrader, I hope it will be back today [12:41] mmrazik, any update on Jenkins? is there anywhere we can look (a RT?) [12:42] Saviq: larry/rick still not online. There is an RT but there is no update (obviously) and I doubt non-reporters have permissions to see it (I didn't report it either; I'm just CCed) [12:43] mmrazik, k thanks [12:43] Saviq: I'm subscribed to the ticket too... so I can watch it and shout once its back [12:44] mzanetti, k, thanks [12:54] mzanetti, would you get the same issue if you had a MultiPointTouchArea or a PinchArea behind a Flickable? [12:54] dandrader: haven't tried === mmrazik is now known as mmrazik|afk === alan_g|lunch is now known as alan_g === mzanetti is now known as mzanetti|lunch === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [13:30] mterry, you need to turn push-to-talk on... [13:30] * greyback joining, mumble being funny [13:31] dednick, nic-doffay standup === mzanetti|lunch is now known as mzanetti [13:33] Cimi, can you hear us? [13:33] nope [13:35] nic-doffay, we could hear you [13:35] Saviq, cool sorted now [13:35] four restarts of mumble. [13:36] nic-doffay, you won, I had three today === jhodapp|dr is now known as jhodapp [13:44] Saviq, I had push to talk on the whole time, but it looks like the mic was on at the beginning? I accidentally launched two mumbles, maybe that screwed something up. Sorry :) [13:45] mterry, yeah, might be, we got some static from you [13:45] mterry, that's fine [14:13] anyone know why code not merging into lp:unity/phablet? [14:17] dednick, Jenkins is down [14:18] dandrader: ah. good reason === davmor2_ is now known as help === help is now known as davmor2 === alan_g is now known as alan_g|tea [14:27] greyback: hey. on the mailing list there is a guy trying to access your chinstrap data... can you put the packages in there to some public place? [14:28] mzanetti: ok [14:33] greyback, people.canonical.com is usually a good place [14:33] Saviq: hmm, never used that before [14:34] greyback, you have a $HOME in there, so you must've ;) [14:34] greyback, anyway, you can just ssh to it with your usual shellname / ssh key [14:34] greyback, and put stuff in public_html [14:34] Saviq: interesting, yep just seeing that now === alan_g|tea is now known as alan_g [14:43] greyback: are you working on your chinstrap issue? [14:43] sergiusens: yep, just replying now === dandrader is now known as dandrader|afk [14:55] sergiusens, here's a fix for the launcher issue - https://code.launchpad.net/~dandrader/unity/phablet_fixLauncherTopScroll/+merge/165896 [14:55] sergiusens, happroved, but jenkins is on holidays :/ [14:55] Saviq: saw it :-) [14:55] Saviq: want to have jenkins working on it first and push it in before creating a build today :-) [14:56] sergiusens, I wouldn't bet on it, there's 6 branches in queue for landing, that's 3 hrs in itself [14:57] and that's _when_ jenkins is back :/ [14:59] Saviq: jenkins is back [15:00] Saviq: ack, I'll do some manual building, testing and streamlining ;-) [15:00] Saviq: can you just in case make the other branches have this one as a prereq? [15:01] sergiusens, the release one does [15:01] sergiusens, https://code.launchpad.net/~unity-team/unity/phablet.release-178/+merge/165995 [15:02] sergiusens, it should also have https://code.launchpad.net/~saviq/unity/phablet.unlock-on-focus/+merge/165989 as prereq, but we can only do one prereq [15:02] sergiusens, but indeed, Mr. J is coming back [15:05] Saviq: you can always chain/serialize them :-) [15:06] sergiusens, yeah, but then I need to resubmit them to add the prereq... and merge the prereq into the branch to be merged... [15:07] Saviq: yeah, too much... let me just try and keep an eye on it === dandrader|afk is now known as dandrader [15:08] sergiusens: hwo can I disable the locking of the screen? [15:10] mzanetti: there's supposed to be a gconf/gsetting for it [15:11] sergiusens: the shells AP tests are failing becuase the screen locks in between all the time [15:12] I guess AP should inhibit the screen lock === dandrader is now known as dandrader|lunch [15:13] sergiusens: how can I disable it now? [15:13] manually? [15:16] mzanetti: I'm looking [15:23] mzanetti: not sure it's deployed yet [15:24] sergiusens: hmm... so currently its hardcoded in a binary? [15:52] mzanetti: bzr revert po :D [15:52] tsdgeos: yeah... [15:53] tsdgeos: why do they change on their own btw? [15:54] tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-fix-ap-on-device/+merge/166084 [15:54] mzanetti: we run msgmerge on them, paulliu has a fix for it [15:54] it's just CI-less :D [15:55] tsdgeos: press() + move() + release() doesn't seem to do actual drags when using uinput [15:55] tsdgeos: I had to cut down a little on the show_hud function/test [15:55] mzanetti: dandrader had a fix for that, or? [15:55] tsdgeos: oh... [15:56] dandrader: please confirm if/when your back allows [15:56] mzanetti: https://code.launchpad.net/~dandrader/unity/phablet_autopilotTouchOnly/+merge/165666 ? [15:56] tsdgeos, mzanetti yes, that's the merge proposal [15:56] oh... cool [15:57] dandrader: did you test on the phone? [15:57] mzanetti, autopilot tests on the phone? no. [16:00] dandrader: ok [16:01] dandrader: because I just tried and the resulting MR looks quite similar to yours :) [16:01] dandrader: your's is better so I'll adjust mine to only add the few missing parts [16:04] om26er: https://code.launchpad.net/~mzanetti/unity/phablet-fix-ap-on-device/+merge/166084 [16:05] om26er: so what we need is this MR ^^ and also dandrader's one [16:05] om26er: and additionally the bugfix for the screenlock prevention [16:05] then I think AP works again on the phone [16:05] Saviq: FYI [16:05] ^ [16:06] all: Jenkins is back [16:06] yay! [16:06] Saviq: anyother FYI :) ^ [16:07] mzanetti, yeah, I know already ;) [16:09] dandrader, we probably shouldn't have the python-evdev dependency in the end, should we? autopilot-touch should pull it in? [16:11] Saviq, well, CI was failing without it [16:11] Saviq, do we install autopilot-touch? [16:12] mzanetti, ^ [16:12] Saviq, the code that needs python-evdev comes from autopilot-python. === mmrazik is now known as mmrazik|afk [16:12] So the correct thing would be for autopilot-python to depend on python-evdev [16:12] no, we are not [16:15] dandrader, mzanetti k, let's leave it for now, but I do remember thomi writing something about this [16:15] obviously can't find it now [16:15] bbl, cheers all [16:16] Saviq, I reported a bug on it [16:16] Saviq, see you [16:16] https://code.launchpad.net/~thomir/autopilot/autopilot-desktop-add-evdev-recommends/+merge/165938 [16:16] dandrader: Saviq^ [16:16] yeah, that [16:20] haha... Jenkin's build queue... === greyback is now known as greyback|food [16:27] mterry: ignoring anything blur related, you could start reviewing this https://code.launchpad.net/~unity-team/unity/phablet-pinlock/+merge/165924 [16:32] mzanetti, Saviq the very same issue occurs if I have a MultiTouchArea behind Flickable [16:32] dandrader: hmm... sucky [16:32] MultiPointTouchArea I mean [16:32] sil2100: is the merge job still down? [16:34] elopio: a few hours ago we were still having problems... [16:34] elopio: sorry about that [16:34] elopio: I guess we're still broken ;/ [16:35] sil2100: no problem. I was just wondering if there was a missing manual step :) [16:35] I'll take a look tomorrow. === alan_g is now known as alan_g|life [17:15] dandrader, so bug in Qt? === jono is now known as Guest93857 [17:19] Saviq, yes === greyback|food is now known as greyback [18:00] Hi. I'm accustomed to using Alt-Fx to switch to workspace x. How can I do this in unity 7.0.0daily13.04.18~13.04-0ubuntu1 ? [18:15] qengho: in the Keyboard applet, under "shortcuts" tab, and in "Navigation" you could set the keyboard shortcuts for "Switch to workspace x" manually [18:23] greyback: okay, i've done that. Alt-F1, -F3, -F4, -F5, -F6 all work well. Alt-F2 raises a unity Run-a-command modal. [18:23] qengho: yep. That may be not change-able there, but in "ccsm" in the Unity plugin, you may be able to change it there [18:25] greyback: so, it's a conflict that's not warned about. On what project should I file a bug? [18:25] qengho: probably lp:unity, since they're doing something that gnome-keybaord doesn't know about and should [18:26] qengho, if you want to change the Alt+F2 for unity, go to CCSM (Compiz Config Setting Manager) -> Ubuntu Unity Plugin and under the general tab change the Alt+F2 setting :) [18:26] ccsm SEGVs. [18:26] le sigh. [18:26] :( [18:27] qengho, you should be able to use gconf-editor to change it then [18:28] and do a edit->find for unityshell [18:30] for example my options are under: /apps/compiz-1/plugins/unityshell/screen0/options [18:35] bschaefer: there is no /apps/compiz-1 . In /org/compiz/profiles/unity/plugins/unityshell, execute-command is set to something else. [18:35] qengho, I ment in gconf-editor [18:37] bschaefer: execute_command is Space . [18:38] qengho, strange...hmm [18:38] bschaefer: Oh, but while editing, compiz crashed and now Alt-F2 works. [18:38] * qengho boggles. [18:39] qengho, hehe, so things are working how you want? That is strange, but CCSM is strange... === mmrazik|afk is now known as mmrazik === greyback is now known as greyback|away === greyback|away is now known as greyback [22:23]