[08:04] <Saviq> whoa it's quiet here today...
[08:24] <mhr3_> Saviq, what's the difference between Q_INVOKABLE and Q_SIGNAL?
[08:24] <Saviq> mhr3_, Qt deals with the function
[08:24] <Saviq> mhr3_, and I can use a SignalSpy to monitor it
[08:24] <Saviq> mhr3_, otherwise I'd need to emit myself
[08:25] <Saviq> in the test of course
[08:25] <mhr3_> Saviq, ah, so just a proper signal
[08:25] <Saviq> mhr3_, yeah yeah
[08:27] <mhr3_> Saviq, you changed pretty much everything i did for see more + header links :/
[08:27] <Saviq> mhr3_, didn't want to touch seemore qml, as it's used in previews still
[08:28] <Saviq> mhr3_, and in GSV I just did a long awaiting refactor
[08:30] <mhr3_> Saviq, btw did we decide on the interface for the thing next to departments?
[08:31] <Saviq> mhr3_, yeah, I want the same...
[08:32] <mhr3_> yey me
[08:32] <mhr3_> but yea, makes sense
[08:33] <mhr3_> Saviq, then what we're missing is interface for the no internet overlay
[08:33] <mhr3_> Saviq, and ideally also the no internet / no location info bar
[08:33] <Saviq> mhr3_, both are scope-wide are they not?
[08:33] <mhr3_> yes
[08:34] <mhr3_> well.. search-specific
[08:34] <mhr3_> but searches are tied to the scope state
[08:37] <Saviq> mhr3_, do we need the scope to be able to override the message?
[08:37] <mhr3_> hm, good question
[08:38] <mhr3_> we do not have api for it yet
[08:38] <mhr3_> scopes lib-wise
[08:38] <mhr3_> think i'd rather limit it
[08:38] <mhr3_> marcustomlinson, fyi ^
[08:40] <Saviq> mhr3_, would we ever show both location and internet bars?
[08:40] <mhr3_> Saviq, no, when you fix internet, you'll discover that you need location too :)
[08:44] <Saviq> mhr3_, so how about an enum
[08:45] <mhr3_> Saviq, sounds good to me... unless marcustomlinson says that we can't have it as enums, and will want to pass arbitrary reasons from the scopes
[08:46] <marcustomlinson> Saviq, mhr3_: an enum of possible error conditions (e.g. no internet, no location, no account info) is fine. But bare in mind these may be returned with partial results too
[08:47] <mhr3_> yea, we need two interfaces, one for the full overlay, and one for agg scopes when there's some results, but not all
[08:49] <marcustomlinson> Saviq, mhr3_: yeah, so the finished() callback will give you say: a no_internet error, but you should check if there are results in the return to decide on whether to display the full overlay or not
[08:51] <Saviq> mhr3_, marcustomlinson, hmm could we have a separate enum value for the full-screen overlay, or should I take care of it in the shell?
[08:51] <Saviq> mhr3_, marcustomlinson, can there be a location full-screen one?
[08:51] <mhr3_> Saviq, haven't seen in desin
[08:51] <mhr3_> designs*
[08:52] <marcustomlinson> Saviq, mhr3_: seems redundant. I suspect there'll be more conditions coming up in the future, and to add 2 values everytime is bit ugly
[08:52] <mhr3_> Saviq, i can easily split in into two interface in the plugin
[08:52] <Saviq> mhr3_, but maybe it makes sense if there's no results because of location either
[08:53] <Saviq> mhr3_, marcustomlinson, the only problem I can see is that if the enum value comes before results, in the UI I'd display the no-internet overlay, and then when results come I'd move it to the bar
[08:53] <Saviq> mhr3_, marcustomlinson, but then maybe I can wait for it to finish first, and only display anything afterwards
[08:54] <mhr3_> Saviq, since it will be in the finished msg, there's no way there would be more results afterwards
[08:54] <Saviq> mhr3_, ah ok
[08:54] <Saviq> mhr3_, marcustomlinson, should we maybe go for a "status" flag then
[08:55] <Saviq> future-proof, too
[08:55] <Saviq> and allowing for multiple status flags to be passed
[08:55] <mhr3_> Saviq, it's not like we needed stable api there :)
[08:56] <Saviq> we only have designs for exclusive ones now, but I can make them exclusive in the UI
[08:57] <Saviq> mhr3_, marcustomlinson, so Q_FLAGS(StatusFlags) enum StatusFlags { NoInternet, NoLocation }?
[08:57] <Saviq> and then depending on whether there's any non-empty category and display full-screen or info bar
[08:58] <Saviq> internet taking precedence
[08:58] <mhr3_> Saviq, sounds reasonable to me, though wondering if it's not too limiting when the shell has to wait for the finished
[08:59] <mhr3_> but meh, let's go with it for now
[08:59] <Saviq> we'll get the finished straight away most times won't we
[08:59] <Saviq> for empty queries at least
[09:00] <mhr3_> Saviq, might take a while when you have very bad internet
[09:00] <marcustomlinson> Saviq. mhr3_: ok so where do you want to get this status from? as a parameter in the finished() callback?
[09:01] <mhr3_> marcustomlinson, i can work with that, but if you want to pass it in another way, fine with me
[09:31] <dednick> mzanetti: howdy. did you do the spead work on the untiy8 qtmir branch?
[09:32] <mzanetti> dednick: yes
[09:32] <dednick> mzanetti: is the spread view the normal view for the apps? ie when they're flat as well?
[09:32] <mzanetti> dednick: yep
[09:34] <dednick> mzanetti: ok thanks.
[09:36] <mzanetti> dednick: any problems with that?
[09:36] <mzanetti> dednick: don't really know how the trusted session stuff will work
[09:41] <dednick> mzanetti: having some crashes, but not yet sure why. crashdump is not useful.
[10:15] <codephobic> hi
[10:17] <codephobic> I've downloaded Sublime Text 3 and want to place it in my ubuntu 14.04 filesystem so that the icons and attendant information are picked up by Unity for the launcher and the lens. Where should I be placing the files, in order to achieve that?
[11:52] <facundobatista> Holas
[11:52] <mhr3_> Saviq, is there any reason why the logo image in the header has 1gu margins?
[11:53] <mhr3_> Saviq, shouldn't all the height be available for the image?
[12:24] <Saviq> mhr3__, why would it ever use full height?
[12:59] <Saviq> elopio, I need your help!
[13:08] <mhr3__> Saviq, it probably wouldn't, but without giving the full height, the logos will look different on each device
[13:08] <Saviq> mhr3__, huh?
[13:10]  * mhr3__ thinks
[13:10] <mhr3> Saviq, ok i guess you could, but imagine that you want your logo to be exactly half the height of the header
[13:10] <Saviq> mhr3, 4GU, done
[13:11] <Saviq> mhr3, so you make your image 6gu with 1gu padding
[13:11] <mhr3> Saviq, yea, and these calculations don't seem magical to you?
[13:11] <Saviq> mhr3, no more magical than padding with 2gu
[13:12] <Saviq> mhr3, I think it's rather easy, you get 6gu height centered vertically in the header
[13:12] <mhr3> Saviq, much more magical than just positioning the image exactly in the center
[13:12] <mhr3> positioning the logo
[13:12] <Saviq> now do what you need to do
[13:12] <Saviq> mhr3, yeah, at what size?
[13:13] <mhr3> whatever you want, right, it will be scaled to fit
[13:13] <Saviq> mhr3, scaled, to what
[13:13] <mhr3> to those 8gu
[13:13] <Saviq> if it's scaled to fill the header, you get 8gu height
[13:13] <Saviq> and you can make it look real bad by actually making it reaching the edges
[13:14] <Saviq> vs. having 6gus to work with
[13:14] <Saviq> I can see no difference between saying it will be 8gu or 6gu vcentered
[13:14] <mhr3> that's scope authors problem
[13:14] <mhr3> if they want it to look bad, well... it will
[13:14] <Saviq> I see completely no difference TBH
[13:15] <Saviq> only providing a better default
[13:15] <Saviq> which 6gu is
[13:15] <Saviq> IMO
[13:15] <mhr3> i think it makes it more difficult to create the logo image
[13:16] <Saviq> mhr3, but why?
[13:17] <Saviq> mhr3, the difference is exactly that: do a 8gu high image vs. do a 6gu high image
[13:17] <Saviq> we should ask those that create that logo image maybe ;P
[13:18] <mhr3> i'm actually going to talk to joshua about it
[13:19] <Saviq> mhr3, people will be throwing in random images in there, with 1gu margins built-in, the default is acceptable in most cases, without it it won't be
[13:19] <mhr3> Saviq, and you know, he has all the headers and needs to export the logo image, it's much easier to just draw a rect around the entire header, than to subtract random amount of pixels from each side
[13:20] <Saviq> mhr3, saying "random amount of pixels" is detrimental
[13:20] <mhr3> Saviq, but that's what it is, who will know the magic 8gu const?
[13:21] <Saviq> mhr3, hopefully everyone that designs anything will
[13:21] <mhr3> maybe our designers
[13:21] <mhr3> 3rd party devs... yea... no
[13:22] <Saviq> mhr3, it would be at the expense of having a worse default, I really doubt it's so much hassle
[13:22] <Saviq> mhr3, we need to define what image is expected in $docs anyway
[13:24] <Saviq> mhr3, but yeah, it's neither of us that should decide
[13:24] <Saviq> mhr3, it's between Esti and Joshua to say what should be possible
[13:25] <mhr3> Saviq, ok, i'll go with whatever joshua says
[14:05] <Saviq> tsdgeos, this should be a 1 min for you https://code.launchpad.net/~saviq/unity8/dont-preview-in-clickscope/+merge/226638
[14:05]  * Saviq puts in a silo in the mean time
[14:07]  * tsdgeos clicks
[14:08] <tsdgeos> Saviq: hmm, is that qmluitests regressions?
[14:09] <Saviq> tsdgeos, right, they are...
[14:09] <Saviq> tsdgeos, need to switch them to a different name proberbly
[14:10] <tsdgeos> Saviq: so what happens now with non installed stuff when you click on them?
[14:10] <Saviq> tsdgeos, there is no non-installed stuff in there
[14:10] <Saviq> tsdgeos, there is only a "go to Store" button
[14:10] <tsdgeos> ah right
[14:11] <tsdgeos> forgot about that big button
[14:11] <tsdgeos> Saviq: not even in search?
[14:11] <Saviq> tsdgeos, nope, not even there
[14:11] <tsdgeos> ok
[14:15] <Saviq> tsdgeos, fix pushed
[14:15] <elopio> Saviq: I'm here.
[14:16] <elopio> how can I help you?
[14:16] <Saviq> elopio, hey, so...
[14:17] <Saviq> elopio, because of a change in delegate management in https://code.launchpad.net/~saviq/unity8/drop-filtergrid/+merge/226415
[14:17] <Saviq> elopio, we don't get all the items in the grid if they're offscreen
[14:18] <Saviq> elopio, so we need to scroll the category in question into view firsr
[14:18] <Saviq> first
[14:19] <Saviq> elopio, so I started with http://paste.ubuntu.com/7793707/
[14:19] <Saviq> elopio, but it's a little naïve...
[14:20] <Saviq> elopio, the emulator assumes the category is on screen already, otherwise _get_category_element would fail already
[14:21] <Saviq> elopio, it feels like we'd need to scroll through completely to oportunistically find the category and put it in view
[14:21] <elopio> Saviq: is the category inside a list view?
[14:22] <Saviq> elopio, it's actually inside our own custom ListViewWithPageHeader, which inherits Flickable directly
[14:23] <Saviq> elopio, but the QQuickListView emulator from UITK could potentially be abused for this, yeah
[14:24] <elopio> Saviq: probably, what we should do is to move this _find_element to the flickable, and make it public
[14:24] <elopio> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_qquicklistview.py#L52
[14:25] <elopio> in the mean time, you can copy it to your ListViewWithPageHeader. It starts swiping to top, and then swipes down one page at a time.
[14:25] <Saviq> elopio, what do I do to "register" an emulator for LVWPH?
[14:26] <elopio> Saviq: define a python class with the same name, that inherits from ubuntuuitoolkit.QQuickFlickable.
[14:27] <Saviq> elopio, should I put it somewhere special, or do you think it's good in dash.py?
[14:27] <elopio> the name of the class should be what autopilot vis shows you. Usually it's the same as the qml file name, but sometimes Qt behaves weird.
[14:28] <elopio> Saviq: at some point we need to split dash, because it's growing big. But for now, I'd put it there.
[14:28] <elopio> Saviq: but on question. We usually don't have tests with that many data, it's not common to have to swipe an entire list to get the element that we want.
[14:28] <elopio> so, is it bad to just use the naive implementation with swipe_into_view?
[14:28] <Saviq> elopio, maybe not, you tell me
[14:29] <Saviq> elopio, well, it doesn't work as-is now, 'cause it flicks
[14:29] <Saviq> elopio, and I need to make it stop (pointers btw?)
[14:29] <Saviq> elopio, but wasn't sure you'd be fine with that approach
[14:29] <Saviq> elopio, if you are, I'm game
[14:30] <elopio> Saviq: with "it flicks" do you mean that you are swiping too fast and it goes below the category that you want?
[14:33] <Saviq> elopio, yeah
[14:33] <Saviq> elopio, well, it's not even about speed, but the fact that it releases without stopping first
[14:36] <elopio> Saviq: the parent of flickable has a method called _slow_drag
[14:36] <elopio> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_flickable.py#L77
[14:36] <elopio> it works for the current cases, but yes, it probably need a better implementation.
[14:37] <elopio> you can overwrite it. However, if you try to put a sleep before releasing the finger, you will hit an autopilot bug that's on my TODO list.
[14:38] <elopio> https://bugs.launchpad.net/autopilot/+bug/1266601
[14:38] <elopio> Saviq: which test is failing for you with swipe into view? I can give it a try.
[14:38] <Saviq> elopio, the correct_applications one
[14:39]  * elopio branches.
[14:39] <elopio> Saviq: jenkins is not running that one? I see no errors on your MP executions.
[14:44] <Saviq> elopio, sorry, standup, back with you
[14:45] <Saviq> elopio, right, it fails locally for me though, most probably an off-by-1-pixel thing
[14:46] <Saviq> elopio, bascially around here the second row of items goes 1px further down than on jenkins ('cause it's scaled down here, not so on jenkins)
[14:46] <Saviq> elopio, and here the last row of delegates is not created, so test fails, 'cause can't find them
[14:46] <elopio> Saviq: this is interesting. I have the same problem on the toolkit scrolling big lists, probably because we are not taking into account the grid unit.
[14:46] <elopio> Saviq: what's your resolution?
[14:47] <Saviq> elopio, 1600x900
[14:47] <Saviq> elopio, and the problem shows up in the 1080p scenario, when it's scaled down 2x
[14:47] <Saviq> size of the window, that is
[14:47] <Saviq> and GU, too
[14:53] <elopio> Saviq: that resolution is not available with my monitor, but I can try to force the 2x scale down.
[14:53] <elopio> a couple of quick things to get the test working for you:
[14:53] <elopio> - this test originally used the category 1. tsdgeos changed it to use category 2 because now the first category of the first scope is not the grid, is the strip.
[14:53] <elopio> we use this on the click scope, that only uses the grid, so you could open the second scope on the set up of the test, and use the first category of that scope.
[14:54] <Saviq> elopio, right, that could be a quick fix indeed
[14:54] <elopio> - as it only fails on your machine for your resolution, you can ignore it for now. We have jenkins checking that it will work for the click tests, so not a big deal.
[14:55] <elopio> you can open a bug, assign it to me, and I will take care of fixing the slow swipe during the week.
[14:55] <Saviq> elopio, ok then, that works
[14:56] <Saviq> elopio, btw, you might find that interesting https://code.launchpad.net/~saviq/unity8/cmake-pydev-fixes/+merge/226416
[14:56] <Saviq> elopio, I can launch a particular test under PyDev debugging with this
[14:57] <elopio> I haven't tried pydev. I used to love eclipse in my previous live.
[14:57] <elopio> I'll give it a try.
[14:58] <Saviq> elopio, what are you using for py dev now?
[14:58] <elopio> Saviq: emacs.
[14:58] <Saviq> elopio, do you have it integrated with a step debugger of some kind?
[14:59] <elopio> Saviq: no, I just add import pdb; pdb.set_trace() when I want to break.
[15:00] <elopio> it's not too nice, but due to vila's influence, I tried to stop debugging and start writing tests when I had problems. So now I don't do it that much.
[15:00] <Saviq> :)
[15:01] <MacSlow> Saviq, btw... https://bugs.launchpad.net/unity8/+bug/1308011 ready for human-eyes.
[15:03] <Saviq> MacSlow, thanks
[15:04] <mhr3> Saviq, ehm, the header is 6.5gu, is that right?
[15:05] <mhr3> Saviq, so with the 1gu margins the image is just 4.5gu
[15:05] <Saviq> mhr3, I invented the 8gu when I talked to you, but I think it is, lemme find something with a grid
[15:06] <Saviq> mhr3, but well, same applies, Josh and Esti need to tell us what area of the header is given to scope developers to do as they please
[15:30] <mhall119> mhr3: does the scopes test tool talk directly to the scope process, or does it need to go through Unity itself?
[15:35] <Saviq> mhr3, couldn't find anything with grids, but from the redlines Josh sent me the header is 7GU, the orange tab bar overflowing it
[15:36] <Saviq> mhr3, so we should probably resolve this somehow indeed
[15:44] <mhr3> mhall119, it's direct
[15:56] <mzanetti> Saviq: did you unapprove the drop-filtergrid branch "just" because of jenkins or is there something else wring with it still?
[15:58] <mhr3> mhall119, what would make you think it needs unity? there's no unity running when you launch it
[15:59] <mhall119> mhr3: so would it be possible to compile a scope against the 14.10 API and have the scope test tool talk to it using the 14.10 API, without backporting the actual 14.10 functionality to 14.04?
[16:01] <mhr3> mhall119, ok, i see what you're asking now... the test tool itself it just using components from unity8, so it needs things like the new header that wasn't in 14.04
[16:03] <mhall119> mhr3: so what needs to be backported isn't the API, it's the components for the test tool?
[16:03] <dandrader> mzanetti, about sending keys to the focused MirSurfaceItem. is it working now?
[16:03] <dandrader> mzanetti, I saw your fix in qtmir
[16:03] <dandrader> mzanetti, wondering about unity8 changes
[16:03] <mzanetti> dandrader: I just wrapped the Surface in a FocusScope and call forceActiveFocus () on it when it gets focused
[16:04] <dandrader> mzanetti, but what about sending keys to *both* the focused MirSurfaceItem and to the VolumeControl in Shell.qml?
[16:05] <mzanetti> dandrader: it's not both... but from my testing that's actually much better...
[16:05] <mhr3> mhall119, well both, but building the api itself is trivial in T, building part of u8 that uses new sdk, where naming of half of the qml pkgs changed after 14.04... not so much
[16:06] <dandrader> mzanetti, I thought we would need to send keys to both...
[16:06] <mhall119> mhr3: would it be worth doing that work so we can support scope developers on 14.04 better?
[16:06] <mzanetti> dandrader: well, we had both before, and we "broke" it for apps with QtComp so I thought the easier way would be to just inject it again into both to have it at least working
[16:06] <mzanetti> dandrader: but turns out, this is actually the correct solution and it just works :)
[16:07] <dandrader> mzanetti, well. that
[16:07] <dandrader> that's nice when it just works :)
[16:07] <elopio> ping Saviq: I need your help to get reviews for my branches: https://code.launchpad.net/~elopio/unity8/
[16:07] <mhr3> mhall119, the question is - is it feasible
[16:07] <elopio> well, except the precommit one. I need to apply your suggestions there.
[16:07] <dandrader> mzanetti, another thing on the same subject: why do we need to wrap the surface in a FocusScope?
[16:08] <mhall119> mhr3: is it feasible?
[16:08] <mhr3> mhall119, apps already made the decision that it isn't, no?
[16:08] <mzanetti> dandrader: Hmm... We could try to remove that again... I had the impression that it didn't really work without it, but when I tested there still was an issue in qtmir...
[16:09] <mzanetti> dandrader: so it might not be required after all
[16:09] <mhall119> mhr3: we can still develop apps against 14.04 because not that much has changed
[16:10] <mhr3> mhall119, so you can take advantage of everything with 14.04 sdk? like the bottom swipe, and new header
[16:11] <mhall119> yes
[16:11] <mhr3> then apps are apparently further than scopes
[16:17] <mhall119> they are, yes
[16:18] <mhall119> we did run into a similar problem early on in app development, but back then bzoltan's team was backporting all of the SDK, including Qt, to older stable releases of Ubuntu
[16:25] <mhr3> Saviq, where there any changes to the customizations?
[16:25] <mhr3> Saviq, i'll update the docs and mention there everything we defined in the json doc
[16:54] <karni> Saviq: Do you know if I can disable the blue highlight if there are links in a Preview Text widget?
[17:19] <greyback> mterry: hey, you know a nice way I can test the lockscreen?
[17:20] <mterry> greyback, I'm building the branches in a PPA as we speak
[17:20] <mterry> greyback, silo 004
[17:21] <greyback> mterry: but how can I test it now? I just want to enable things to when I turn on my phone & must enter a pin/passcode
[17:22] <mterry> greyback, you can test the current demo version of it by editing /home/phablet/.unity8-greeter-demo and making it look like:
[17:22] <mterry> [phablet]
[17:22] <mterry> password=pin
[17:22] <mterry> passwordValue=1234
[17:22] <greyback> mterry: perfect, thank you
[18:11] <Saviq> elopio, we'll try and get those done asap, we
[18:11] <Saviq> 're a bit crammed for reviews right now :|
[18:12] <Saviq> karni, they shouldn't be there, must be we've not disabled rich text in there
[18:12] <Saviq> karni, are the links in <a> in there or url in plain text?
[18:15] <cwayne> i think he's gone, but I believe they're in <a> tags Saviq
[18:16] <Saviq> cwayne, right, we'll have to disable those
[18:17] <cwayne> Saviq: hm, fair enough, though I know victor's been using rich text as a way to better control formatting in text/title widgets
[18:17] <Saviq> cwayne, the dash toolkit design does not allow that, though...
[18:18] <Saviq> cwayne, we'll probably have to discuss exceptions and apply a whitelist on html tags
[18:19] <cwayne> Saviq: fair enough, I think the bug victor was working around is here: https://bugs.launchpad.net/savilerow/+bug/1328513
[18:19] <cwayne> I guess just make sure that's fixed before we disable rich text, for minimal victor pushback :)
[18:20] <Saviq> cwayne, yeah, will just drop the text size back to what's in the Card, that was old design where this was different
[18:23] <cwayne> Saviq: makes sense to me