| 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:13 |
|---|---|---|
| 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:15 |
| baron_zemo | is this possible? | 00:22 |
| baron_zemo | I've edited something similar in the cinnamon app switcher before... | 00:23 |
| 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:29 |
| 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:30 |
| 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:31 |
| baron_zemo | this: http://imgur.com/a/vqpQQ | 00:36 |
| baron_zemo | ChrisTownsend, http://imgur.com/a/vqpQQ | 00:36 |
| 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:38 |
| baron_zemo | ChrisTownsend, aw man, yeah if it's hardcoded and not a padding variable, yeah . okay thanks man. | 00:41 |
| ChrisTownsend | baron_zemo: Sorry I didn't have a better answer for you:) | 00:42 |
| 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:46 |
| ChrisTownsend | Wow...just wow. | 00:47 |
| ChrisTownsend | baron_zemo: Have you tired the Unity Tweak tool? | 00:47 |
| ChrisTownsend | Err, I mean tried. | 00:47 |
| baron_zemo | yes, unity-tweak, ubuntu-tweak, dconf-editor and myUnity and tweak-tools | 00:48 |
| 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. | 00:49 |
| === seb128_ is now known as seb128 | ||
| === duflu_ is now known as duflu | ||
| === iahmad is now known as iahmad|afk | ||
| 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:27 |
| tsdgeos | we've 18 approved reviews :D | 09:28 |
| 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:29 |
| === iahmad|afk is now known as iahmad | ||
| mzanetti | tsdgeos: FYI: CI should work again, but our AP tests are failing on trusty | 09:38 |
| 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:39 |
| tsdgeos | ookidoki | 09:40 |
| MacSlow | mzanetti, all done | 09:40 |
| mzanetti | MacSlow: ah cool. are all the tests passing on that branch? | 09:40 |
| MacSlow | mzanetti, locally yes... on jenkins I don't know | 09:41 |
| mzanetti | MacSlow: ok. which branch? | 09:41 |
| 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:42 |
| 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:43 | |
| 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:45 |
| 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:46 |
| Cimi | mzanetti, do we need tests here? https://code.launchpad.net/~nick-dedekind/unity8/lp1240756/+merge/192939 | 09:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| tsdgeos | i don't even have the bt :-/ | 09:59 |
| tsdgeos | Cimi: yes? | 09:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| tsdgeos | mhr3: i don't think i see anything wrong while swiping | 10:05 |
| 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:06 |
| 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:07 |
| tsdgeos | ok | 10:09 |
| Cimi | tsdgeos, can you put m_headerItem && m_headerItem->y() == contentY() just in update layout? | 10:10 |
| Cimi | just a no is enough :) | 10:11 |
| Cimi | I know you worked loads on that yesterday | 10:11 |
| tsdgeos | Cimi: update layout == viewportMoved ? | 10:13 |
| Cimi | tsdgeos, yeah sorry | 10:14 |
| 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:19 |
| tsdgeos | booooo | 10:22 |
| tsdgeos | i knew it | 10:22 |
| tsdgeos | this test wasn't going to fly on the VM's | 10:22 |
| 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:34 |
| tsdgeos | mzanetti: also why is onClicked now different to onPressAndHold in GenericScopeView? | 10:35 |
| 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:36 |
| tsdgeos | not cool harcoding the names in there | 10:37 |
| tsdgeos | is that something the scopes can help us with? | 10:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| tsdgeos | ok | 10:43 |
| mzanetti | tsdgeos: pushed the removal of the print() | 10:45 |
| tsdgeos | ok | 10:47 |
| tsdgeos | mzanetti: looks good to me | 10:49 |
| tsdgeos | the lack of tests is a bit unfortunate | 10:49 |
| tsdgeos | is this urgent to get merged? otherwise we can wait on the tests even if they take some time, no? | 10:50 |
| 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:52 |
| 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:53 |
| mzanetti | tsdgeos: but ok. I'm finishing that albumart provider fix and then try to start getting some tests | 10:54 |
| 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:00 |
| 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:08 |
| mzanetti | tsdgeos: the narrowMode thing? | 11:09 |
| tsdgeos | mzanetti: the "check for length == 1 is in the childItem assignment " | 11:09 |
| 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:10 |
| 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:12 |
| mzanetti | so has downsides too | 11:13 |
| 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:14 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| mzanetti | much better, yes | 11:26 |
| 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:29 |
| mzanetti | tsdgeos: I guess there's logic in unity8 which actually switches to a certain scope when clicking on a tab, no? | 11:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| tsdgeos | ok | 11:35 |
| tsdgeos | will do | 11:35 |
| MacSlow | Did anybody have any luck with using kazam to capture a screen-recording under trusty? | 11:41 |
| * mzanetti never heard of kazam before | 11:42 | |
| 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:43 |
| tsdgeos | has a K and is not kdelibs-based? where's the world going! | 11:45 |
| mzanetti | :D | 11:46 |
| === alan_g is now known as alan_g|afk | ||
| 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 ;) | 11:49 |
| === alan_g|afk is now known as alan_g | ||
| === jhodapp|afk is now known as jhodapp | ||
| * tsdgeos kicks ScopeView and GenericScopeView | 12:17 | |
| tsdgeos | why is GenericScopeView a ScopeView | 12:17 |
| tsdgeos | becaue ScopeView is GenericGenericScopeView | 12:17 |
| tsdgeos | ... | 12:17 |
| * tsdgeos gets the axe ready | 12:19 | |
| === MacSlow is now known as MacSlow|lunch | ||
| alan_g | greyback_: any chance of looking over some unity-mir MPs? | 12:30 |
| greyback_ | alan_g: sure | 12:31 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| tsdgeos | well, i'll leave it like that until someone comments then :D | 12:47 |
| tsdgeos | will add a note to the MR too | 12:47 |
| nic-doffay | tsdgeos, sorry was running autopilot tests couldn't click or type :P | 13:00 |
| 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:01 |
| mzanetti | tsdgeos: https://code.launchpad.net/~mzanetti/unity8/fix-1237829/+merge/193233 | 13:15 |
| mzanetti | pstolowski: http://i.imgur.com/LWrDtqU.png (notice something?) | 13:23 |
| 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:26 |
| pstolowski | mzanetti, yeah, just noticed LP notification, cool :) | 13:27 |
| === MacSlow|lunch is now known as MacSlow | ||
| voldyman | i am writing an indicator using libappindicator3, where can i find the list of all icons available? | 13:58 |
| 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:00 |
| mzanetti | pstolowski: do you know why my home scope only shows some music in like one of 100 runs? | 14:20 |
| 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:23 |
| 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:24 |
| 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:27 | |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| mzanetti | pstolowski: hmm... still doesn't show up | 14:32 |
| mhr3 | tsdgeos, btw your header fix doesn't fix the scrolling issue | 14:36 |
| tsdgeos | mhr3: which scrolling issue? | 14:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:45 |
| pstolowski | mzanetti, great | 14:46 |
| === dandrader is now known as dandrader|afk | ||
| === pstolowski is now known as pstolowski|bbl | ||
| mhr3 | tsdgeos, https://bugs.launchpad.net/unity8/+bug/1246351 | 14:47 |
| ubot5 | Ubuntu bug 1246351 in Unity 8 "Positioning of the Dash's header gets confused" [Medium,In progress] | 14:47 |
| tsdgeos | ok | 14:49 |
| tsdgeos | mhr3: thanks :-) | 14:50 |
| === dandrader|afk is now known as dandrader | ||
| nic-doffay | mzanetti, lp:~nicolas-doffay/unity8/scope-search-refactor | 15:01 |
| 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:02 |
| 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:26 |
| === alan_g is now known as alan_g|tea | ||
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| mzanetti | which bug? | 15:36 |
| mzanetti | nic-doffay: ^ | 15:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| nic-doffay | mzanetti, it's working here after merging trunk. | 15:42 |
| mzanetti | ok... doesn't stop to get weirder | 15:42 |
| 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:43 |
| mzanetti | huh? | 15:44 |
| mzanetti | just going for groceries and alcohol man :D | 15:44 |
| mzanetti | bbl | 15:44 |
| === alan_g|tea is now known as alan_g | ||
| nic-doffay | mzanetti, haha | 15:49 |
| nic-doffay | That's the equivalent of travelling for me now. | 15:49 |
| === jhodapp is now known as jhodapp|sick | ||
| 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:06 |
| Cimi | but maybe we don't need tests for that | 16:07 |
| 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:08 |
| Cimi | tsdgeos, was looking at this https://bugs.launchpad.net/unity8/+bug/1152150 | 16:22 |
| ubot5 | Ubuntu bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,Confirmed] | 16:23 |
| Cimi | tsdgeos, you have any ideas out of your mind? | 16:23 |
| 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:25 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | Saviq: ping | 16:31 |
| === jono is now known as Guest50058 | ||
| Cimi | if you guys are bored, there are some of my branches waiting reviews | 16:49 |
| 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 |
| === pstolowski|bbl is now known as pstolowski | ||
| Cimi | https://code.launchpad.net/~cimi/unity8/remove-mathlocal/+merge/192709 | 16:50 |
| tsdgeos | mzanetti: pushed the tests for the tabbar thing | 16:58 |
| Cimi | tsdgeos, so | 16:59 |
| Cimi | tsdgeos, horizontal velocity is 0 on vertical scoll | 16:59 |
| Cimi | tsdgeos, can we patch LVWPH? | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| 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:06 |
| Cimi | ok | 17:07 |
| Cimi | tsdgeos, mouse area on top how? | 17:07 |
| Cimi | tsdgeos, we need not to steal events | 17:07 |
| tsdgeos | Cimi: you can make mousearea not steal events | 17:08 |
| Cimi | tsdgeos, but it usually does steal them | 17:09 |
| Cimi | tsdgeos, if you do onPressed it gets the event | 17:09 |
| Cimi | let me try | 17:10 |
| tsdgeos | Cimi: propagateComposedEvents ? | 17:10 |
| Cimi | ok | 17:11 |
| Cimi | it's not that simple | 17:23 |
| 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:24 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | Cimi, ping | 17:48 |
| 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:56 |
| 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:57 |
| === alan_g is now known as alan_g|EOD | ||
| 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 | 17:59 |
| dandrader | Cimi, +1 on what Saviq said | 18:00 |
| Cimi | Saviq, well | 18:00 |
| Cimi | Saviq, we start the drag on LVWPH | 18:00 |
| 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:01 |
| Cimi | Saviq, it starts as a vertical drag | 18:02 |
| Cimi | Saviq, so the scopelistview gets it | 18:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:08 |
| Saviq | Cimi, you're talking about bug #1152150 right? | 18:09 |
| ubot5 | bug 1152150 in Unity 8 "[DASH] diagonal swipe is recognized as a scroll" [High,Confirmed] https://launchpad.net/bugs/1152150 | 18:09 |
| Cimi | Saviq, yeah boss | 18:09 |
| Saviq | Cimi, so yeah, we need to dig through Qt to improve that | 18:10 |
| 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:25 |
| Saviq | dandrader, yeah, sure, but the threshold for it being recognized as vertical or horizontal could be increased | 18:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| Saviq | dandrader, well, not necessarily - it's basically the same maybe-gesture recognition pattern as we want for the edges | 18:31 |
| 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:32 |
| Saviq | dandrader, but that does require digging in Qt afaict | 18:33 |
| dandrader | Saviq, yes | 18:33 |
| === dandrader is now known as dandrader|afk | ||
| === jono is now known as Guest21711 | ||
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| Saviq | thomi, not sure what failed above :/ | 19:12 |
| === dandrader|afk is now known as dandrader | ||
| === ChrisTownsend1 is now known as ChrisTownsend | ||
| bjsnider | if an app chooses not to export the menubar, does it still work ok? | 21:15 |
| 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 | 21:33 |
| 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? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
