[00:13] <baron_zemo> 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] <baron_zemo> I want to edit the left and right padding variables for the unity launcher.  the space between the icons and the desktop.
[00:22] <baron_zemo> is this possible?
[00:23] <baron_zemo> I've edited something similar in the cinnamon app switcher before...
[00:29] <ChrisTownsend> 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] <baron_zemo> 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] <baron_zemo> I'm pretty that's just padding, and it either stays the same as you increase icon size, or increases proportionally
[00:31] <baron_zemo> there's got to be a variable/function for it somewhere.
[00:36] <baron_zemo> this: http://imgur.com/a/vqpQQ
[00:36] <baron_zemo> ChrisTownsend, http://imgur.com/a/vqpQQ
[00:38] <ChrisTownsend> 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] <baron_zemo> ChrisTownsend, aw man, yeah if it's hardcoded and not a padding variable, yeah .  okay thanks man.
[00:42] <ChrisTownsend> baron_zemo: Sorry I didn't have a better answer for you:)
[00:46] <baron_zemo> 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] <baron_zemo> :'(
[00:47] <ChrisTownsend> Wow...just wow.
[00:47] <ChrisTownsend> baron_zemo: Have you tired the Unity Tweak tool?
[00:47] <ChrisTownsend> Err, I mean tried.
[00:48] <baron_zemo> yes, unity-tweak, ubuntu-tweak, dconf-editor and myUnity and tweak-tools
[00:49] <baron_zemo> 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] <ChrisTownsend> 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] <baron_zemo> it's no big deal ofcourse i just have free time.
[00:49] <ChrisTownsend> Heh, ok.
[09:27] <tsdgeos> 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] <tsdgeos> mzanetti: how's the autolanding thing going? need help? we really need to get going :D
[09:28] <tsdgeos> we've 18 approved reviews :D
[09:29] <mhr3> oh the conflicts! :P
[09:29] <mzanetti> tsdgeos: only 18? I thought it would be more :D
[09:29] <mzanetti> MacSlow: how's larsu's branch integration going?
[09:38] <mzanetti> tsdgeos: FYI: CI should work again, but our AP tests are failing on trusty
[09:39] <tsdgeos> mzanetti: sure, so who's fixing them?
[09:39] <tsdgeos> :D
[09:39] <mzanetti> tsdgeos: MacSlow is. actually larsu already prepared a branch which should fix. needs a little more love by MacSlow still
[09:40] <tsdgeos> ookidoki
[09:40] <MacSlow> mzanetti, all done
[09:40] <mzanetti> MacSlow: ah cool. are all the tests passing on that branch?
[09:41] <MacSlow> mzanetti, locally yes... on jenkins I don't know
[09:41] <mzanetti> MacSlow: ok. which branch?
[09:42] <MacSlow> mzanetti, I assume you're talking about the notify-osd/unity8 notification-service-takeover
[09:42] <MacSlow> mzanetti, it's all merged by now
[09:43] <mzanetti> MacSlow: it's merged to trunk already?
[09:43] <MacSlow> mzanetti, Saviq did that yesterday
[09:43] <mzanetti> ah. nice
[09:43]  * mzanetti triggers a few jenkins runs
[09:45] <MacSlow> 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] <MacSlow> mzanetti, so no more mass-failure should happen
[09:46] <mzanetti> MacSlow: ah I see, that wasn't in unity8
[09:46] <mzanetti> MacSlow: so I guess we still need to wait for those projects to be released
[09:46] <MacSlow> mzanetti, tested the notification-service take-over only on my desktop though
[09:46] <MacSlow> mzanetti, correct... the changed needed to happen in the notification-backend and notify-osd itself
[09:53] <Cimi> mzanetti, do we need tests here? https://code.launchpad.net/~nick-dedekind/unity8/lp1240756/+merge/192939
[09:55] <mzanetti> Cimi: hmm... not really I'd say.
[09:55] <Cimi> mzanetti, this only because I'm not the author of the branch? :D
[09:56] <mzanetti> Cimi: yeah, you got it
[09:56] <Cimi> hah
[09:56] <Cimi> :D
[09:56] <mzanetti> Cimi: no... I mean. We could test if the image is invisible when !== Ready
[09:56] <mzanetti> Cimi: but that kinda tests the Image {} itself which we assume is tested withing Qt
[09:56] <Cimi> or width of control
[09:57] <mzanetti> Cimi: actually, yeah... for the width we probably should have tests, you're right
[09:57] <Cimi> might write a test for him to safe time
[09:58] <tsdgeos> mzanetti: i made the switching previous thing crash
[09:58] <tsdgeos> but now i can't repro it
[09:58] <tsdgeos> :-(
[09:58] <Cimi> tsdgeos, on https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200
[09:58] <tsdgeos> and since somehow it seems i have the crash stuff disabled in my desktop
[09:59] <tsdgeos> i don't even have the bt  :-/
[09:59] <tsdgeos> Cimi: yes?
[10:02] <Cimi> tsdgeos, I just read the diff so I don't know the rest of the code
[10:02] <mhr3> tsdgeos, do you even have apport installed? :)
[10:02] <Cimi> tsdgeos, I was not a huge fan of setting         m_inContentHeightKeepHeaderShown = m_headerItem && m_headerItem->y() == contentY();
[10:02] <Cimi>         setContentHeight(contentHeight);
[10:02] <Cimi>         m_inContentHeightKeepHeaderShown = false;
[10:02] <tsdgeos> mhr3: i actually do :D
[10:02] <tsdgeos> Cimi: you are welcome to fix it otherwise
[10:03] <Cimi> tsdgeos, I don't know the code, I was just wondering if you had better ideas
[10:03] <tsdgeos> Cimi: if i had better ideas, i would have created a better patch
[10:03] <Cimi> fair :D
[10:04] <mhr3> tsdgeos, fwiw i just tested it, does indeed fix the header
[10:04] <tsdgeos> 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] <tsdgeos> mhr3: i don't think i see anything wrong while swiping
[10:06] <mhr3> tsdgeos, there seems to be a couple more revs, so perhaps it got fixed? :)
[10:06] <tsdgeos> mhr3: maybe, can you describe to me what it was or try it yourself?
[10:07] <mhr3> you wouldn't miss it, it was very visible and weird :)
[10:07] <mhr3> basically the previews were moving into [0,0] when you swiped
[10:09] <tsdgeos> ok
[10:10] <Cimi> tsdgeos, can you put m_headerItem && m_headerItem->y() == contentY() just in update layout?
[10:11] <Cimi> just a no is enough :)
[10:11] <Cimi> I know you worked loads on that yesterday
[10:13] <tsdgeos> Cimi: update layout == viewportMoved ?
[10:14] <Cimi> tsdgeos, yeah sorry
[10:19] <tsdgeos> Cimi: the test says i can't
[10:19] <tsdgeos> i.e. do the change you suggest and testHeaderPositionBug1240118 doesn't work anymore
[10:19] <tsdgeos> can you please confirm?
[10:22] <tsdgeos> booooo
[10:22] <tsdgeos> i knew it
[10:22] <tsdgeos> this test wasn't going to fly on the VM's
[10:34] <tsdgeos> mzanetti: you have a " print("model is", model)" in the switching previews thing
[10:34] <mzanetti> tsdgeos: that does sound like me, altough I thought I had removed them all
[10:34] <mzanetti> tsdgeos: will fix
[10:35] <tsdgeos> mzanetti: also why is onClicked now different to onPressAndHold in GenericScopeView?
[10:36] <mzanetti> tsdgeos: because we always want to show a preview onPressAndHold. and we always want to show a preview onClicked except for apps
[10:36] <tsdgeos> hmmmok
[10:37] <tsdgeos> not cool harcoding the names in there
[10:37] <tsdgeos> is that something the scopes can help us with?
[10:38] <mzanetti> tsdgeos: I had this discussion with mhr... eventually they convinced me to do it like this
[10:38] <tsdgeos> ok
[10:38] <tsdgeos> mzanetti: AlbumTile gone because noone was using it?
[10:39] <mzanetti> 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] <mzanetti> 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] <tsdgeos> ok
[10:45] <mzanetti> tsdgeos: pushed the removal of the print()
[10:47] <tsdgeos> ok
[10:49] <tsdgeos> mzanetti: looks good to me
[10:49] <tsdgeos> the lack of tests is a bit unfortunate
[10:50] <tsdgeos> is this urgent to get merged? otherwise we can wait on the tests even if they take some time, no?
[10:52] <tsdgeos> iow
[10:52] <tsdgeos> do you think there would be a benefit on getting this merged without tests?
[10:52] <tsdgeos> like getting more real life testers sooner?
[10:53] <mzanetti> 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] <mzanetti> tsdgeos: but ok. I'm finishing that albumart provider fix and then try to start getting some tests
[11:00] <tsdgeos> mzanetti: i'm ok with getting it in if it's a hassle to maintian
[11:00] <tsdgeos> now if we could get it in :D
[11:00] <mzanetti> indeed
[11:08] <tsdgeos> mzanetti: not sure i understand the first point of your comment in https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505
[11:08] <tsdgeos> when you want me to check it?
[11:09] <mzanetti> tsdgeos: the narrowMode thing?
[11:09] <tsdgeos> mzanetti: the "check for length == 1 is in the childItem assignment "
[11:10] <mzanetti> 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] <tsdgeos> yes
[11:10] <mzanetti> oh wait... I might have something overlooked... gimme a sec
[11:12] <mzanetti> 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] <mzanetti> instead of checking that each time you use it
[11:12] <mzanetti> would require to make it a real property instead of an alias tho
[11:13] <mzanetti> so has downsides too
[11:14] <tsdgeos> tbh i think it's fine as it is
[11:14] <tsdgeos> it's not like anyone's going to use it more than how we are
[11:14] <mzanetti> ok then
[11:16] <tsdgeos> mzanetti: about the "FIXME: workaround rendering issue due to use of ShaderEffectSource in"
[11:16] <tsdgeos> i have no clue what it's about tbh :D
[11:18] <tsdgeos> not sure to what it applies either :D
[11:18] <mzanetti> tsdgeos: so the UbuntuShape blocks when creating
[11:18] <mzanetti> tsdgeos: if we wouldn't use this huge cacheBuffer, lots of ubuntu shapes would be created when swiping the dash left/right
[11:19] <mzanetti> tsdgeos: which would cause stuttering
[11:19] <mzanetti> 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] <tsdgeos> tbh given we have billions of async loaders inside of async loaders
[11:21] <tsdgeos> the problem is just that UbuntuShape needs to be more performan
[11:22] <tsdgeos> :D
[11:22] <mzanetti> yeah... that's what it comes down to
[11:22] <mzanetti> and this FIXME should probably just say: "Need this huge cachebuffer because UbuntuShape is performing bad"
[11:22] <tsdgeos> otoh one wouldn't want the dash to create itself all the time either
[11:22] <tsdgeos> it's probably more battery efficient just to keep it in memory all the time
[11:22] <tsdgeos> than to waste cpu creating/decreating it
[11:22] <mzanetti> but not really memory efficient
[11:23] <tsdgeos> well, it all depends on how much memory
[11:23] <tsdgeos> but i'll trade anything for battery life :D
[11:23] <mzanetti> tsdgeos: yeah. somewhere there are numbers on how much it is
[11:24] <mzanetti> well, how much it was when I did the measurements. its quite a long time ago by now
[11:24] <mzanetti> but it was *a lot*
[11:24] <tsdgeos> 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] <tsdgeos> mzanetti: well, we did have the people scope and no delegatecreationrange for inner listviews
[11:24] <tsdgeos> so yes, i can see it was quite a lot
[11:25] <tsdgeos> 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] <tsdgeos> / TODO Investigate if we can switch to a smaller cache buffer when/if UbuntuShape gets more performant
[11:25] <tsdgeos> ?
[11:26] <mzanetti> much better, yes
[11:29] <tsdgeos> mzanetti: about the tests
[11:29] <tsdgeos> i'm not sure they make much sense tbh
[11:29] <mhr3> mzanetti, albumart provider fix?
[11:29] <mhr3> what's the issue with it?
[11:29] <tsdgeos> mzanetti: what would i be testing besides testing that the tabbar works, that should be tested by the sdk guys?
[11:30] <mzanetti> tsdgeos: I guess there's logic in unity8 which actually switches to a certain scope when clicking on a tab, no?
[11:31] <tsdgeos> onSelectedTabIndexChanged: {
[11:31] <tsdgeos>                         dashContentList.currentIndex = selectedTabIndex;
[11:31] <tsdgeos>                     }
[11:31] <tsdgeos> yep
[11:31] <mzanetti> heh, ok
[11:31] <tsdgeos> i mean i can do some tests
[11:31] <tsdgeos> but ultimately this MR has "no code"
[11:32] <tsdgeos> it's just refactoring stuff
[11:32] <tsdgeos> and adding the tabbar
[11:32] <mzanetti> tsdgeos: assuming the TabBar API changes to rename the parameter selectedIndex. this would break unnoticed.
[11:33] <mzanetti> 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] <mzanetti> 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] <tsdgeos> ok
[11:35] <tsdgeos> will do
[11:41] <MacSlow> 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] <MacSlow> mzanetti, it's a pretty handy screen-recording tool... uses gstreamer... written in Python... quite nice
[11:43] <MacSlow> it was all fine under saucy
[11:45] <tsdgeos> has a K and is not kdelibs-based? where's the world going!
[11:46] <mzanetti> :D
[11:49] <MacSlow> 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 ;)
[12:17]  * tsdgeos kicks ScopeView and GenericScopeView
[12:17] <tsdgeos> why is GenericScopeView a ScopeView
[12:17] <tsdgeos> becaue ScopeView is GenericGenericScopeView
[12:17] <tsdgeos> ...
[12:19]  * tsdgeos gets the axe ready
[12:30] <alan_g> greyback_: any chance of looking over some unity-mir MPs?
[12:31] <greyback_> alan_g: sure
[12:40] <tsdgeos> does anybody know about the search history expected behaviour on the dash?
[12:40] <tsdgeos> it seems tehre's code that tries to make it common for all the scopes
[12:40] <tsdgeos> but then there is code that fails
[12:40] <tsdgeos> so i wonder if it has to be shared or not
[12:40] <tsdgeos> mzanetti: mhr3: greyback_: all: ↑↑↑↑
[12:41] <mhr3> i think nic-doffay was trying to fix it some time ago
[12:41] <mhr3> so... he'd know :)
[12:41] <mzanetti> 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] <tsdgeos> because with my tabbar rework
[12:42] <tsdgeos> there's a single header
[12:42] <tsdgeos> and thus the history is now shared
[12:42] <tsdgeos> nic-doffay: you know?
[12:43] <greyback_> 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] <tsdgeos> well, i'll leave it like that until someone comments then :D
[12:47] <tsdgeos> will add a note to the MR too
[13:00] <nic-doffay> tsdgeos, sorry was running autopilot tests couldn't click or type :P
[13:01] <nic-doffay> tsdgeos, re that I had a branch I was working on to bring the search history out of the page header.
[13:01] <nic-doffay> 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] <nic-doffay> That's where it stands currently.
[13:15] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity8/fix-1237829/+merge/193233
[13:23] <mzanetti> pstolowski: http://i.imgur.com/LWrDtqU.png (notice something?)
[13:26] <pstolowski> mzanetti, you fixed ac/dc bug? :)
[13:26] <mzanetti> heh, yeah. feel free to review it
[13:26] <mzanetti> https://code.launchpad.net/~mzanetti/unity8/fix-1237829/+merge/193233
[13:27] <pstolowski> mzanetti, yeah, just noticed LP notification, cool :)
[13:58] <voldyman> i am writing an indicator using libappindicator3, where can i find the list of all icons available?
[14:00] <davidcalle> voldyman, have a look at http://iloveubuntu.net/icon-library-20-released-gtk3-and-python-3-support
[14:00] <voldyman> thank davidcalle
[14:00] <davidcalle> voldyman, yw
[14:20] <mzanetti> pstolowski: do you know why my home scope only shows some music in like one of 100 runs?
[14:23] <pstolowski> mzanetti, local music files? if online music - is you network connection reliable?
[14:23] <mzanetti> pstolowski: local music
[14:23] <mzanetti> pstolowski: they show up in the music scope. but I've seen it only very rarely in the home scope
[14:24] <pstolowski> mzanetti, surfacing, or in response to search?
[14:24] <mzanetti> pstolowski: surfacing
[14:24] <mzanetti> pstolowski: on the desktop that is. works fine on the phone
[14:24] <pstolowski> mzanetti, aaah
[14:27] <pstolowski> 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] <mzanetti> pstolowski: hmm... dash filters?
[14:28] <mzanetti> pstolowski: I'm still talking about unity8
[14:28] <mzanetti> and I don't run unity7 so, no, I didn't change any settings there
[14:28] <pstolowski> mzanetti, yes, but I mean filters in unity7 (because this would update settings that affect surfacing also in unity8)
[14:29] <pstolowski> mzanetti, what does 'gsettings get com.canonical.Unity.Lenses home-lens-default-view' say?
[14:29] <mzanetti> pstolowski: ['more_suggestions.scope', 'more_suggestions-amazon.scope']
[14:30] <mzanetti> this is probably still from the last time I started unity7 in quantal :D
[14:30] <pstolowski> mzanetti, ah, so that's why, it should have music.scope
[14:31] <pstolowski> mzanetti, this key controls surfacing search
[14:31] <mzanetti> pstolowski: like this? ['more_suggestions.scope', 'more_suggestions-amazon.scope', 'music.scope']
[14:31] <pstolowski> mzanetti, and it can be edited by user via filters in Home in unity7 (when search is empty)
[14:31] <tsdgeos> mzanetti: standup
[14:31] <pstolowski> mzanetti, yes
[14:32] <mzanetti> pstolowski: hmm... still doesn't show up
[14:36] <mhr3> tsdgeos, btw your header fix doesn't fix the scrolling issue
[14:36] <tsdgeos> mhr3: which scrolling issue?
[14:37] <mhr3> tsdgeos, lp:1240118 meaning if i revert r456, it's still broken
[14:37] <mhr3> tsdgeos, so i guess we should split the bug into two
[14:39] <tsdgeos> 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] <tsdgeos> and that may or may not fix the other thing
[14:39] <pstolowski> mzanetti, home scope doesn't monitor this key for changes, so you need to restart it. btw, it works here
[14:40] <tsdgeos> mhr3: so yeah you may want to split the bug
[14:40] <mhr3> tsdgeos, good, could you comment on that bug and perhaps link it?
[14:40] <mhr3> tsdgeos, did you do bzr commit with --fixes=lp:xxx ?
[14:40] <tsdgeos> nope
[14:41] <tsdgeos> never remember to do that
[14:41] <mhr3> good in this case, at least we can unlink the branch and link it to the split bug
[14:41] <mzanetti> pstolowski: yay! thanks. this works now
[14:45] <nic-doffay> mzanetti, got a moment, it's regarding another older branch.
[14:45] <nic-doffay> Looks like I'm stuck with autopilot until image 8 is sorted.
[14:45] <mzanetti> nic-doffay: sure
[14:46] <pstolowski> mzanetti, great
[14:47] <mhr3> tsdgeos, https://bugs.launchpad.net/unity8/+bug/1246351
[14:49] <tsdgeos> ok
[14:50] <tsdgeos> mhr3: thanks :-)
[15:01] <nic-doffay> mzanetti, lp:~nicolas-doffay/unity8/scope-search-refactor
[15:02] <nic-doffay> You'll see the SearchHistory has been moved out to the Dash.
[15:02] <nic-doffay> and passed through to the page header where the query is added.
[15:02] <nic-doffay> I've already confirmed the memory address of both page headers in the Dash and that in the PageHeader are the same.
[15:02] <nic-doffay> Thing is queries don't appear to be added, I have no idea why.
[15:26] <mzanetti> nic-doffay: hmm... seems to work fine here
[15:26] <mzanetti> nic-doffay: so the purpose is to have the same search history everywhere, right?
[15:31] <nic-doffay> mzanetti, that's right yeah.
[15:31] <mzanetti> nic-doffay: works here
[15:31] <nic-doffay> mzanetti, so you've tested it and it works as it should?
[15:32] <mzanetti> yeah
[15:32] <nic-doffay> mzanetti, haha well I must have missed something.
[15:32] <nic-doffay> mzanetti, in that case review?
[15:32] <mzanetti> nic-doffay: well, how do you unfocus the textfield?
[15:33] <mzanetti> 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] <nic-doffay> mzanetti, if so can you include that as a review comment?
[15:34] <nic-doffay> https://code.launchpad.net/~nicolas-doffay/unity8/scope-search-refactor/+merge/193265
[15:34] <nic-doffay> mzanetti, linking it to the bug now.
[15:34] <mzanetti> 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] <nic-doffay> mzanetti, it was a while ago I last checked. I'm going to merge trunk and test it again.
[15:35] <mzanetti> nic-doffay: ok yeah. your branch seems really old
[15:35] <nic-doffay> 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] <mzanetti> which bug?
[15:36] <mzanetti> nic-doffay: ^
[15:37] <mzanetti> nic-doffay: when you commit a bugfix, use this: bzr commit --fixes lp:123456
[15:37] <mzanetti> so the bug report will get linked to the branch
[15:37] <nic-doffay> mzanetti, cool
[15:38] <tsdgeos> booo for me
[15:38] <mzanetti> booo for tsdgeos!
[15:38] <tsdgeos> i thought this would work
[15:38] <tsdgeos> http://pastebin.kde.org/p2giuhabx
[15:38] <tsdgeos> but doesn't :-S
[15:38] <tsdgeos> and the damn qml engine doesn't tell me those ugly
[15:39] <tsdgeos> YOU ARE DEPENDING ON NON NOTIFYABLE STUFF
[15:39] <tsdgeos> it usually says when you try to do stuff like that with a non notifuable property
[15:39] <mzanetti> tsdgeos: I actually think that's QMetaObject that does
[15:40] <mzanetti> or well, something in the engine combined with the metaobject information
[15:40] <tsdgeos> ./qml/qml/qqmljavascriptexpression.cpp:254:                                   QLatin1String(" depends on non-NOTIFYable properties:");
[15:40] <mzanetti> it requires a QObject to be able to figure that out
[15:40] <tsdgeos> well, that's what you say :D
[15:41] <tsdgeos> and since it's not a qobject, it may as well assume it's non notifiable if it can do that :D
[15:41] <mzanetti> I tend to agree with that
[15:41] <mzanetti> but then, I've much too little knowledge about javascript to answer that
[15:41] <tsdgeos> same here
[15:42] <nic-doffay> mzanetti, it's working here after merging trunk.
[15:42] <mzanetti> ok... doesn't stop to get weirder
[15:43] <mzanetti> nic-doffay: anyways, please manually link the bug report with the branch. you can do that in the launchpad ui
[15:43] <mzanetti> I'll do the review soonish. need to leave for a while now
[15:43] <nic-doffay> mzanetti, I've done that.
[15:43] <nic-doffay> cool cheers
[15:43] <nic-doffay> gl with your travels.
[15:44] <mzanetti> huh?
[15:44] <mzanetti> just going for groceries and alcohol man :D
[15:44] <mzanetti> bbl
[15:49] <nic-doffay> mzanetti, haha
[15:49] <nic-doffay> That's the equivalent of travelling for me now.
[16:06] <Cimi> hey dednick
[16:06] <dednick> Cimi: hi
[16:06] <Cimi> dednick, I wanted to help you on tests for https://code.launchpad.net/~nick-dedekind/unity8/lp1240756/+merge/192939
[16:06] <Cimi> dednick, but cannot find them :)
[16:07] <Cimi> but maybe we don't need tests for that
[16:08] <dednick> Cimi: there are no indicator tests at the moment. They're in ubuntu-settings-components, but it hasn't landed yet
[16:08] <Cimi> ok
[16:08] <Cimi> so I'll approve now
[16:22] <Cimi> tsdgeos, was looking at this https://bugs.launchpad.net/unity8/+bug/1152150
[16:23] <Cimi> tsdgeos, you have any ideas out of your mind?
[16:25] <Cimi> maybe if we can detect horizontal velocity we could stop flicking the list view and switch to the other scope
[16:25] <Cimi> I'll try in 30 mins
[16:25] <tsdgeos> Cimi: that's the joy of list inside of list
[16:25] <tsdgeos> can't think of anything on top of my head
[16:25] <Cimi> I'll try
[16:31] <kgunn> Saviq: ping
[16:49] <Cimi> if you guys are bored, there are some of my branches waiting reviews
[16:50] <Cimi> https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414
[16:50] <Cimi> https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/192118
[16:50] <Cimi> https://code.launchpad.net/~cimi/unity8/remove-mathlocal/+merge/192709
[16:58] <tsdgeos> mzanetti: pushed the tests for the tabbar thing
[16:59] <Cimi> tsdgeos, so
[16:59] <Cimi> tsdgeos, horizontal velocity is 0 on vertical scoll
[16:59] <Cimi> tsdgeos, can we patch LVWPH?
[17:00] <tsdgeos> Cimi: for what exactly?
[17:00] <Cimi> tsdgeos, having horizontal velocity on a vertical scroll
[17:00] <tsdgeos> Cimi: lvwph is not the top list
[17:00] <tsdgeos> don't think that changing lvpwh will help
[17:00] <tsdgeos> or maybe it will
[17:01] <Cimi> tsdgeos, you can do something like onHorizontalVelocityChanged: if (horizontalVelocity > 2 * verticalVelocity) flick left or right
[17:01] <tsdgeos> Cimi: not sure i understand the bug at all
[17:01] <tsdgeos> it's all write in the oren-speech
[17:01] <tsdgeos> i've still not totally mastered
[17:01] <tsdgeos> Cimi: can you translate to devel-speech what's the problem?
[17:01] <Cimi> tsdgeos, it means that sometimes you want to change lens but you're stuck into the vertical scrolling of the listview
[17:01] <tsdgeos> ok
[17:02] <Cimi> tsdgeos, it depends on how you start the flick basically
[17:02] <Cimi> tsdgeos, tolerance is difficult
[17:02] <Cimi> so was thinking of detecting the horizontal speed
[17:05] <tsdgeos> Cimi: tbh LVWPH doesn't do that
[17:05] <tsdgeos> it's the flickable
[17:05] <Cimi> tsdgeos, I know
[17:05] <tsdgeos> and it won't give us the hSpeed
[17:05] <tsdgeos> since it's not hScrollable
[17:05] <Cimi> tsdgeos, but I don't know if you can get the function from it
[17:05] <Cimi> ah ok
[17:05] <Cimi> you answered
[17:06] <Cimi> tsdgeos, we can add code to calculate this
[17:06] <tsdgeos> Cimi: imho the easiest way is a separate mousearea
[17:06] <Cimi> tsdgeos, or put a mouse area
[17:06] <Cimi> tsdgeos, yeah :D
[17:06] <tsdgeos> i.e. LVPWH doesn't get any "input event"
[17:06] <tsdgeos> all it gets is
[17:06] <tsdgeos> "your viewport moved"
[17:07] <Cimi> ok
[17:07] <Cimi> tsdgeos, mouse area on top how?
[17:07] <Cimi> tsdgeos, we need not to steal events
[17:08] <tsdgeos> Cimi: you can make mousearea not steal events
[17:09] <Cimi> tsdgeos, but it usually does steal them
[17:09] <Cimi> tsdgeos, if you do onPressed it gets the event
[17:10] <Cimi> let me try
[17:10] <tsdgeos> Cimi: propagateComposedEvents ?
[17:11] <Cimi> ok
[17:23] <Cimi> it's not that simple
[17:24] <Cimi> horizontalVelocity represents only when the view moves
[17:24] <Cimi> doesn't seem the speed of the actual mouse action
[17:24] <Cimi> dandrader|lunch, ping me when you're back
[17:48] <dandrader> Cimi, ping
[17:56] <Cimi> dandrader, so we have listview that allow vertical scrolling
[17:56] <Cimi> for each scope
[17:56] <Cimi> dandrader, while we have another list view for horizontal scrolling
[17:56] <Cimi> to change lens
[17:57] <Cimi> dandrader, sometimes we start a vertical flick in a scope while we wanted to scroll left or right
[17:57] <Cimi> how would you work on it?
[17:59] <Saviq> Cimi, that's a Qt-internal thing to recognize whether something's a horizontal or vertical drag
[17:59] <Saviq> Cimi, so it requires investigation how we can influence it
[18:00] <dandrader> Cimi,  +1 on what Saviq said
[18:00] <Cimi> Saviq, well
[18:00] <Cimi> Saviq, we start the drag on LVWPH
[18:01] <Cimi> Saviq, so the mouse event is stolen from now on until the drag ends
[18:01] <Cimi> by the ScopeListView
[18:01] <Saviq> Cimi, yes, assuming the ListView doesn't take it over because it's a horizontal drag instead
[18:02] <Cimi> Saviq, it starts as a vertical drag
[18:02] <Cimi> Saviq, so the scopelistview gets it
[18:03] <Cimi> so initial condition, done properly the drag works
[18:03] <Cimi> but if you start one drag and try to change.. no way, you have to wait for the flick to end
[18:03] <Cimi> Saviq, was thinking of detecting the mouse event somehow and be able to stop a flick
[18:04] <Saviq> Cimi, that's internal Qt machinery we can't be hacking around, 'cause we'll just break something
[18:04] <Saviq> Cimi, we just need to see how we can influence that machinery
[18:06] <Cimi> Saviq, but there is no way of tell qt to scroll left if the event is already grabbed by the vertical scroll of the scope list view
[18:06] <Cimi> Saviq, what do you have in mind master?
[18:08] <Saviq> Cimi, sure, we might need to be able to - but it's not something we can do on our side, we need to investigate qt insides for that
[18:09] <Saviq> Cimi, you're talking about bug #1152150 right?
[18:09] <Cimi> Saviq, yeah boss
[18:10] <Saviq> Cimi, so yeah, we need to dig through Qt to improve that
[18:25] <dandrader> Cimi, it's a feature/good-thing that once you start a horizontal drag it can't turn into a vertical one and vice-versa
[18:25] <dandrader> Cimi, Saviq although I read somewhere that there's an Apple patent on that :)
[18:26] <Saviq> dandrader, yeah, sure, but the threshold for it being recognized as vertical or horizontal could be increased
[18:27] <dandrader> Saviq, yes, so the problem seems to be that a horizontal or vertical drag is prematurely recognized. but by reading the back log it seemed that you guys thought that the behavior I mentioned was wrong
[18:28] <dandrader> (that you cannot break the h/v flick once it starts
[18:28] <dandrader> )
[18:28] <Saviq> dandrader, no no, that's good
[18:28] <Saviq> dandrader, it's just the initial recognition that we'd like to tweak
[18:29] <Saviq> dandrader, that said, it is sometimes tricky when you have to wait for the thing to settle before being able to drag in the other direction ;)
[18:29] <dandrader> Saviq, start doing in both ways, if it settles in a horizontal or vertical direction than you lock that axis
[18:30] <dandrader> Saviq, that must be what the Apple patent is about :)
[18:30] <Saviq> dandrader, right ;)
[18:30] <dandrader> Saviq, but for that to work I suppose you would need a single entity, and not two overlapping, independent entities (ie, the hor-flickable and the vertical one)
[18:31] <Saviq> dandrader, well, not necessarily - it's basically the same maybe-gesture recognition pattern as we want for the edges
[18:32] <Saviq> dandrader, so while both say "maybe" they react, but once one says "mine", the other gets canceled
[18:32] <dandrader> Saviq, right, that might do it
[18:33] <Saviq> dandrader, but that does require digging in Qt afaict
[18:33] <dandrader> Saviq, yes
[19:08] <thomi> Saviq: it looks like I can't run the unity8 AP tests on the desktop from the source tree. Is that correct?
[19:08] <thomi> I should probably know that already...
[19:09] <Saviq> thomi, you can
[19:09] <Saviq> thomi, you need to make -C builddir install first, though
[19:09] <thomi> oh ok
[19:09] <Saviq> thomi, make -C buillddir autopilot should actually do it for you - but it will run the whole suite
[19:10] <Saviq> thomi, that's assuming you actually want to run the locally compiled version
[19:10] <Saviq> thomi, and not the system-wide installed one
[19:10] <thomi> Saviq: I did './build -s && ./build', but the AP tests look for an upstart thing?
[19:10] <thomi> yeah
[19:11] <thomi> Saviq: http://pastebin.ubuntu.com/6331713/
[19:11] <Saviq> thomi, the suite will tell you what to do with the unity8.conf file
[19:12] <Saviq> thomi, not sure what failed above :/
[21:15] <bjsnider> if an app chooses not to export the menubar, does it still work ok?
[21:33] <Cimi> Saviq, in reality would be good to break a vertical flick for a horizontal
[21:33] <Cimi> sometimes you really scroll left or right
[21:33] <Cimi> those cases I'd break and switch to horizontal
[23:59] <ali1234> tedg: in http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu/trunk.14.04/revision/355 you added a #if check for "insert"/"child-added" but you did not make the same check for "remove"/"child-removed". why?