[07:51] <tsdgeos> pete-woods: ping
[07:51] <pete-woods> tsdgeos: hi
[07:51] <tsdgeos> pete-woods: for usermetrics
[07:52] <tsdgeos> where's UseXGettext ?
[07:52] <pete-woods> tsdgeos: cmake-extras
[07:53] <tsdgeos> oh that name is going to be confusing with extra-cmake-modules :D
[07:54] <tsdgeos> pete-woods: setLabel(_(GETTEXT_PACKAGE, "No data sources available")); does not end up in the .pot
[07:54] <tsdgeos> which makes the very first thing i see on the phone untranslatable
[07:56] <pete-woods> tsdgeos: it's in there. for some reason just not in trunk?...
[07:56] <tsdgeos> well, should be in trunk if we want people to translate it, no?
[07:58] <pete-woods> tsdgeos: sure, trying to figure out what's going on
[08:03] <tsdgeos> Mirv: has there been any recent patch to qtdeclarative? i am getting a pretty consistent crash i didn't use to
[08:08] <pete-woods> tsdgeos: okay. I've sorted out my own stupidity now
[08:08] <pete-woods> going to have to make another landing
[08:08] <tsdgeos> cool, tx
[08:11] <pete-woods> tsdgeos: https://code.launchpad.net/~unity-api-team/libusermetrics/extract-all-translations/+merge/234773
[08:11] <pete-woods> there's the branch, if that helps
[08:12] <Mirv> tsdgeos: https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+changelog (the last one not yet in rtm)
[08:13] <tsdgeos> Mirv: ok, tx
[08:13] <tsdgeos> pete-woods: nice :)
[08:29] <tsdgeos> Mirv: i'm going to need https://codereview.qt-project.org/#/c/87700/ in
[08:30] <tsdgeos> Mirv: it's a two lines patch that is already in 5.3
[08:30] <tsdgeos> Mirv: how do we proceed?
[08:31] <Mirv> tsdgeos: file a LP bug, check that it applies against our 5.3.0 package, I'll take it from there
[08:31] <tsdgeos> ok, tx
[08:36] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1369930
[08:37] <Mirv> tsdgeos: thanks, I'll start preparing it
[08:37] <tsdgeos> awesomeness
[09:26] <tsdgeos> pstolowski: so what's exactly the UI that you guys thought for that resultsEnabled?
[09:28] <mzanetti> greyback__: good morning. trying to land your branches: please resolve the conflict here: https://code.launchpad.net/~gerboland/qtmir/exposeOrientation/+merge/232485
[09:28] <mzanetti> greyback__: and please reapprove this one after I merged conflicts: https://code.launchpad.net/~mzanetti/unity8/focus-first-if-running-at-startup/+merge/234778
[09:29] <pstolowski> tsdgeos, i only heard a rough idea to dim/blur them, Saviq and thostr would know, but both are not available :/
[09:32] <tsdgeos> pstolowski: :/
[09:33] <greyback__> mzanetti: https://code.launchpad.net/~mzanetti/unity8/focus-first-if-running-at-startup/+merge/234778 missing commit message
[09:33] <mzanetti> greyback__: good catch. fixed
[09:34] <greyback__> mzanetti: approved
[09:34] <mzanetti> thanks
[09:35] <greyback__> mzanetti: and expose-orientation conflicts fixed
[09:36] <mzanetti> greyback__: awesome. thanks
[09:38] <tsdgeos> pstolowski:  lp:~aacid/unity8/results-enabled-flag give it a try
[09:39] <pstolowski> tsdgeos, thanks, doing
[10:24] <tsdgeos> @unity: anyone knwos what's going on with the autopilot tests?
[10:30] <pstolowski> tsdgeos, your branch works fine, but i think we need to think about how to indicate the 'disabled' state
[10:31] <tsdgeos> yeah
[10:31] <pstolowski> tsdgeos, e.g. entire screen is grayed out, but it looks weird since you can still type into the search box
[10:32] <pstolowski> tsdgeos, also, when search results arrive immediately (usually the case for local scopes), they're grayed out for just a blink of an eye
[10:32] <tsdgeos> that too
[10:32] <pstolowski> tsdgeos, i think it would look much better if only the icons where greyed out, not entire dash
[10:33] <pstolowski> tsdgeos, but, i think somebody else needs to decide ;)
[10:33] <tsdgeos> that's why the orange line has "make it last longer than it really is"
[10:33] <tsdgeos> not to look horribly broken
[10:33] <tsdgeos> pstolowski: agreed, now go on and find who that somebody is :D
[10:33] <pstolowski> :D
[10:33] <mzanetti> tsdgeos: what up with AP tests?
[10:34] <pstolowski> tsdgeos, who is the best contact in design these days?..
[10:34] <mzanetti> tsdgeos: yesterday I had a run and they were passing fine
[10:34] <tsdgeos> mzanetti: they seem to be failing in places that don't make sense given the changes in the branc
[10:34] <tsdgeos> h
[10:35] <tsdgeos> like
[10:35] <tsdgeos> ERROR: unity8.shell.tests.test_lock_screen.TestLockscreen.test_can_unlock_pin_screen(Native Device)
[10:35] <tsdgeos> in https://code.launchpad.net/~marcustomlinson/unity8/handle_null_preview/+merge/234054
[10:35] <tsdgeos> pstolowski: don't know :/
[10:40] <tsdgeos> JMulholland: hi ho, i've been told you're our new Dash guide nowadays
[10:40] <tsdgeos> JMulholland: pstolowski and me have some questions, have a minute?
[10:47] <Cimi> tsdgeos, I had several chats with him, what do you need to know?
[10:47] <tsdgeos> Cimi: ↑↑↑
[10:47] <tsdgeos> basically there seems to be a desire to dim the dash while searchs are running
[10:47] <pstolowski> Cimi, we need to disable & dim/blur/whatever search results while search is in progress
[10:48] <pstolowski> Cimi, so we're interested in knowing what will be the desired effect from design pov
[10:48] <Cimi> we did not have the pulsing bar at the bottom to indicate search?
[10:48] <tsdgeos> we do
[10:48] <tsdgeos> that's a different thing
[10:48] <tsdgeos> let's say complementary
[10:49] <tsdgeos> not totally different
[10:49] <pstolowski> Cimi, yes, this indicates search in progress. but till now we were clearing all results almosst immdiately. from now on we will keep old results displayed until new ones arrive
[10:49] <Cimi> pstolowski, so if I search house, i clear and I search dog, house will be shown while dog search is in progress?
[10:50] <pstolowski> Cimi, yes, till at least a single result arrives. and old results will get disabled in the meantime
[10:50] <pstolowski> Cimi, no wait
[10:50] <Cimi> pstolowski, I think we should clear them
[10:51] <pstolowski> Cimi, when you're removing characters, it's new search every time
[10:51] <Cimi> ah ok
[10:51] <Cimi> pstolowski, so if I add a search term
[10:51] <Cimi> house london
[10:51] <Cimi> I will still see results for house while is searching london?
[10:52] <Cimi> searching "house london"
[10:52] <pstolowski> yes, but they will get disabled and dimmed, and we will clear and replace them when 1st result for full phrase arrives. the idea is to minimize the time you see completely empty dash while search is in progress
[10:53] <pstolowski> Cimi, currently we clear almost immediately as you type (after 240 ms afair)
[10:54] <tsdgeos> Cimi: some pixel pushing that has high priority https://code.launchpad.net/~aacid/unity8/bug1365929/+merge/234795
[10:56] <Cimi> pstolowski, basically ytour idea is to make them desaturated and half opaque?
[10:56] <Cimi> pstolowski, why do we need to dim and disable them?
[10:57] <Cimi> I would just leave them personally, with the pulsing progressbar at the bottom
[10:58] <pstolowski> Cimi, disable, so that user cannot click them anymore. and btw, it's not my idea ;) Saviq and thostr agreed on the general concept shortly before leaving for vacation ;)
[10:58] <Cimi> the user has a glance that something is going on, as well as ability to open a previous result and cancel the search in case he decides to tap on one of the previous
[10:58] <Cimi> pstolowski, why the user should not click on them?
[10:59] <pstolowski> Cimi, there is no strong reason to disable, except for, suddenly you can click wrong item when new ones replace old ones
[11:00] <Cimi> pstolowski, so we should dim out only before the results are coming in
[11:01] <Cimi> pstolowski, imagine you searching on google and everything disables as you type
[11:01] <pstolowski> Cimi, yes, that's the plan (sorry if my earlier explanation was chaotic); you type -> current (old) results get dimmed -> 1st result arrive and we clear old ones + new results are enabled
[11:02] <Cimi> pstolowski, I meant, current ones should not get dimmed
[11:02] <Cimi> pstolowski, they should get dimmed when new results are enabled
[11:03] <Cimi> pstolowski, we have 1 problem we want to fix: user tapping an old result when a new one is just about to being displayed, is like a race condition
[11:03] <pstolowski> Cimi, that's not possible ;), you either have old results, or new, not both
[11:03] <Cimi> pstolowski, disabling everything sounds like a brutal solution that does not aim at the issue but affects the rest of the experience
[11:04] <pstolowski> Cimi, hmm, i disagree, it's better than removing everything on every letter you type as we do now
[11:04] <Cimi> pstolowski, I think one better solution, for example, could be dimming the results coming in, with a small transition
[11:04] <Cimi> instead dimming old
[11:05] <Cimi> we want to block people from running "new" results
[11:05] <Cimi> not from opening old ones
[11:06] <Cimi> current issue we have on the desktop, for example, I type fire (for firefox) and I want to click on firefox but a new item comes in and I open that by mistake
[11:06] <Cimi> I think the new results should fade in, rather than old ones (old ones are still valid, in fact)
[11:13] <pstolowski> Cimi, the scenario you describe doesn't apply to the new architecture; in unity7 we were diffing result sets and did other crazy stuff the could result in some late items pushed before already displayed one. now we only append (this accounts for both categories and individual results)
[11:13] <Cimi> tsdgeos, what you think?
[11:14] <Cimi> pstolowski, even if does not apply to the architecture, still completely fixes the problem
[11:14] <Cimi> pstolowski, type cal, calendar and calculator appear on screen
[11:15] <Cimi> we don't know if user wants to tap one of the other
[11:16] <Cimi> so we leave those on screen
[11:16] <Cimi> then the user adds a letter, and while is searching realises he wants to open calendar because he sees it, he is satisfied and just wants to run that
[11:17] <Cimi> he can tap and the app opens
[11:17] <tsdgeos> Cimi: don't know tbh what i prefer
[11:17] <tsdgeos> not the design type myself :D
[11:18] <Cimi> this is the scenario, and as we said can be problematic if results change while user is moving the finger towards the screen (is like a race condition)
[11:18] <Cimi> so what we do, we make those results fade in/as a transition
[11:18] <Cimi> so the user will never fall in the situation of tapping something he does not want
[11:19] <pstolowski> Cimi, well, as tsdgeos says.. i like how it works with current branch from tsdgeos (minus the actual effect of dimming of entire screen), design needs to speak up ;)
[11:19] <tsdgeos> Cimi: i don't see how fadein/out is going to make the user never make a mistake
[11:19] <pstolowski> exactly
[11:19] <Cimi> tsdgeos, fade in new results
[11:20] <Cimi> not fade out old
[11:20] <pstolowski> Cimi, perhaps you want to give it a shot?
[11:20] <Cimi> pstolowski, what?
[11:20] <tsdgeos> Cimi: we're not fading in/out anything
[11:20] <tsdgeos> we're just dimming them
[11:20] <Cimi> dimming
[11:20] <Cimi> yeah
[11:21] <Cimi> tsdgeos, we are disabling them, right?
[11:21] <tsdgeos> i'm just adding a huge black 0.7 overlay on top
[11:21] <facundobatista> Holas
[11:21] <Cimi> tsdgeos, are they clickable?
[11:21] <tsdgeos> no
[11:21] <Cimi> tsdgeos, this is the issue
[11:21] <tsdgeos> what would be the point if they were clickable?
[11:21] <Cimi> tsdgeos, they are not
[11:21] <Cimi> tsdgeos, they should be
[11:21] <Cimi> in my opinion
[11:21] <tsdgeos> that's what *you* say
[11:22] <tsdgeos> and that's why we have deisgn people
[11:22] <Cimi> tsdgeos, yes
[11:22] <tsdgeos> that maybe will answer the question before the next decade
[11:22] <pstolowski> :)
[11:22] <tsdgeos> if they get to listen to irc
[11:22] <tsdgeos> instead of just be on ir
[11:22] <tsdgeos> -r+t
[11:22] <Cimi> tsdgeos, so imagine I am looking for "weather las palmas gran canaria"
[11:23] <tsdgeos> Cimi: you don't have to convince me, you have to convince JMulholland
[11:23] <Cimi> tsdgeos, as soon as I typed "weather las", the correct result is already there
[11:23] <pstolowski> Cimi, we've branches ready that implement that
[11:23] <Cimi> why on earth would I need to block the entire ui, if the result is ready, until all the other words are processed?
[11:24] <Cimi> I will ask James :)
[11:24] <Cimi> and tell him my idea
[11:24] <tsdgeos> Cimi: that's nto the situation as i understand it anyway
[11:25] <tsdgeos> unless you are ultra slow when typing
[11:25] <Cimi> (which I just noticed is exactly how it works on other search engines)
[11:31] <Cimi> tsdgeos, pstolowski going tomorrow to the office, I'll sort this out
[11:31] <pstolowski> i'm not sure if transition is an answer, since we do search with practically every letter you type
[11:31] <Cimi> pstolowski, do you have an android phone?
[11:32] <pstolowski> Cimi, ok, but please give it a shot before that, because i think it's not as bad as you think it is; in fact i think it works quite nicely with slow scopes (such as wikipedia)
[11:32] <pstolowski> Cimi, i've nexus4
[11:32] <pstolowski> Cimi, ah, android, yeah, sure
[11:32] <Cimi> pstolowski, you can try doing a google search, and see is also nice being able to tap results while search is in progress
[11:33] <Cimi> pstolowski, I am not saying is bad, I am saying that probably we can think of something better
[11:33] <Cimi> pstolowski, the UX problem is that we can tap new results that are popping in, and we did not see them
[11:34] <Cimi> pstolowski, so I would work on this side of the problem
[11:35] <tsdgeos> MacSlow|lunch: does unity8.shell.tests.test_notifications.EphemeralNotificationsTests.test_append_hint pass for you on the PC
[11:35] <tsdgeos> ?
[11:36] <pstolowski> Cimi, ok, but keep in mind that we currently have a single model for results, so if you want to do a transition that needs two models (old results, new results), then this is potentially too big undertaking and refactoring at this point imho
[11:37] <Cimi> pstolowski, the old results just disappear instantenuously
[11:37] <Cimi> pstolowski, the new results are not clickable for (for example) 100 ms
[11:38] <Cimi> eventually we can think of animating those 100ms
[11:39] <Cimi> but this is my idea, tomorrow I will ask james about it
[11:39] <tsdgeos> marcustomlinson: found a problem with your branch
[11:39] <pstolowski> Cimi, ah, ok, thanks
[11:39] <marcustomlinson> tsdgeos: what did I do?
[11:39] <tsdgeos> mzanetti: do autopilot tests work for you on the desktop? or you test only on the phone?
[11:39] <tsdgeos> marcustomlinson: broke previews in dash overview
[11:40] <mzanetti> tsdgeos: I only tried on the phone
[11:44] <MacSlow> tsdgeos, that ap-test should no longer be in lp:unity8
[11:44] <MacSlow> tsdgeos, Design wanted me to can the whole append-feature
[11:46] <MacSlow> tsdgeos, phew... it is no longer part of lp:unity8
[11:46] <MacSlow> tsdgeos, what branch are you checking?
[11:46] <tsdgeos> MacSlow: marcustomlinson's
[11:46] <tsdgeos> marcustomlinson: can you merge trunk?
[11:47] <marcustomlinson> tsdgeos: k
[11:47] <pstolowski> Cimi, btw pls keep in mind that this is contradicting what Saviq requested, which is not to clear current (old) results immediately on new search
[11:47] <MacSlow> tsdgeos, marcustomlinson: handle_null_preview ?
[11:48] <Cimi> pstolowski, what is contracticting?
[11:48] <tsdgeos> MacSlow: yep
[11:49] <marcustomlinson> tsdgeos: k, merged and pushed
[11:49] <pstolowski> Cimi, "the old results just disappear instantenuously"
[11:49] <Cimi> pstolowski, when new results pop in
[11:49] <Cimi> pstolowski, or we can just keep them if they are appended
[11:50] <tsdgeos> marcustomlinson: let's see if that fixes the autopilot tests, don't forget about the overview thing though
[11:50] <Cimi> pstolowski, I understood the model gets cleared
[11:51] <Cimi> pstolowski, add a "when the first new result becomes available"
[11:51] <Cimi> the old results just disappear instantenuously when the first new result becomes available
[11:51] <Cimi> the new results are not clickable for (for example) 100 ms
[11:51] <pstolowski> Cimi, ah, yes, the old results disappear immediately when new ones pop in - this makes perfect sense
[11:51] <pstolowski> Cimi, ok, and then if you disable tap for a short period you cannot click wrong item
[11:51] <pstolowski> makes sense
[11:52] <Cimi> pstolowski, I could have explained myself better
[11:52] <Cimi> via chat is hard
[11:52] <Cimi> I think is a better solution
[11:53] <Cimi> keeps dash responsive all the time, does not clutter visuals with elements getting darkened and such
[11:53] <Cimi> while still fixing the issue of wrong taps
[12:09] <Cimi> is run.sh broken?
[12:09] <Cimi> for unity
[12:09] <Cimi> runs the wizard hre
[12:15] <MacSlow> Cimi, trunk still worked for me earlier today
[12:18] <cwayne> mzanetti: ping
[12:18] <mzanetti> cwayne: hey
[12:19] <cwayne> mzanetti: hey, was wondering if we had any idea when https://code.launchpad.net/~unity-team/unity8/card-visual-tweaks might be landing?
[12:21] <mzanetti> cwayne: hmm... it still has to be reviewed. not on the landing list for the next 2 batches
[12:21] <mzanetti> cwayne: also the last comment in there says "Changing to WiP until all the scopes get updated."
[12:21] <mzanetti> alecu: hey, can you explain what this means? ^
[12:22] <mzanetti> i.e. which branches need to land first
[12:22] <cwayne> hm, the bug i wanted it to fix doesnt even appear there anymore.. https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1356371
[12:34] <alecu> mzanetti: yes: with that branch (card-visual-tweaks) all the titles of results will be left-aligned, as it's the default in the spec. Many scopes need the titles to be centered and those are the scopes that will need to be updated.
[12:34] <alecu> cwayne: ^
[12:34] <mzanetti> alecu: thanks
[12:34] <alecu> np
[13:07] <tsdgeos> pete-woods: ping
[13:07] <pete-woods> tsdgeos: hi
[13:07] <tsdgeos> pstolowski: or you actually
[13:07] <pete-woods> :)
[13:07] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1365041 is fixed now, right?
[13:08] <pete-woods> tsdgeos: correct
[13:08] <tsdgeos> ok, marked all as released
[13:08] <pete-woods> cool
[13:08] <pstolowski> yep
[13:09]  * pete-woods getting tired of making things released now. why did LP stop doing it
[13:22] <michael-vb> Hello.  Do developers read this channel?
[13:23] <tsdgeos> for some value of developers
[13:23] <tsdgeos> yes
[13:24] <michael-vb> I was wanting to ping someone about LP 1353675.  It is basically a place in your code where you call an (x, y, w, h) API with (x1, x2, y1, y2) data, which messes up multi-monitor full-screen in VirtualBox.
[13:26] <michael-vb> Is this the right place for that sort of thing?
[13:28] <tsdgeos> may be, though it's more frequented by unity8 developers than by compiz/unity7 developers
[13:30] <michael-vb> Ah right.  Any suggestions as to better places?  It should be pretty quick to fix, though no idea how fast that sort of fix propagates in Ubuntu.
[13:30] <tsdgeos> michael-vb: if you really know what is the line that needs to be fixed
[13:31] <tsdgeos> you can always create a merge request in launchpad
[13:31] <tsdgeos> that probably helps
[13:31] <tsdgeos> then #ubuntu-desktop may help too (or not)
[13:31] <michael-vb> Is there any documentation about merge requests?  I'm not familiar with your work-flow.
[13:32] <tsdgeos> i guess there is, i don't know where tbh
[13:33] <tsdgeos> in short is bzr branch lp:project, code, bzr push lp:~myuser/project/somename, then go to launchpad ui and request a merge
[13:34] <michael-vb> Thanks, I will try that.
[14:13] <alecu> dednick: hi! I'm still seeing weird behavior on apps being run in a trusted prompt session. I've got this two bugs for the pay-ui that really can't be happening due to the code in pay-ui: https://bugs.launchpad.net/pay-ui/+bug/1366942 and https://bugs.launchpad.net/pay-ui/+bug/1366771
[14:16] <dednick> alecu: is the payment ui transparent?
[14:19] <dednick> alecu: http://bazaar.launchpad.net/~unity-api-team/pay-ui/first-branch/view/head:/app/payui.qml#L60
[14:20] <alecu> dednick: only the first screen has some transparency, yes. Then there's a flow between a few screens without transparency, then there's one screen with an embeded html in oxide, and when getting back to the screens without transparency there's the issue.
[14:22] <dednick> alecu: https://launchpadlibrarian.net/184337720/payui-error.png looks like it has a transparent background.
[14:22] <dednick> pay-ui (with transparent background) overlayed on the dash
[14:26] <dednick> alecu: and i have no idea how the theme determination will respond to transparent background.
[14:27] <dednick> alecu: which is probably why the text is white
[14:28] <alecu> dednick: the weird thing is that the same screen is shown before, and it looks just right
[14:29] <alecu> only when adding a new credit card does the display start to look jumbled.
[14:29] <dednick> alecu: let me try give it a run. i've never actua;;y done it before
[14:29] <alecu> dednick: thanks
[14:30] <cwayne> mzanetti: so back to the card-visual-tweaks.. is there any chance to bump it in terms of priority (i understand we've have to changes the scopes that want to have centered titles first), we're really struggling with this bug: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1356371
[14:32] <mzanetti> cwayne: I don't really know who needs to change the scopes
[14:33] <alecu> mzanetti: I can do it for the click one :-)
[14:33] <mzanetti> alecu: ok. do you know which other scopes are affected?
[14:39] <cwayne> or is it possible to split out just the emblem bits into a separate MP?
[14:39] <alecu> mzanetti: I don't really know which other scopes need that, sorry
[14:40] <mzanetti> ok
[14:41] <mzanetti> tsdgeos: hey, do you know more things about this? https://code.launchpad.net/~unity-team/unity8/card-visual-tweaks
[14:41] <tsdgeos> mzanetti: not really
[14:42] <tsdgeos> mzanetti: not sure what "all scopes are updated means"
[14:42] <tsdgeos> maybe cwayne knows?
[14:43] <tsdgeos> or alecu?
[14:43] <alecu> mzanetti: I just checked all the preinstalled scopes on my phone, and the only ones that shows centered titles are Wikipedia and Installed Apps.
[14:43] <mzanetti> no,, both don'
[14:43] <mzanetti> t
[14:43] <mzanetti> ah
[14:43] <alecu> mzanetti: but that's the main screens, I don't know if they show centered titles in other pages inside the scope.
[14:43] <mzanetti> I see
[14:43] <mzanetti> well, lets do this:
[14:44] <mzanetti> alecu: please update the click scope when possible and review the branch (seeing you're there as a requested reviewer)
[14:44] <mzanetti> I'll try to chase down other affected scopes
[15:13] <dednick> alecu: hm. i added the delta app, now i can't purchase anything anymore :(
[15:13] <alecu> dednick: in staging there's "qr codes", "tv stalker" and "evil app" with prices
[15:14] <dednick> alecu: ah.  ta. anyway i can "unbuy"?
[15:15] <alecu> dednick: we have to ask the server folk to remove the purchases from their dbs
[15:16] <alecu> dednick: or, create a new user in staging
[15:17] <alecu> dednick: were you able to reproduce the glitches when adding credit cards?
[15:18] <alecu> dednick: you don't really need to complete every step on the test plan, only adding two or more credit cards triggers it somehow.
[15:22] <anpok> hm is there a way to mock methods with qts testing framework?
[15:29] <dednick> alecu: i've removed the transparency and it seems to work..
[15:30] <dednick> alecu: i think there must be something funky happening in the theming
[15:30] <dednick> when you change the background
[15:31] <alecu> dednick: weird. What I still don't understand, is why that page is shown fine before adding a credit card, and then shown wrong after the card is added.
[15:32]  * alecu checks the code again
[15:33] <dednick> alecu: it's possibly not to do with your code. might be inheriting backgrounds and something getting screwed in sdk.
[15:34] <alecu> dednick: one question: when you removed the transparency... did the issue with the arrows and checkmarks in the combo got solved too?
[15:35] <dednick> alecu: erm. dunno
[15:35] <alecu> dednick: nevermind, I can try it.
[15:38] <dednick> alecu: hm. i can't seem to select another credit card
[15:39] <alecu> dednick: well, actually the card is selected, but the checkmark nor the chevron nor the selection highlight are shown
[15:39] <dednick> alecu: it doesn't go away from the previously selected one.
[15:39] <alecu> dednick: try tapping on "paypal" and then moving forward with the purchase
[15:39] <dednick> no visual feedback
[15:39] <alecu> right
[15:40] <alecu> dednick: I check that those combos (the qml OptionSelectors ) are working fine outside the trusted prompts
[15:41] <alecu> dednick: that is, when starting an app normally
[15:41] <alecu> * I've checked
[15:42] <dednick> alecu: when starting payment-ui outside? or other apps?
[15:42] <dednick> everything else seems to be getting feedback
[15:42] <dednick> buttons i mean
[15:43] <alecu> dednick: that would be the same combos in other apps; I can find out how to start pay-ui outside the prompt
[15:43] <alecu> (I've only got dragged into this last week, so I'm not very familiar with the innards of pay-ui)
[15:45] <dednick> it doesn't look like there's anything special in there that could stop it working :/
[17:24] <bregma> mzanetti, your launcher items schema key MP has landed in the Ubuntu archives
[17:24] <mzanetti> bregma: nice. thanks!
[18:04] <yecril71pl> Is there a dash scope for info:?