[00:13] using ubuntu 13.10 and unity 7.1.2 here, was wondering where I would find the file in my system for the unity gui's launcher icon padding. I've found the 'dash_widget.json' which had padding variables inside of it, but was not what i was looking for. [00:15] I want to edit the left and right padding variables for the unity launcher. the space between the icons and the desktop. [00:22] is this possible? [00:23] I've edited something similar in the cinnamon app switcher before... [00:29] baron_zemo: Hi, I'm not quite sure I follow what you are asking. Do you want to decrease/increase the size of the icons (and the Launcher) or are you wanting to leave the Launcher the same width and make the icons smaller or something else? [00:30] ChrisTownsend, no icon sizes aside, there is a constant space between the icons and the windows you open. the space around the icons, to the left and right [00:31] I'm pretty that's just padding, and it either stays the same as you increase icon size, or increases proportionally [00:31] there's got to be a variable/function for it somewhere. [00:36] this: http://imgur.com/a/vqpQQ [00:36] ChrisTownsend, http://imgur.com/a/vqpQQ [00:38] baron_zemo: Ok, thanks for the pic. That helps me visualize what you are asking. I'm pretty sure this value is hard coded in the Unity code. Feel free to enter a bug to make this configurable, and as always, patches are welcome:) [00:41] ChrisTownsend, aw man, yeah if it's hardcoded and not a padding variable, yeah . okay thanks man. [00:42] baron_zemo: Sorry I didn't have a better answer for you:) [00:46] ChrisTownsend, better than this guy http://askubuntu.com/questions/368214/where-can-i-find-unity-7-1-2s-appearence-gui-files-on-my-drive [00:46] :'( [00:47] Wow...just wow. [00:47] baron_zemo: Have you tired the Unity Tweak tool? [00:47] Err, I mean tried. [00:48] yes, unity-tweak, ubuntu-tweak, dconf-editor and myUnity and tweak-tools [00:49] I'm 99% sure i've adequately looked them over and haven't seen the option, or maybe i saw it but did not recognize it [00:49] Ok, I know what you are looking for wasn't in it, but I thought you might find it handy, but you are already aware. [00:49] it's no big deal ofcourse i just have free time. [00:49] Heh, ok. === seb128_ is now known as seb128 === duflu_ is now known as duflu === iahmad is now known as iahmad|afk [09:27] mhr3: can you check https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200 fixes the problem for you? It does here [09:27] mzanetti: how's the autolanding thing going? need help? we really need to get going :D [09:28] we've 18 approved reviews :D [09:29] oh the conflicts! :P [09:29] tsdgeos: only 18? I thought it would be more :D [09:29] MacSlow: how's larsu's branch integration going? === iahmad|afk is now known as iahmad [09:38] tsdgeos: FYI: CI should work again, but our AP tests are failing on trusty [09:39] mzanetti: sure, so who's fixing them? [09:39] :D [09:39] tsdgeos: MacSlow is. actually larsu already prepared a branch which should fix. needs a little more love by MacSlow still [09:40] ookidoki [09:40] mzanetti, all done [09:40] MacSlow: ah cool. are all the tests passing on that branch? [09:41] mzanetti, locally yes... on jenkins I don't know [09:41] MacSlow: ok. which branch? [09:42] mzanetti, I assume you're talking about the notify-osd/unity8 notification-service-takeover [09:42] mzanetti, it's all merged by now [09:43] MacSlow: it's merged to trunk already? [09:43] mzanetti, Saviq did that yesterday [09:43] ah. nice [09:43] * mzanetti triggers a few jenkins runs [09:45] mzanetti, yup... both relevant branches updated... http://bazaar.launchpad.net/~indicator-applet-developers/notify-osd/trunk/revision/473 http://bazaar.launchpad.net/~unity-api-team/unity-notifications/trunk/revision/186 [09:45] mzanetti, so no more mass-failure should happen [09:46] MacSlow: ah I see, that wasn't in unity8 [09:46] MacSlow: so I guess we still need to wait for those projects to be released [09:46] mzanetti, tested the notification-service take-over only on my desktop though [09:46] mzanetti, correct... the changed needed to happen in the notification-backend and notify-osd itself [09:53] mzanetti, do we need tests here? https://code.launchpad.net/~nick-dedekind/unity8/lp1240756/+merge/192939 [09:55] Cimi: hmm... not really I'd say. [09:55] mzanetti, this only because I'm not the author of the branch? :D [09:56] Cimi: yeah, you got it [09:56] hah [09:56] :D [09:56] Cimi: no... I mean. We could test if the image is invisible when !== Ready [09:56] Cimi: but that kinda tests the Image {} itself which we assume is tested withing Qt [09:56] or width of control [09:57] Cimi: actually, yeah... for the width we probably should have tests, you're right [09:57] might write a test for him to safe time [09:58] mzanetti: i made the switching previous thing crash [09:58] but now i can't repro it [09:58] :-( [09:58] tsdgeos, on https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200 [09:58] and since somehow it seems i have the crash stuff disabled in my desktop [09:59] i don't even have the bt :-/ [09:59] Cimi: yes? [10:02] tsdgeos, I just read the diff so I don't know the rest of the code [10:02] tsdgeos, do you even have apport installed? :) [10:02] tsdgeos, I was not a huge fan of setting m_inContentHeightKeepHeaderShown = m_headerItem && m_headerItem->y() == contentY(); [10:02] setContentHeight(contentHeight); [10:02] m_inContentHeightKeepHeaderShown = false; [10:02] mhr3: i actually do :D [10:02] Cimi: you are welcome to fix it otherwise [10:03] tsdgeos, I don't know the code, I was just wondering if you had better ideas [10:03] Cimi: if i had better ideas, i would have created a better patch [10:03] fair :D [10:04] tsdgeos, fwiw i just tested it, does indeed fix the header [10:04] mhr3: what was the "There's still the issue Saviq described - the previews move when swiping between them, " in https://code.launchpad.net/~unity-team/unity8/switching-previews/+merge/189556 [10:05] mhr3: i don't think i see anything wrong while swiping [10:06] tsdgeos, there seems to be a couple more revs, so perhaps it got fixed? :) [10:06] mhr3: maybe, can you describe to me what it was or try it yourself? [10:07] you wouldn't miss it, it was very visible and weird :) [10:07] basically the previews were moving into [0,0] when you swiped [10:09] ok [10:10] tsdgeos, can you put m_headerItem && m_headerItem->y() == contentY() just in update layout? [10:11] just a no is enough :) [10:11] I know you worked loads on that yesterday [10:13] Cimi: update layout == viewportMoved ? [10:14] tsdgeos, yeah sorry [10:19] Cimi: the test says i can't [10:19] i.e. do the change you suggest and testHeaderPositionBug1240118 doesn't work anymore [10:19] can you please confirm? [10:22] booooo [10:22] i knew it [10:22] this test wasn't going to fly on the VM's [10:34] mzanetti: you have a " print("model is", model)" in the switching previews thing [10:34] tsdgeos: that does sound like me, altough I thought I had removed them all [10:34] tsdgeos: will fix [10:35] mzanetti: also why is onClicked now different to onPressAndHold in GenericScopeView? [10:36] tsdgeos: because we always want to show a preview onPressAndHold. and we always want to show a preview onClicked except for apps [10:36] hmmmok [10:37] not cool harcoding the names in there [10:37] is that something the scopes can help us with? [10:38] tsdgeos: I had this discussion with mhr... eventually they convinced me to do it like this [10:38] ok [10:38] mzanetti: AlbumTile gone because noone was using it? [10:39] tsdgeos: yeah... I wanted to keep this merge clean as in only changing stuff required for the preview and not mixing it up with the cleanup that's needed in the Dash folder [10:40] tsdgeos: however, because of required API changes of Tiles I felt it doesn't make sense to update that one now even though unneeded and drop it in 3 weeks again [10:43] ok [10:45] tsdgeos: pushed the removal of the print() [10:47] ok [10:49] mzanetti: looks good to me [10:49] the lack of tests is a bit unfortunate [10:50] is this urgent to get merged? otherwise we can wait on the tests even if they take some time, no? [10:52] iow [10:52] do you think there would be a benefit on getting this merged without tests? [10:52] like getting more real life testers sooner? [10:53] tsdgeos: I think the only benefit would be to stop causing conflicts. I rebased this already like 10 times and as you see it's starting already again [10:54] tsdgeos: but ok. I'm finishing that albumart provider fix and then try to start getting some tests [11:00] mzanetti: i'm ok with getting it in if it's a hassle to maintian [11:00] now if we could get it in :D [11:00] indeed [11:08] mzanetti: not sure i understand the first point of your comment in https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505 [11:08] when you want me to check it? [11:09] tsdgeos: the narrowMode thing? [11:09] mzanetti: the "check for length == 1 is in the childItem assignment " [11:10] tsdgeos: so you have a property called "childItem" which might be set to a list, and everytime you use "childItem" you check if it in fact just one item [11:10] yes [11:10] oh wait... I might have something overlooked... gimme a sec [11:12] tsdgeos: ok, so what I meant is that I think it would make more sense to make sure childItem always has only one childItem when setting it. [11:12] instead of checking that each time you use it [11:12] would require to make it a real property instead of an alias tho [11:13] so has downsides too [11:14] tbh i think it's fine as it is [11:14] it's not like anyone's going to use it more than how we are [11:14] ok then [11:16] mzanetti: about the "FIXME: workaround rendering issue due to use of ShaderEffectSource in" [11:16] i have no clue what it's about tbh :D [11:18] not sure to what it applies either :D [11:18] tsdgeos: so the UbuntuShape blocks when creating [11:18] tsdgeos: if we wouldn't use this huge cacheBuffer, lots of ubuntu shapes would be created when swiping the dash left/right [11:19] tsdgeos: which would cause stuttering [11:19] so yeah. I think we should update that FIXME given that it's still valid but refers to non existent stuff for explaining it [11:21] tbh given we have billions of async loaders inside of async loaders [11:21] the problem is just that UbuntuShape needs to be more performan [11:22] :D [11:22] yeah... that's what it comes down to [11:22] and this FIXME should probably just say: "Need this huge cachebuffer because UbuntuShape is performing bad" [11:22] otoh one wouldn't want the dash to create itself all the time either [11:22] it's probably more battery efficient just to keep it in memory all the time [11:22] than to waste cpu creating/decreating it [11:22] but not really memory efficient [11:23] well, it all depends on how much memory [11:23] but i'll trade anything for battery life :D [11:23] tsdgeos: yeah. somewhere there are numbers on how much it is [11:24] well, how much it was when I did the measurements. its quite a long time ago by now [11:24] but it was *a lot* [11:24] anyway i'm not really sure it's me that has to update that comment in this MR since it doesn't really touch that besides putting it inside another item [11:24] mzanetti: well, we did have the people scope and no delegatecreationrange for inner listviews [11:24] so yes, i can see it was quite a lot [11:25] mzanetti: but if you want me to update the comment, tell me what you want so you're happy with the review :D [11:25] / TODO Investigate if we can switch to a smaller cache buffer when/if UbuntuShape gets more performant [11:25] ? [11:26] much better, yes [11:29] mzanetti: about the tests [11:29] i'm not sure they make much sense tbh [11:29] mzanetti, albumart provider fix? [11:29] what's the issue with it? [11:29] mzanetti: what would i be testing besides testing that the tabbar works, that should be tested by the sdk guys? [11:30] tsdgeos: I guess there's logic in unity8 which actually switches to a certain scope when clicking on a tab, no? [11:31] onSelectedTabIndexChanged: { [11:31] dashContentList.currentIndex = selectedTabIndex; [11:31] } [11:31] yep [11:31] heh, ok [11:31] i mean i can do some tests [11:31] but ultimately this MR has "no code" [11:32] it's just refactoring stuff [11:32] and adding the tabbar [11:32] tsdgeos: assuming the TabBar API changes to rename the parameter selectedIndex. this would break unnoticed. [11:33] so yes... I'd still think a test for clicking a tab and checking if the according scope comes into view would be good [11:34] tsdgeos: btw. exactly this happened with the DashBar before... the SDK changed their api and I guess we still wouldn't know that clicking the dashbar at the bottom was broken if the test wouldn't have cought it [11:35] ok [11:35] will do [11:41] Did anybody have any luck with using kazam to capture a screen-recording under trusty? [11:42] * mzanetti never heard of kazam before [11:43] mzanetti, it's a pretty handy screen-recording tool... uses gstreamer... written in Python... quite nice [11:43] it was all fine under saucy [11:45] has a K and is not kdelibs-based? where's the world going! [11:46] :D === alan_g is now known as alan_g|afk [11:49] tsdgeos, well... I'm doing Qt as an old-schoon glib/gtk+ person... so you will have to deal with the K in a non KDE-app ;) === alan_g|afk is now known as alan_g === jhodapp|afk is now known as jhodapp [12:17] * tsdgeos kicks ScopeView and GenericScopeView [12:17] why is GenericScopeView a ScopeView [12:17] becaue ScopeView is GenericGenericScopeView [12:17] ... [12:19] * tsdgeos gets the axe ready === MacSlow is now known as MacSlow|lunch [12:30] greyback_: any chance of looking over some unity-mir MPs? [12:31] alan_g: sure [12:40] does anybody know about the search history expected behaviour on the dash? [12:40] it seems tehre's code that tries to make it common for all the scopes [12:40] but then there is code that fails [12:40] so i wonder if it has to be shared or not [12:40] mzanetti: mhr3: greyback_: all: ↑↑↑↑ [12:41] i think nic-doffay was trying to fix it some time ago [12:41] so... he'd know :) [12:41] tsdgeos: good question. I'd say it doesn't make sense to bring up recent music searches in e.g. the video scope [12:42] because with my tabbar rework [12:42] there's a single header [12:42] and thus the history is now shared [12:42] nic-doffay: you know? [12:43] due to the home lens, where multiple lenses are sent a search term at one go, I don't think there's a clean way to make the history per-scope [12:47] well, i'll leave it like that until someone comments then :D [12:47] will add a note to the MR too [13:00] tsdgeos, sorry was running autopilot tests couldn't click or type :P [13:01] tsdgeos, re that I had a branch I was working on to bring the search history out of the page header. [13:01] However I was running into an issue where adding queries stopped working and had to shelve it to continue on an sdk issue. [13:01] That's where it stands currently. [13:15] tsdgeos: https://code.launchpad.net/~mzanetti/unity8/fix-1237829/+merge/193233 [13:23] pstolowski: http://i.imgur.com/LWrDtqU.png (notice something?) [13:26] mzanetti, you fixed ac/dc bug? :) [13:26] heh, yeah. feel free to review it [13:26] https://code.launchpad.net/~mzanetti/unity8/fix-1237829/+merge/193233 [13:27] mzanetti, yeah, just noticed LP notification, cool :) === MacSlow|lunch is now known as MacSlow [13:58] i am writing an indicator using libappindicator3, where can i find the list of all icons available? [14:00] voldyman, have a look at http://iloveubuntu.net/icon-library-20-released-gtk3-and-python-3-support [14:00] thank davidcalle [14:00] voldyman, yw [14:20] pstolowski: do you know why my home scope only shows some music in like one of 100 runs? [14:23] mzanetti, local music files? if online music - is you network connection reliable? [14:23] pstolowski: local music [14:23] pstolowski: they show up in the music scope. but I've seen it only very rarely in the home scope [14:24] mzanetti, surfacing, or in response to search? [14:24] pstolowski: surfacing [14:24] pstolowski: on the desktop that is. works fine on the phone [14:24] mzanetti, aaah [14:27] mzanetti, did you by any chance unselected 'Music' in dash filters in the home, while search query was empty? [14:27] * mzanetti checks [14:28] pstolowski: hmm... dash filters? [14:28] pstolowski: I'm still talking about unity8 [14:28] and I don't run unity7 so, no, I didn't change any settings there [14:28] mzanetti, yes, but I mean filters in unity7 (because this would update settings that affect surfacing also in unity8) [14:29] mzanetti, what does 'gsettings get com.canonical.Unity.Lenses home-lens-default-view' say? [14:29] pstolowski: ['more_suggestions.scope', 'more_suggestions-amazon.scope'] [14:30] this is probably still from the last time I started unity7 in quantal :D [14:30] mzanetti, ah, so that's why, it should have music.scope [14:31] mzanetti, this key controls surfacing search [14:31] pstolowski: like this? ['more_suggestions.scope', 'more_suggestions-amazon.scope', 'music.scope'] [14:31] mzanetti, and it can be edited by user via filters in Home in unity7 (when search is empty) [14:31] mzanetti: standup [14:31] mzanetti, yes [14:32] pstolowski: hmm... still doesn't show up [14:36] tsdgeos, btw your header fix doesn't fix the scrolling issue [14:36] mhr3: which scrolling issue? [14:37] tsdgeos, lp:1240118 meaning if i revert r456, it's still broken [14:37] tsdgeos, so i guess we should split the bug into two [14:39] mhr3: well, the fix we had for bad sortfilterproxy/qml is not "the right one", i'm waiting on "the right one" to get updated to the qt packages [14:39] and that may or may not fix the other thing [14:39] mzanetti, home scope doesn't monitor this key for changes, so you need to restart it. btw, it works here [14:40] mhr3: so yeah you may want to split the bug [14:40] tsdgeos, good, could you comment on that bug and perhaps link it? [14:40] tsdgeos, did you do bzr commit with --fixes=lp:xxx ? [14:40] nope [14:41] never remember to do that [14:41] good in this case, at least we can unlink the branch and link it to the split bug [14:41] pstolowski: yay! thanks. this works now [14:45] mzanetti, got a moment, it's regarding another older branch. [14:45] Looks like I'm stuck with autopilot until image 8 is sorted. [14:45] nic-doffay: sure [14:46] mzanetti, great === dandrader is now known as dandrader|afk === pstolowski is now known as pstolowski|bbl [14:47] tsdgeos, https://bugs.launchpad.net/unity8/+bug/1246351 [14:47] Ubuntu bug 1246351 in Unity 8 "Positioning of the Dash's header gets confused" [Medium,In progress] [14:49] ok [14:50] mhr3: thanks :-) === dandrader|afk is now known as dandrader [15:01] mzanetti, lp:~nicolas-doffay/unity8/scope-search-refactor [15:02] You'll see the SearchHistory has been moved out to the Dash. [15:02] and passed through to the page header where the query is added. [15:02] I've already confirmed the memory address of both page headers in the Dash and that in the PageHeader are the same. [15:02] Thing is queries don't appear to be added, I have no idea why. [15:26] nic-doffay: hmm... seems to work fine here [15:26] nic-doffay: so the purpose is to have the same search history everywhere, right? === alan_g is now known as alan_g|tea [15:31] mzanetti, that's right yeah. [15:31] nic-doffay: works here [15:31] mzanetti, so you've tested it and it works as it should? [15:32] yeah [15:32] mzanetti, haha well I must have missed something. [15:32] mzanetti, in that case review? [15:32] nic-doffay: well, how do you unfocus the textfield? [15:33] nic-doffay: maybe there's an issue in one of the code paths that add something to the history. it's many of them [15:34] mzanetti, if so can you include that as a review comment? [15:34] https://code.launchpad.net/~nicolas-doffay/unity8/scope-search-refactor/+merge/193265 [15:34] mzanetti, linking it to the bug now. [15:34] nic-doffay: I'd still like to get to the bottom of it. if it's not working for you there must be an issue somewhere [15:35] mzanetti, it was a while ago I last checked. I'm going to merge trunk and test it again. [15:35] nic-doffay: ok yeah. your branch seems really old [15:35] mzanetti, suggestions for the latter part of this bug are welcome though. https://code.launchpad.net/~nicolas-doffay/unity8/scope-search-refactor/+merge/193265 [15:36] which bug? [15:36] nic-doffay: ^ [15:37] nic-doffay: when you commit a bugfix, use this: bzr commit --fixes lp:123456 [15:37] so the bug report will get linked to the branch [15:37] mzanetti, cool [15:38] booo for me [15:38] booo for tsdgeos! [15:38] i thought this would work [15:38] http://pastebin.kde.org/p2giuhabx [15:38] but doesn't :-S [15:38] and the damn qml engine doesn't tell me those ugly [15:39] YOU ARE DEPENDING ON NON NOTIFYABLE STUFF [15:39] it usually says when you try to do stuff like that with a non notifuable property [15:39] tsdgeos: I actually think that's QMetaObject that does [15:40] or well, something in the engine combined with the metaobject information [15:40] ./qml/qml/qqmljavascriptexpression.cpp:254: QLatin1String(" depends on non-NOTIFYable properties:"); [15:40] it requires a QObject to be able to figure that out [15:40] well, that's what you say :D [15:41] and since it's not a qobject, it may as well assume it's non notifiable if it can do that :D [15:41] I tend to agree with that [15:41] but then, I've much too little knowledge about javascript to answer that [15:41] same here [15:42] mzanetti, it's working here after merging trunk. [15:42] ok... doesn't stop to get weirder [15:43] nic-doffay: anyways, please manually link the bug report with the branch. you can do that in the launchpad ui [15:43] I'll do the review soonish. need to leave for a while now [15:43] mzanetti, I've done that. [15:43] cool cheers [15:43] gl with your travels. [15:44] huh? [15:44] just going for groceries and alcohol man :D [15:44] bbl === alan_g|tea is now known as alan_g [15:49] mzanetti, haha [15:49] That's the equivalent of travelling for me now. === jhodapp is now known as jhodapp|sick [16:06] hey dednick [16:06] Cimi: hi [16:06] dednick, I wanted to help you on tests for https://code.launchpad.net/~nick-dedekind/unity8/lp1240756/+merge/192939 [16:06] dednick, but cannot find them :) [16:07] but maybe we don't need tests for that [16:08] Cimi: there are no indicator tests at the moment. They're in ubuntu-settings-components, but it hasn't landed yet [16:08] ok [16:08] so I'll approve now [16:22] tsdgeos, was looking at this https://bugs.launchpad.net/unity8/+bug/1152150 [16:23] Ubuntu bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,Confirmed] [16:23] tsdgeos, you have any ideas out of your mind? [16:25] maybe if we can detect horizontal velocity we could stop flicking the list view and switch to the other scope [16:25] I'll try in 30 mins [16:25] Cimi: that's the joy of list inside of list [16:25] can't think of anything on top of my head [16:25] I'll try === dandrader is now known as dandrader|lunch [16:31] Saviq: ping === jono is now known as Guest50058 [16:49] if you guys are bored, there are some of my branches waiting reviews [16:50] https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414 [16:50] https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/192118 === pstolowski|bbl is now known as pstolowski [16:50] https://code.launchpad.net/~cimi/unity8/remove-mathlocal/+merge/192709 [16:58] mzanetti: pushed the tests for the tabbar thing [16:59] tsdgeos, so [16:59] tsdgeos, horizontal velocity is 0 on vertical scoll [16:59] tsdgeos, can we patch LVWPH? [17:00] Cimi: for what exactly? [17:00] tsdgeos, having horizontal velocity on a vertical scroll [17:00] Cimi: lvwph is not the top list [17:00] don't think that changing lvpwh will help [17:00] or maybe it will [17:01] tsdgeos, you can do something like onHorizontalVelocityChanged: if (horizontalVelocity > 2 * verticalVelocity) flick left or right [17:01] Cimi: not sure i understand the bug at all [17:01] it's all write in the oren-speech [17:01] i've still not totally mastered [17:01] Cimi: can you translate to devel-speech what's the problem? [17:01] tsdgeos, it means that sometimes you want to change lens but you're stuck into the vertical scrolling of the listview [17:01] ok [17:02] tsdgeos, it depends on how you start the flick basically [17:02] tsdgeos, tolerance is difficult [17:02] so was thinking of detecting the horizontal speed [17:05] Cimi: tbh LVWPH doesn't do that [17:05] it's the flickable [17:05] tsdgeos, I know [17:05] and it won't give us the hSpeed [17:05] since it's not hScrollable [17:05] tsdgeos, but I don't know if you can get the function from it [17:05] ah ok [17:05] you answered [17:06] tsdgeos, we can add code to calculate this [17:06] Cimi: imho the easiest way is a separate mousearea [17:06] tsdgeos, or put a mouse area [17:06] tsdgeos, yeah :D [17:06] i.e. LVPWH doesn't get any "input event" [17:06] all it gets is [17:06] "your viewport moved" [17:07] ok [17:07] tsdgeos, mouse area on top how? [17:07] tsdgeos, we need not to steal events [17:08] Cimi: you can make mousearea not steal events [17:09] tsdgeos, but it usually does steal them [17:09] tsdgeos, if you do onPressed it gets the event [17:10] let me try [17:10] Cimi: propagateComposedEvents ? [17:11] ok [17:23] it's not that simple [17:24] horizontalVelocity represents only when the view moves [17:24] doesn't seem the speed of the actual mouse action [17:24] dandrader|lunch, ping me when you're back === dandrader|lunch is now known as dandrader [17:48] Cimi, ping [17:56] dandrader, so we have listview that allow vertical scrolling [17:56] for each scope [17:56] dandrader, while we have another list view for horizontal scrolling [17:56] to change lens [17:57] dandrader, sometimes we start a vertical flick in a scope while we wanted to scroll left or right [17:57]