[07:57] <tsdgeos> damnit
[07:58] <tsdgeos> am i the only one with the spam folder full of bugreports/merge reviews?
[07:58] <Saviq> tsdgeos, I didn't switch to GMail, so... ;)
[07:59] <Saviq> brb
[08:33] <Saviq> didrocks, hey, if mir broke ABI, but unity-mir doesn't care (i.e. just needs a no-change rebuild) - how do we tackle such?
[08:37] <xnox> Saviq: you need to add versioned depends, because people can upgrade unity-mir / mir out of order.
[08:38] <xnox> Saviq: and thus bump packaging/version of unity-mir.
[08:40] <Saviq> xnox, right, so when mir is released with the new version, we need to bump our >= regardless of the fact that we don't really depend on it :/
[08:41] <xnox> Saviq: "don't really depend on it" you don't link against it? just reuse it's e.g. c++ templates?
[08:41] <Saviq> xnox, no no, we link
[08:41] <Saviq> xnox, but don't really care about the new version
[08:41] <Saviq> xnox, but I understand we can't rebuild a same-version unity-mir just to go with the new ABI
[08:42] <xnox> Saviq: oh, then you do depend on it =) and broken ABI can give you horrible & confusing crash-reports =)
[08:42] <Saviq> xnox, although... they're bumping SONAME, too
[08:42] <Saviq> xnox, i.e. I don't think there was a *release* of mir with broken ABI
[08:42] <xnox> Saviq: right, one cannot have same version number for two different packags =)
[08:43] <xnox> (in official archive, in PPAs one can delete/reupload)
[08:43] <Saviq> xnox, so since unity-mir gets a shlib depend on libmirserver7, and the new one will be libmirserver8
[08:43] <xnox> oh, that's good =) then you simply need a no change rebuild.
[08:43] <xnox> $ dch --rebuild 'No change rebuild against libmirserver8'
[08:44] <Saviq> xnox, right, exactly
[08:44] <xnox> bzr commit / merge / push, whatever needed to get that uploaded via ci stuff.
[08:44] <xnox> (we just did ~400 uploads like this to pick up libperl5.18, and another ~100 uploads comming to pick up boost1.54)
[08:44] <Saviq> xnox, didn't know --rebuild, that helps :)
[08:44] <Saviq> :)
[08:46] <xnox> Saviq: yeah, so --rebuild uses "build1" suffix, if "ubuntuX" was not yet used. And then auto-sync from debian ignores/overrides "buildX" packages, so they stay in-sync with Debian. Not that it matters for mir/packages not in debian =)
[08:47] <Saviq> :)
[08:47] <Saviq> xnox, thanks!
[08:55] <didrocks> Saviq: just do a version bump in mir and bump the build-dep in unity-mir
[08:55] <didrocks> to ensure it'll pick the right version
[08:56] <Saviq> didrocks, ok then https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep16/+merge/191551 is correct
[08:56] <Saviq> didrocks, feels wrong as we don't *really* require it ;)
[08:56] <didrocks> Saviq: yeah, but it's possible to do for random transitions (but not frequent), not possible when the transition happens every week
[08:57] <Saviq> didrocks, understood
[08:57] <Saviq> didrocks, do we have a mechanism for no-change rebuilds in cu2d?
[08:58] <didrocks> Saviq: there is one, but I think it's good for upstream to feel the pain first (as we have to dput anyway)
[08:58] <didrocks> so that they think about ABI stability
[08:58] <didrocks> (also, it's only valid until next cu2d run)
[08:59] <Saviq> didrocks, :D
[08:59] <didrocks> so if we don't release right away, it won't get rebuild
[08:59] <didrocks> and won't be releasable
[08:59] <Saviq> mhm
[09:00] <Saviq> didrocks, btw, did we talk about reshuffling the stacks so that mir, unity-mir and unity8 are in one stack?
[09:00] <didrocks> Saviq: not sure what that will bring you
[09:00] <Saviq> didrocks, we'll be able to not wait for mir releases in unity-mir
[09:00] <Saviq> didrocks, and just merge and release the whole stack in concert
[09:01] <didrocks> Saviq: but if mir FTBFS, it will mean we can't release unity8
[09:01] <Saviq> didrocks, now we need to wait for mir to release - only then we can merge stuff into unity-mir
[09:01] <Saviq> didrocks, well, ok - mir and unity-mir, then?
[09:01] <didrocks> Saviq: that sounds more logical
[09:01] <didrocks> sil2100: as you are redeploying the stack, mind handling that? ^
[09:01] <Saviq> the dep between unity8 and unity-mir is more relaxed than between mir and unity-mir
[09:02] <sil2100> didrocks: Mirv is dealing with head, and I guess it's a head thing
[09:02] <didrocks> Mirv: then ^ ;)
[09:04] <Cimi> Saviq, I'm fixing https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/191247
[09:04] <Cimi> Saviq, not sure which ubuntuanimation shall I use
[09:04] <Cimi> what's the anlog of 250ms
[09:04]  * Mirv deploys the redeploy of redeploy
[09:05] <Cimi> brisk is the closer
[09:05] <Mirv> but ok, so a wish of moving unity-mir to mir stack? check.
[09:05] <Saviq> Cimi, I'd probably put SnapDuration there
[09:06] <Cimi> Saviq, but it's not using linear I believe
[09:06] <Saviq> Cimi, Duration has nothing to do with easing
[09:06] <Saviq> Cimi, you just need NumberAnimation { ... easing.type: Easing.Linear }
[09:06] <Cimi> Saviq, I know, but standard easing here is qeasingcurve
[09:07] <Cimi> Saviq, snap is 100, not 250
[09:07] <Saviq> Cimi, yes, but for opacity we're not using the standard easing
[09:07] <Saviq> Cimi, 165
[09:07] <Cimi> Saviq, it's 100 on the docs, ok
[09:07] <Saviq> Cimi, I meant Fast, sorry
[09:07] <Cimi> ok
[09:07] <Saviq> Cimi, yeah, Snap probably too quick
[09:07] <Saviq> Cimi, so Fast or Brisk
[09:08] <Saviq> Cimi, if Fast, you can also go UbuntuNumberAnimation { easing.type: Easing.Linear }
[09:08] <Saviq> as Fast is default
[09:08] <Cimi> Saviq, obviously ,don't worry for that
[09:12] <Cimi> is this going to be merged? https://code.launchpad.net/~unity-team/unity8/carousel-loader/+merge/190406
[09:12] <Cimi> because I'll have to merge this in the music video carousel in case
[09:14] <Saviq> Cimi, it is, but not today probably
[09:14] <Saviq> Cimi, just make it a prerequisite of the new branch
[09:14] <Cimi> ok
[09:20] <Saviq> Cimi, btw, can you please actively follow up with the sdk folk about the InverseMouseArea? so that they have it on their radar?
[09:21] <Cimi> I asked again 2 times no answers, I'll chase with zoltan
[09:21] <Cimi> Saviq, ^
[09:21] <Saviq> Cimi, talk to zsombi directly - IMA's his creation
[09:31] <Saviq> Mirv, you're deploying cu2d, can you please make sure unity8-autolanding is disabled still?
[09:31] <Saviq> Mirv, we need https://code.launchpad.net/~thomas-voss/unity-mir/less-aggressive-scores/+merge/191440 to be released to be able to look at mediumtests-touch again
[09:35] <nic-doffay> Saviq, got time for a review?
[09:38] <Saviq> nic-doffay, which one?
[09:39] <Mirv> Saviq: everything for trusty is in manual publishing mode
[09:40] <Cimi> Saviq, I updated the branch
[09:41] <Cimi> Saviq, no updated assets yet, we can update them later on
[09:41] <Cimi> jouni is not online
[09:41] <Saviq> Mirv, ah, cu2d != upstream merger, sorry ;)
[09:41] <Saviq> Mirv, so that should remain unaffected
[09:42] <nic-doffay> Saviq, the filters. The reliant branch finally got landed last week.
[09:42] <nic-doffay> https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145
[09:42] <Saviq> nic-doffay, landed, not released yet, so still tricky to test on the phone :/
[09:42] <Mirv> Saviq: :) yes, although for merger stuff it's best to check with francis
[09:42] <Saviq> nic-doffay, either way, I saw that on desktop the first item was selected - and it was not "All"
[09:42] <Saviq> nic-doffay, that expected?
[09:50] <nic-doffay> Saviq, that data is pulled from the backend pstolowski ^ ?
[09:55] <pstolowski> nic-doffay, Saviq : that's definately not expected
[09:56] <Saviq> pstolowski, there should be an "All" entry on both mobile and desktop, right?
[09:57] <Saviq> mhr3, think we should throttle refreshes? putting music on the device while looking at the music scope is scary ;)
[09:58] <Saviq> mhr3, and btw I made unity crash while swiping the carousel when it got refreshed
[09:59] <mhr3> Saviq, yep, throttling would be nice, but it should be deeper in mediascanner imo
[09:59] <Saviq> mhr3, yeah, probably
[09:59] <mhr3> then again, mediascanner might not be the only one that will need throttling
[09:59] <pstolowski> Saviq, yes, both, but it's up to the scope to enable 'all' button.
[09:59] <mhr3> so ideally both :)
[10:00] <mhr3> Saviq, and the crash sounds more like a ui-thing, no? :)
[10:00] <Saviq> mhr3, not necessarily, but didn't get a core out of it
[10:00] <mhr3> Saviq, sooo... get one? :)
[10:00] <Saviq> mhr3, I think it might've requested data from a result that disappeared
[10:01] <Saviq> should be easy :P
[10:02] <Saviq> ok, not ;P
[10:03] <Saviq> but yikes we need a better way for refreshing than redoing the whole model :/
[10:08] <pstolowski> Saviq, nic-doffay i'm trying unity8 trunk to see what is it about
[10:15] <Saviq> pstolowski, thanks
[10:16] <nic-doffay> pstolowski, cool just give me a shout if you need anything.
[10:32] <mzanetti> Saviq: how do I use translations in c++?
[10:32] <mzanetti> in unity8
[10:33] <mzanetti> I assume we're not using tr()
[10:33] <Saviq> mzanetti, gettext
[10:34] <Saviq> mzanetti, #include <libintl.h> and gettext / dgettext / ngettext etc.
[10:34] <mzanetti> Saviq: ack, thanks
[10:35] <Saviq> mzanetti, check out http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/plugin/i18n.cpp
[10:37]  * tsdgeos votes for exposing that into a header
[10:37] <tsdgeos> so we don't have to do that ugly QString::fromUtf8(C::ngettext(singular.toUtf8(), plural.toUtf8(), n)); ourselves
[10:37] <tsdgeos> and can do the less ugly
[10:37] <tsdgeos> I18n::tr(singular, plural, n);
[10:38] <Saviq> tsdgeos, bug on SDK?
[10:38] <Saviq> tsdgeos, I completely agree, too
[10:38] <tsdgeos> ok, i'll file it
[10:41] <tsdgeos> Saviq: mzanetti: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1243152
[10:41] <tsdgeos> mzanetti: if you do that gettext() thing you'll have to udapte the pot creation script i'd say
[10:42] <Saviq> yeah, possibly
[11:11] <mzanetti> 13 branches approved and ready to be merged
[11:28] <Cimi> dednick, was looking at https://code.launchpad.net/~nick-dedekind/unity8/indicator-segfault-lp1243146/+merge/192121
[11:28] <Cimi> dednick, usually when you bind properties you do onLoaded qt bind bla bla
[11:28] <Cimi> dednick, what was the binding originally done that other way?
[11:29] <Cimi> i'm curious to understand the difference
[12:11] <dednick> Cimi: yeah, i dont really understand why the binding is causing issue. Possibly the dynamic Qt.binding is not being destroyed when the qml "item" object is destroyed.
[12:12] <dednick> Cimi: i think that it's because od the "index" property inside the binding. It's being updated while the object is being destoyed or something.
[12:27] <mzanetti> Saviq: may I ask your opinion once again on this one? https://code.launchpad.net/~kalikiana/ubuntu-ui-toolkit/qsettingspath/+merge/191818
[12:27] <mzanetti> Saviq: the problem is, that if the SDK does not unset the organisationName it'll appear in QStandardPaths and break that.
[12:28] <mzanetti> unsetting it makes the QSettings experience a bit weird tho
[12:28] <mzanetti> so it's a tricky one
[12:28] <mzanetti> tsdgeos: you might have an opinion about that too ^
[12:29] <Saviq> mzanetti, so feels like a Qt bug? is it expected that orgname is cleared on setting appname?
[12:29] <mzanetti> Saviq: no, the SDK does that explicitly
[12:30] <Saviq> mzanetti, ah, why?
[12:30] <mzanetti> Saviq: Qt differs in a way that QStandardPath apparently doesn't add anything if organisationName is empty, while QSettings writes "Unknown Organisation"
[12:30] <mzanetti> Saviq: the remove it to make QStandardPath to point to only appname in order to make it work with apparmor
[12:30] <mzanetti> s/the/they/
[12:31] <Saviq> mzanetti, ah, 'cause if it's non-empty, QStandardPaths would have used the organization name in the
[12:31] <Saviq> -in the
[12:32] <mzanetti> yeah. that's how I understood kalikiana
[12:32] <Saviq> mzanetti, question is whether we'd want to allow different apps access to their organization
[12:32] <mzanetti> yeah, we probably don't want that
[12:32] <Saviq> mzanetti, i.e. cross-app data access within an organization
[12:33] <mzanetti> well, maybe
[12:33] <mzanetti> but it would allow very nasty attacks
[12:33] <Saviq> mzanetti, yeah, I think we might want to
[12:33] <mzanetti> i.e. compiling malware out of multiple apps at runtime
[12:33] <Saviq> mzanetti, you'd have to spoof orgName
[12:33] <Saviq> mzanetti, oh jeez
[12:33] <Saviq> mzanetti, it's closed source, deal with it ;P
[12:34] <Saviq> mzanetti, "we have root" ;P
[12:34] <mzanetti> just saying... I still think it's good practice to keep security in mind with everything we do
[12:34] <mzanetti> not sure what you mean with "we have root" in this context
[12:34] <Saviq> mzanetti, sure, allowing access between apps could be on a per-app basis
[12:35] <Saviq> mzanetti, the only other "fix" would be to make Qt consistent...
[12:35] <Saviq> mzanetti, which sounds scary
[12:35] <mzanetti> agreed
[12:35] <Saviq> mzanetti, or would at least involve migration
[12:36] <mzanetti> Saviq: what I meant before is that an app that doesn't have network capability but contacts could grab the addressbook and another app with only network could send it out if they have a shared data pool
[12:37] <mzanetti> not really related to closed vs open source
[12:37] <mzanetti> but more a bypass apparmor thing
[12:39] <Saviq> mzanetti, or, you'd just make an app that has access to both network and contacts ;)
[12:39] <mzanetti> Saviq: anyways... so I guess what kalikiana did in this merge is the closest we can get with reasonable efforts. Unless it would be possible to modify QStandardPath through the QPA
[12:39] <Saviq> mzanetti, but I *kind of* know what you mean
[12:39] <mzanetti> Saviq: well, you could also just turn off AppArmor. but that's not the point
[12:40] <Saviq> mzanetti, I mean that preventing cross-app access within the same orgname doesn't really buy us any security IMO
[12:40] <mzanetti> it certainly diggs a whole. as a user I might install some game which only has network and I feel secure that it doesn't spy on me. While I might install a plugin to the address book where I rely on AppArmor not allowing it to send anything through the network
[12:41] <mzanetti> s/whole/hole/
[12:43] <Saviq> mzanetti, as I said - it could be an additional permission
[12:43] <mzanetti> right. sure. anyways. that's rather offtopic
[12:44] <Saviq> yup
[13:04] <mzanetti> Saviq: do we actually plan to not use -mousetouch at some point?
[13:04] <mzanetti> Saviq: this option seems to be useless as it's required always
[13:08] <Saviq> mzanetti, not on the device it isn't
[13:08] <Saviq> mzanetti, but yeah, we'll drop it when Qt merges touch and pointer events ;)
[13:09] <mzanetti> Saviq: but using it on the phone shouldn't hurt either. and once we allow plugging in a real mouse through USB we'd need it there too, no?
[13:09] <mzanetti> Saviq: Qt merging touch and pointer events might be a loooong way down the road
[13:12] <Saviq> mzanetti, yeah I was always afraid of the "shouldn't hurt" part...
[13:12] <Saviq> mzanetti, I'd rather think of actually improving the DDA to understand mouse events as well as touch ones
[13:12] <dandrader> mzanetti, avoiding it on the phone gives you a 0.00001% performance boost. as you avoid the overhead of an event filter checking for mouse events :)
[13:13] <mzanetti> Saviq: ah ok. that's good enough as a reason for me
[13:13] <Saviq> dandrader, it shouldn't be difficult, should it? to make DDA understand mouse events, too?
[13:13] <mzanetti> dandrader: mhm... I see
[13:14] <mzanetti> I was just wondering as I type in -mousetouch every time I open a new branch in qtcreator...
[13:14] <mzanetti> not that it would be a real problem
[13:14] <dandrader> Saviq, no it's not difficult. but it's more work in any case
[13:14] <mzanetti> but yeah, in the long run we probably to fix this properly
[13:14] <mzanetti> +want
[13:15] <dandrader> Saviq, mzanetti another advantage I see in the mouse-to-touch translation is that you're able to have a code path on the desktop much closer to what you have on the device
[13:16] <mzanetti> dandrader: otoh it kills the mouse wheel
[13:16] <mzanetti> and probably other mouse specific stuff too
[13:16] <dandrader> mzanetti, yes, but you don't need it for a phone or tablet ui
[13:16] <mzanetti> dandrader: when running it on the desktop I do
[13:17] <mzanetti> dandrader: and that's not working as long as we require the -mousetouch
[13:19] <dandrader> mzanetti, I still don't see why you need the mouse wheel to play with a phone ui on the deskopt
[13:20] <seb128> mhr3, is the dash supposed to be useful/list local scopes if unity-scope-home is missing?
[13:21] <seb128> didrocks, ^
[13:22] <mhr3> seb128, if you just remove the pkg, nothing will work, you'd need to change a bunch of settings to get apps files etc
[13:22] <seb128> mhr3, should it be a depends of unity rather than a recommends then?
[13:22] <mzanetti> dandrader: I would use the mouse wheel to scroll to scopes for example?
[13:22] <mhr3> seb128, would make sense, yea
[13:22] <mzanetti> dandrader: through
[13:22] <seb128> mhr3, just got some french user who had recommends disabled and dash listing no app/file/... after updating to saucy
[13:22] <seb128> mhr3, k, I'm going to mp that then, thanks
[13:23] <mzanetti> dandrader: what I mean is unity8 is not a phone app. it's the same thing on the desktop, and the scrollwheel should work there
[13:26] <mzanetti> dandrader: so yeah... we should not make -mousetouch the default. I see that now. but instead make the DDA work with mouse somewhen in the future.
[13:27] <dandrader> mzanetti, I think that DDA makes no sense on the desktop-version of unity8
[13:27] <dandrader> mzanetti, you don't do gestures with the mouse. it's a whole different story
[13:28] <mzanetti> dandrader: right. I tend to agree...
[13:31] <greyback> Saviq: standup?
[13:32] <didrocks> thanks seb128 :)
[13:32] <seb128> didrocks, hey, yw!
[13:48] <kgunn> mterry: did you get a chance to talk to robert_ancell about socket sharing...and the "new" way of connecting
[13:51] <mterry> kgunn, yes...
[13:51] <mterry> kgunn, there is some bug with it, im trying to help
[13:52] <kgunn> mterry:  :) cool...so "we" think its complete...
[13:52] <mterry> kgunn, maybe?  :)
[13:53] <mterry> kgunn, it hasnt landed yet, bc of the bug
[13:53] <kgunn> mterry: oh...ok, exactly what i was wondering....if the mp's were done/merged
[13:54] <mterry> kgunn, some have
[13:54] <bregma> seb128, the missing unity-scope-home on upgrade is #1233029
[13:54] <kgunn> mterry: so complete in theory, minus the fact there's a bug that prevents it from operating? or is it failing ci ?
[13:55] <seb128> bregma, thanks
[13:56] <seb128> bregma, why is it marked as invalid for unity?
[13:56] <mterry> kgunn, yeah, a bug not a ci problem
[13:56] <seb128> bregma, mhr3 agrees that it should be a depends
[13:57] <bregma> seb128, just go ahead and reopen for Unity
[13:57] <seb128> bregma, k
[14:20] <pstolowski> Saviq, re filters it seems to me that UI assumes first filter option is selected when filter is created (be it 'All', or a real filter option). this is not correct. while this is kind of ok if scope provides 'all' filter option, it's not good if it doesn't (i.e. in Home, which doesn't have 'All' by design - BTW, does it make sense on the phone?). Currently backend doesn't mark 'All' as selected - it probably should, but that's a s
[14:20] <pstolowski> eparate issue. To sum it up, I think UI shouldn't make any assumptions about 1st option being selected, and just rely on the model
[14:22] <Saviq> pstolowski, ok thanks
[14:25] <pstolowski> Saviq, i'll discuss this with Nic when he is online
[14:26] <Saviq> pstolowski, thanks
[14:26] <pstolowski> Saviq, i'm a bit unsure about the lack of 'All' in Home; this was deliberately removed from home filters, but you can't unselect filter options in unity8 right? in that case 'All' makes sense?
[14:27] <Saviq> pstolowski, well, we could allow unselecting them, but then the UI doesn't really cope well with multiselection anyway
[14:27] <Saviq> pstolowski, i.e. you'll only see a single selected item anyway
[14:29] <pstolowski> Saviq, uh, and I just realized having 'All' in home would have more implications
[14:30] <Saviq> pstolowski, yeah
[14:31] <Cimi> mzanetti, I'm trying to run autopilot from tests/autopilot dir, I get this
[14:31] <Cimi> RuntimeError: Unable to instantiate any backends
[14:31] <Cimi> UInput: UInputError('"/dev/autopilot-uinput" cannot be opened for writing',)
[14:31] <Cimi> I have unity8-autopilot installed
[14:31] <mzanetti> Cimi: /dev/autopilot-uinput cannot be opened for writing :P
[14:32] <mzanetti> Cimi: what does "ls -l /dev/autopilot-uinput" say?
[14:32] <Cimi> mzanetti, yeah, what the hell is that
[14:32] <Cimi> mzanetti, root
[14:32] <Cimi> mzanetti, we need root access?
[14:32] <mzanetti> Cimi: root:root?
[14:32] <Cimi> y
[14:32] <Cimi> and loads of r/w permissions though
[14:33] <mzanetti> yeah... there is a udev rule which changes permissions afaik. but that only works once udev is restarted
[14:33] <mzanetti> rebooting should help
[14:33]  * Cimi reboots
[15:38] <Cimi> tsdgeos, I am trying to do the autopilot tests for the greeter backhround
[15:38] <tsdgeos> ok
[15:38] <Cimi> tsdgeos, but the y coordinates are not map on the window coordinates, are relative to their parent
[15:38] <tsdgeos> yep
[15:38] <Cimi> tsdgeos, so how do I get them relative to window?
[15:38] <tsdgeos> you need the mapTo/mapFrom thing
[15:39] <Cimi> tsdgeos, is it accessible from python?
[15:39] <tsdgeos> hmmm
[15:39] <tsdgeos> good question
[15:39] <tsdgeos> honestly i do not know
[15:39] <tsdgeos> the other thing is
[15:39] <mzanetti> no, it's not
[15:39] <tsdgeos> if as mzanetti correctly said, we're going to split the greeter to a different process
[15:40] <tsdgeos> this autopilot test won't make sense
[15:40] <tsdgeos> actually scratch that
[15:40] <Cimi> ok...
[15:40] <tsdgeos> it will still make sense, but will have to start the greeter
[15:40] <tsdgeos> or?
[15:40] <mzanetti> it will make a lot of sense once the split is done. but until then it's just here to break
[15:40] <Cimi> how do I get the relative coordintes then?
[15:41] <tsdgeos> Cimi: then you'll have to manually recurse parents and add the .y ?
[15:41] <mzanetti> ouch
[15:41] <Cimi> pls no
[15:41] <mzanetti> ah wait
[15:41] <mzanetti> no
[15:41] <tsdgeos> but autopilot had a globalx/globaly coords
[15:41] <tsdgeos> no?
[15:41] <mzanetti> autopilot always gives you "mapToGlobal"
[15:41] <Cimi> mmm ok
[15:41] <Cimi> mow to use it?
[15:41] <mzanetti> that is, all coords you get are mapped to 0,0 of the application (or even the screen)
[15:42] <mzanetti> so you could easily check if the background.y is panel.height down from Shell.y
[15:42] <mzanetti> if that's what you want
[15:44] <mzanetti> dandrader: you wrote the fake app manager, right?
[15:44] <dandrader> mzanetti, yes
[15:45] <mzanetti> dandrader: I can't really find why it still works for gallery-app and camera-app and everything else doesn't
[15:45] <mzanetti> dandrader: I'd need more of those fake apps
[15:45] <dandrader> mzanetti, If I recall correctly there's a hardcoded list of fake apps somewhere
[15:45] <mzanetti> I tried to adjust buildListOfAvailableApplications() but that doesn't seem to be enough
[15:46] <dandrader> mzanetti, also the fake apps have to have their fake screenshots and icons
[15:47] <mzanetti> dandrader: yeah, I just would need to have those fakes we had half a year ago.
[15:47] <mzanetti> but for some reason the startApplication() is not even called except for gallery and camera
[15:47] <mzanetti> even though the appId would match the one in buildListOfAvailableApplications()
[15:48] <dandrader> mzanetti, odd. last time I played with them (a while ago) I'm sure the fake facebook worked as well
[15:48] <mzanetti> dandrader: the webapps actually trigger kioclient here :D
[15:48] <dandrader> mzanetti, maybe there's a mismatch between the appIp in the fake ApplicationManager
[15:49] <mzanetti> dandrader: as in "unity8 asks KDE to launch them"
[15:49] <dandrader> mzanetti, and the appId in the icon used by the launcher?
[15:49] <Cimi> mzanetti, where is doc for mapToGlobal?
[15:49] <mzanetti> dandrader: for example trying with the dialer: it says: Unable to activate  "dialer-app.desktop"
[15:50] <mzanetti> Cimi: I think QWidget and QGraphicsItem have those
[15:50] <dandrader> mzanetti, the fake app manager has no dialer-app
[15:50] <Cimi> mzanetti, but how to use them?
[15:50] <mzanetti> dandrader: I already updated the fakeapplicationmanager to have dialer-app.desktop instead of the old "phone-app"
[15:50] <dandrader> mzanetti, it has a phone-app
[15:50] <Cimi> mzanetti, this is python
[15:50] <dandrader> :D
[15:50] <mzanetti> dandrader: yeah, I did that... still nothing. the startApplication() doesn't get called for it
[15:51] <mzanetti> Cimi: the mapToGlobal() happens inside autopilot-qt
[15:51] <mzanetti> Cimi: all the x and y you get are already mapped to global
[15:51] <Cimi> mzanetti, don't think so
[15:51] <Cimi> mzanetti, I have -29.0
[15:51] <mzanetti> Cimi: oh, right. I remember... ever item should have a .globalRect
[15:51] <dandrader> mzanetti, you mean the startApplication from the cpp side? (in tests/mocks/Unity/Application/ApplicationManager.cpp)
[15:51] <dandrader> is not called at all?
[15:52] <mzanetti> Cimi: which is a array of length 4
[15:52] <Cimi> mzanetti, let me try
[15:52] <mzanetti> dandrader: yes
[15:52] <dandrader> mzanetti, then the application manager wrapper must be doing something...
[15:52] <dandrader> mzanetti, from the qml side
[15:52] <mzanetti> dandrader: I'm afraid it's even earlier, in the scopes somewhere
[15:52] <mzanetti> dandrader: I just hoped you would know what. But I'll figure it if you don't
[15:53] <dandrader> mzanetti, I would have to dig into it. many things changed since I last did heavy development on that side
[15:53] <mzanetti> dandrader: sure. no problem... I thought it's still worth a try
[15:58] <Cimi> mzanetti, easily compare the globarect, cool
[16:00] <mzanetti> Cimi: nice
[16:01] <kgunn> Saviq: under the list of stuff for indicators...any idea what this one means "Porting of app-menu"
[16:01] <kgunn> like 3rd party indicator support?
[16:01] <Saviq> kgunn, yup
[16:02] <Saviq> kgunn, although AFAICS that's desktop-only
[16:02] <Saviq> kgunn, design doesn't cater for 3rd party indicators on phoe
[16:02] <Saviq> phone
[16:02] <kgunn> sure....
[16:02] <kgunn> planning is going to go until convergence
[16:02]  * tsdgeos has hacked TabBar not to need a Tabs/MainView
[16:02] <kgunn> or that's the plan
[16:02] <Saviq> tsdgeos, \o/
[16:02] <tsdgeos> Saviq: http://paste.ubuntu.com/6283736/
[16:02] <Cimi> mzanetti, setting a property for the panel size isn't that nice, instead just using panel.height
[16:03] <Cimi> mzanetti, I mean in the greetercontent
[16:03] <tsdgeos> Saviq: it's a bit ugly and depends on the SDK guys not changing the names of the stuff they expect
[16:03] <Saviq> kgunn, yeah, right - what I mean is that we need to re-sync with design on that
[16:03] <Cimi> mzanetti, implies adding a binding to the Loader inside Greeter.qml
[16:03] <kgunn> Saviq: got it...like we might actually want to add to phone form factor as well
[16:03] <tsdgeos> Saviq: i guess i could suggest a TabsBase thing in the SDK we could both "inherit" so they don't change it in the future
[16:03] <tsdgeos> Saviq: whatcha think?
[16:03] <mzanetti> Cimi: yeah... but it doesn't break in 3 weeks ;)
[16:03] <Saviq> tsdgeos, +1
[16:04] <Saviq> tsdgeos, we should just try and propose changes in the sdk that we need
[16:04] <tsdgeos> sure
[16:04] <tsdgeos> this was more of a "let's see if i can make it work" thing
[16:04] <tsdgeos> since having a mainview was a bit of a pain
[16:04] <Saviq> kgunn, yeah, I think question is really *why* do we not support 3rd party indicators on phone - if it's only about screen real estate - should they be enabled on tablet?
[16:07] <Saviq> tsdgeos, you should look at the indicators - dednick already managed to get it to work in there
[16:07] <tsdgeos> Saviq: i did
[16:07] <Saviq> tsdgeos, so maybe some ideas there
[16:07] <tsdgeos> didn't like it :D
[16:07] <Saviq> tsdgeos, ah ok
[16:08] <Saviq> lol
[16:08] <dednick> eh?
[16:08] <tsdgeos> dednick: re-tabs and MainView
[16:08] <dednick> tsdgeos: yeah, it's shit. asked sdk for a non-MainView page like 3 months ago.
[16:08] <tsdgeos> i know, seen the bug
[16:09] <tsdgeos> dednick: i hacked a thing together today http://paste.ubuntu.com/6283736/
[16:09] <tsdgeos> needs 1 line modif in the SDK
[16:09] <tsdgeos> and tomorrow i'll try to get something less hacky to a merge request for the SDK
[16:10] <dednick> yikes
[16:10] <tsdgeos> dednick: what?
[16:10] <tsdgeos> it's not that bad :D
[16:10] <dednick> hehe
[16:10] <dednick> ok
[16:10] <tsdgeos> and that said, EOD time
[16:11]  * tsdgeos waves
[16:13] <Cimi> https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414
[16:13] <Cimi> mzanetti,  ^
[16:21] <Cimi> Saviq, asset updated https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/192118
[16:40] <mzanetti> dandrader|lunch: duude... that DDA crash fix grew a little :D