[00:49] <tedg> Saviq, Hmm, I thought it did because that's how Click checks to see if the app is running and shuts it down, no?
[00:53] <tedg> Saviq, Yeah, this calls UAL, so it needs to have access to the session bus. http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/lib/click/database.vala#L267
[07:46] <tsdgeos> Saviq: interestingly the backtrace is different
[07:46] <tsdgeos> so indeed seems a different thing :S
[07:46] <tsdgeos> or not...
[08:07] <Saviq> tsdgeos, I assume you're talking about the last crash in DashContent?
[08:07] <tsdgeos> Saviq: yes
[08:07] <tsdgeos> i think it's a different crash
[08:08] <tsdgeos> because if i run from qtdeclarative git it doesn't crash (or hasn't for the last 20 min)
[08:08] <Saviq> mzanetti, did you notice tedg's reply yesterday about click hooks?
[08:08] <tsdgeos> let me try to see if the incubate patch we spoke yesterday actually fixes this one
[08:08] <mzanetti> Saviq: no... fell asleep like instantaneously
 [02:49:58] Saviq, Hmm, I thought it did because that's how Click checks to see if the app is running and shuts it down, no?
[08:08] <Saviq>  [02:53:25] Saviq, Yeah, this calls UAL, so it needs to have access to the session bus. http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/lib/click/database.vala#L267
[08:09] <Saviq> mzanetti, ↑
[08:09] <mzanetti> err...
[08:09] <mzanetti> but...
[08:09] <mzanetti> it doesn't :D
[08:10] <mzanetti> Saviq: my hook is a script that echoes those variables to a file, and they are all empty
[08:10] <mzanetti> so probably something wrong with the hook still
[08:11] <mzanetti> Saviq: see anything wrong? http://paste.ubuntu.com/8086809
[08:13] <Saviq> mzanetti, not really
[08:13]  * Saviq tries it out
[08:13] <mzanetti> Saviq: http://paste.ubuntu.com/8086819
[08:17] <Saviq> mzanetti, yeah I just went env >
[08:18] <Saviq> mzanetti, but confirmed it doesn't work
[08:18] <Saviq> or well, that the env is empty / weird
[08:19] <Saviq> on hook install it was sane
[08:19] <Saviq> but on app install it was just 4 random values
[08:35] <mzanetti> Saviq: so what you suggest?
[08:36] <mzanetti> going the session route?
[08:37] <mzanetti> I mean the upstart thing we discusses yesterday
[08:49] <Saviq> mzanetti, no, we'll need to talk to folks later today
[08:49] <Saviq> mzanetti, let's find out what's their approach, unfortunately cjwatson isn't around until later this week AFAIR
[09:17] <sil2100> Saviq: hi! I noticed you did some reviews for MacSlow's unity-notifications
[09:18] <sil2100> Saviq: could you (or find anyone else from your team) have a take on reviewing his branch? It's a blocker fix: https://code.launchpad.net/~macslow/unity-notifications/fix-1354406/+merge/231005
[09:27] <Saviq> sil2100, will do
[09:27] <Saviq> @unity, who wants to take ↑ please?
[09:27] <sil2100> Thanks!
[09:27] <Saviq> MacSlow, just one clarification on the above
[09:28] <Saviq> MacSlow, I'm worried that the push notifications backend might send multiple notifications in the name of different services
[09:28] <Saviq> Chipaca, can you relate to ↑ for us?
[09:29] <Chipaca> what's that again?
[09:31]  * Chipaca reads
[09:32] <Chipaca> I'm not sure what that does
[09:33] <Chipaca> just skimming the mp, i mean, i can't tell if it's adding senderName to the dbus api, if it's adding it to the libnotify api, or if it's deducing it from the dbus connection
[09:33] <Chipaca> Saviq: ?
[09:35] <Chipaca> none of those don't break push notifications, fwiw
[09:35] <Saviq> Chipaca, yeah, that's what I wanted clarification on
[09:35] <Chipaca> Saviq: which that is that?
[09:35] <Saviq> Chipaca, with MacSlow ;)
[09:35] <Chipaca> the breaking of push, or the thing that's being implemented?
[09:35] <Saviq> Chipaca, don't you send more than one notification from the push service if they come in at the same time?
[09:36] <Chipaca> yes
[09:36] <Chipaca> not more than one per application at the same time though
[09:36] <Chipaca> although they could be in quick succession
[09:38] <Saviq> Chipaca, yeah, that's the point, per application, but I'm worried the change in the above MP actually looks at the dbus sender name
[09:38] <Saviq> Chipaca, which would mean that you'd be prevented from sending more than one in quick succession
[09:39] <Saviq> tsdgeos, could you please look through https://code.launchpad.net/~marcustomlinson/unity8/lp-1356410/+merge/231326
[09:39] <Saviq> tsdgeos, I think we might need to do onGotoScope there too
[09:39] <tsdgeos> Saviq:  sure
[10:05] <Cimi> where goes the qml log of autopilot?
[10:06] <Saviq> Cimi, same as everything
[10:07] <Saviq> Cimi, ~/.cache/upstart/unity8{,-dash}.log
[10:07] <Cimi> Saviq, I have AP failure on scope settings
[10:07] <Cimi> Saviq, fixing that...
[10:07] <Cimi> Saviq, currentIndex related issues
[10:09] <Cimi> Saviq, hah, found
[10:09] <Saviq> Cimi, good boy
[10:09] <Saviq> :P
[10:12] <Cimi> Saviq, are you sure of this? > +        readonly property int count: status [10:12] <Cimi> item && item.count || 0
[10:13] <Cimi> mmm
[10:14] <Saviq> Cimi, why not?
[10:14] <Saviq> Cimi, if item is null, 0
[10:14] <Saviq> Cimi, if item.count evaluates to false (null, undefined, 0), 0
[10:15] <Saviq> otherwise item.count
[10:16] <Cimi> Saviq, yeah indeed...
[10:17] <Cimi> Saviq, there is sth weird or I am stupid
[10:17] <Cimi> I'm in autopilot test for open preview, this code http://paste.ubuntu.com/8087581/
[10:18] <Cimi> preview_list.currentIndex seems 1 here, but log in qml shows 0
[10:24] <Saviq> Cimi, onCurrentIndexChanged: console.debug(currentIndex)?
[10:24] <Cimi> 0 0 0
[10:24] <Cimi> starts from -1 and becomes 0
[10:24] <Cimi> not 1
[10:25] <Cimi> I just forced it to 0, let's see
[10:26] <Cimi> forcing to 0 in the loader is actually 0
[10:26] <Cimi> test pass
[10:27] <Saviq> Cimi, sure you get the correct object in autopilot?
[10:29] <Cimi> Saviq, works with readonly property int currentIndex: status [10:29] <Cimi> Saviq, but doesn't with readonly property int currentIndex: item && item.currentIndex || -1
[10:32] <Saviq> Cimi, why do you even need to pass currentIndex up?
[10:32] <Cimi> Saviq, tests I think
[10:32] <Saviq> Cimi, just get into the loader in tests instead
[10:33] <Cimi> Saviq, ok but doesn't answer my mental question "what's wrong in that code"
[10:35] <mzanetti> soo... I tried to switch over to unity and increased the scale factor for high dpi to 1.5, which causes icons to be 1.5 but fonts to be scale factor 3
[10:35] <mzanetti> 'cause X11 reports a dpi of 220 which changes fonts already
[10:35] <mzanetti> anyone else here running unity on a high dpi screen?
[10:36] <Saviq> Cimi, I'd say the binding is broken somewhere, and you're not really looking at the same property
[10:36] <Cimi> Saviq, but console.log I put both inside the previewlist and the loader, they all change at the same time
[10:37] <Cimi> Saviq, unless this is a timing issue
[10:37] <Cimi> Saviq, having -1 intead 0...
[10:43] <Cimi> even this works item && item.hasOwnProperty("currentIndex") ? item.currentIndex : -1
[10:43] <dandrader> mzanetti, ping
[10:43] <Cimi> but not item && item.currentIndex || -1
[10:43] <Saviq> Cimi, well
[10:44] <Saviq> Cimi, 0 evaulates to false
[10:44] <Saviq> Cimi, so when currentIndex is 0
[10:44] <Saviq> Cimi, it would end up -1 in this case
[10:44] <Cimi> right!!!!!!!!!
[10:44] <Saviq> Cimi, it only made sense when it was || 0
[10:44] <Cimi> Saviq, that must be it, thanks!!
[10:47] <mzanetti> dandrader: pong
[10:47] <Cimi> Saviq, ok pushed
[11:02] <greyback_> Saviq: think you'd have a chance to re-visit https://code.launchpad.net/~gerboland/unity-api/surfaceSizerCallback/+merge/230270 ?
[11:02] <greyback_> if not, please point someone else to it
[11:04] <Saviq> greyback_, yeah, will do
[11:14] <dednick> Saviq: fix for the indicator bug - https://code.launchpad.net/~nick-dedekind/unity8/lp1328646/+merge/231335
[11:15] <Saviq> dednick, great, thanks
[11:17] <facundobatista> Holas
[12:13] <greyback_> dandrader: I replied to you in  https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/230490
[12:14] <dandrader> greyback_, !? http://bazaar.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/revision/1147
[12:15] <dandrader> ah right. nevermind that. you're adding it back again
[12:15] <Cimi> Saviq, finally something that looks sane https://code.launchpad.net/~cimi/unity8/infographics-august-merge/+merge/231344
[12:16] <Cimi> took me a while :D
[13:16] <mzanetti> tedg: ping
[13:16] <tedg> Good morning mzanetti
[13:16] <mzanetti> tedg: good morning!
[13:17] <mzanetti> tedg: so, I saw your reply regarding the session and click hooks
[13:17] <dednick> Saviq: re the ref/deref thing. I couldn't get it working properly with being able to share the object. If i give the menumodel i create no context, it doesn't seem to delete until the app is close, not when the last ref is released.
[13:17] <mzanetti> tedg: doesn't work for me :D and thinking about it, it kinda makes sense that the hooks don't have the session exported
[13:17] <mzanetti> tedg: because there could be multiple sessions running
[13:18] <dednick> Saviq: and if i give it the createObject context, it just deletes the menumodel regardless if there are other things referencing it.
[13:18] <tedg> mzanetti, The click user hooks should always be run as the user that they're referencing.
[13:18] <mzanetti> tedg: yes, its ran as the user phablet, that's fine
[13:18] <mzanetti> tedg: but it doesn't have DBUS_SESSION_BUS_ADDRESS exported
[13:19] <Saviq> dednick, hmm wonder if you forced the garbage collector to run...
[13:19] <dednick> Saviq: howto?
[13:19] <tedg> mzanetti, Asking cjwatson about it, worst case you can get it from the file, but it seems like other hooks would use it as well.
[13:20]  * mzanetti is confused about the channel :=
[13:20] <mzanetti> :)
[13:20] <Saviq> dednick, http://qt-project.org/doc/qt-5/qtqml-javascript-qmlglobalobject.html gc()
[13:20] <mzanetti> tedg: right... we figured the way to get it though the upstart session file and then get-env for the dbus address
[13:20] <Saviq> dednick, that object needs to be parentless when passed to QML for it to be garbage collected though
[13:20] <mzanetti> tedg: but that seems a bit...
[13:21] <Saviq> mzanetti, I talked with cjwatson briefly today
[13:21] <dednick> Saviq: yup.
[13:21] <mzanetti> ah
[13:21] <mzanetti> Saviq: outcome?
[13:21] <Saviq> mzanetti, and he said this should really work, as those are run *from* the upstart session
[13:21] <josharenson> If I have a branch in +junk and I need to move it to a 'team branch' so it can be merge elsewhere, can I just push it to ~unity-team ?
[13:22] <mzanetti> Saviq: ah, so you mean the hook would be executed multiple times in case of multiple sessions?
[13:22] <Saviq> mzanetti, but then I lost his attention
[13:23] <Saviq> mzanetti, would have to be yeah (not that we do support multiple sessions yet)
[13:23] <tedg> mzanetti, Saviq, what do you guys do for legacy apps, a directory watch?
[13:23] <mzanetti> not sure yet...
[13:23] <Saviq> tedg, no, we'll only do startup
[13:23] <Saviq> tedg, as those can only change on OTA
[13:23] <Saviq> tedg, and if you make your device writable... your fault, reboot :P
[13:23] <tedg> Saviq, I can write something to .local/share/applications anytime I want :-)
[13:24] <Saviq> tedg, hmm right forgot .local
[13:24] <tedg> (or delete)
[13:24] <Saviq> tedg, sounds like directory watch then, nothing else
[13:24] <tedg> Saviq, If you make a dbus interface for "changed" I'd recommend setting up an Upstart job with the directory watch that then signals the changed.
[13:24] <Saviq> tedg, but *later*
[13:24] <tedg> Saviq, Keeps the code simpler.
[13:24] <Saviq> tedg, yeah we do
[13:24] <Saviq> have a dbus interface
[13:25] <Saviq> sounds like a good idea
[13:25] <dednick> Saviq: hm. no, doesnt seem to do the trick either.
[13:25] <mzanetti> I guess I would just do the filesystem watch in the launcher though
[13:25] <mzanetti> why another process?
[13:25] <tedg> You can do something like: start on (file FILE=~/.local/share/applications/*.desktop)
[13:25] <Saviq> dednick, thing is I think they need to get out of scope to get gc'd
[13:26] <Saviq> dednick, there's no refcounting IIRC
[13:26] <dednick> Saviq: they should be oos. if the UnitMenuModel cache is destroyed.
[13:27] <Saviq> actually no, it should be refcounted
[13:27] <dednick> Saviq: yet they don't really have scope, since they are created without context
[13:27] <dednick> so the engine is probably their scope
[13:28] <dednick> well, without parent i mean
[13:28] <dandrader> greyback_, mzanetti all fixed in the unity8/lifecycle mp
[13:29] <mzanetti> dandrader: ok... I think we're good code wise now... need to have some little more testing before I feel confident enough to approve
[13:29] <mzanetti> dandrader: but I don't expect much more breakage
[13:29] <Saviq> dednick, yeah, so they should be ref'd after all
[13:29] <tedg> Saviq, Anyway, where I was going, if you make your own directory of links and watch that you'll get the change when the links are updated and a distinction between legacy and click apps.
[13:30] <tedg> Saviq, You can also use the short appids
[13:30] <Saviq> dednick, can you read http://qt-project.org/doc/qt-5/qqmlengine.html#ObjectOwnership-enum and see if anything you're doing applies and results in cppownership?
[13:30] <mzanetti> tedg: ooh! that's awsome
[13:30] <mzanetti> didn't know that
[13:30] <mzanetti> tedg: will that still work when we switch to systemd? :)
[13:30] <Saviq> tedg, mzanetti, but do we care actually? we need to go through all locations regardless
[13:30] <Saviq> ?
[13:31] <mzanetti> Saviq: well, we need to get triggered somehow
[13:32] <tedg> Saviq, Yes, but knowning click or not would be useful for you. And so would be using the short ids because they'd change less.
[13:32] <Saviq> mzanetti, yeah, we get triggered by the hook, whether the Pattern: is different for us than for click hook
[13:32] <Saviq> tedg, but then if we monitor .local/share/applications, we'd get notified about any changes there anyway
[13:32] <Saviq> tedg, short or not
[13:33] <mzanetti> Saviq: not sure I understand. I don't think the click hook will execute when a legacy app is installed/removed, is it?
[13:33] <Saviq> mzanetti, exactly, no, but that's not something that tedg was referring to
[13:33] <Saviq> mzanetti, unless you mean the upstart notify ;)
[13:33] <mzanetti> yes, I meant that
[13:33] <mzanetti> ok
[13:33] <Saviq> mzanetti, because there seem to be two conversations going on in parallel :)
[13:33] <mzanetti> confusion solved
[13:34] <mzanetti> there seem to be more than 2 :D
[13:37] <mzanetti> Saviq: so I'm still not sure what to do now..
[13:38] <Saviq> mzanetti, first we need to understand why your hook does not get the right env
[13:38] <Saviq> mzanetti, join #ubuntu-devel and talk to cjwatson please
[13:46] <dednick> Saviq: it seems to be working, but don't seem to have any control over garbage collection.
[13:47] <dednick> Saviq: so don't really know if the models are being deleted.
[13:47] <dednick> Saviq: which means they will be left running
[13:47] <Saviq> dednick, well, qDebug() << "deleted!"; to try? ;)
[13:47] <Saviq> in ~
[13:47] <dednick> Saviq: yes, well that's what i mean. it's a bit random
[13:47] <Saviq> dednick, yeah, that's gc for you
[13:47] <Saviq> dednick, it's not an exact science
[13:48] <dednick> Saviq: well, i'm not convinced!
[13:48] <dednick> Saviq: we could be left with models running until app close
[13:48] <Saviq> dednick, until shell close, which it never does...
[13:48] <Saviq> dednick, and because it's a cache...
[13:49] <dednick> Saviq: presicely.
[13:49] <Saviq> dednick, it's caching things
[13:49] <Saviq> dednick, but do you mean we'll be leaking them?
[13:49] <MacSlow> dandrader|afk, Saviq: whoever has time... https://code.launchpad.net/~macslow/unity8/fix-1348092/+merge/228090 is passing all AP- and qml-tests again... so another look is welcomed.
[13:50] <Saviq> dednick, the cache should probably be a factory is all?
[13:50] <dednick> Saviq: possibly. if we're switching from different profiles
[13:50] <Saviq> dednick, meaning it keeps a handle on those it created
[13:50] <Saviq> dednick, and gives the same up if they exist in the cache?
[13:51] <dednick> Saviq: that's what it does
[13:51] <Saviq> dednick, then at worst we'll have $number_of_indicators of them hanging around
[13:51] <Saviq> dednick, what's your worry? mem? cpu usage?
[13:51] <Saviq> dednick, don't we have them all around anyway for the panel?
[13:51] <dednick> Saviq: yes. responding to changes in indicators.
[13:52] <Saviq> dednick, or are those only used in the pages themselves?
[13:53] <dednick> Saviq: i think we are supposed to be switching indicator profiles when changing from greeter mode to phone mode. which means we'll have indicators*2 models
[13:53] <dednick> to "normal" mode i mean
[13:54] <Saviq> dednick, can't the cache be switched to a different profile?
[13:54] <Saviq> dednick, and really I don't think it's so bad to have them around for a while, they will get gc'd at some point
[13:55] <Saviq> dednick, but if you're going in and out if them, it's even better to keep them around
[13:56] <dednick> Saviq: ok, well if you think it's ok then i'm not fussed.
[13:58] <mzanetti> Saviq: so we're going for a workaround/hack atm, that's for sure. The 2 possibilites we have atm is changing click-scope to execute click hook run-user after package operations or the session file thing from yesterday
[13:58] <mzanetti> I guess I vote for the session file
[13:58] <Saviq> dednick, as long as you can see them really getting destroyed
[13:58] <Saviq> mzanetti, "atm" meaning until we get an update from cjwatson?
[13:59] <mzanetti> Saviq: yes
[13:59] <dednick> Saviq: i can see them being destroyed on app shutdown.
[13:59] <Saviq> mzanetti, or should we just do the upstart thing
[13:59] <Saviq> dednick, oh well, that sounds like they're not deref'd then on menus closed
[13:59] <mzanetti> Saviq: atm means, cjwatson can look at it at earliest in september
[13:59] <Saviq> dednick, so not gc'd
[13:59] <mzanetti> Saviq: after rtm afaiu
[13:59] <Saviq> mzanetti, should we just go for the upstart thing anyway
[13:59] <mzanetti> Saviq: +1
[14:00] <Saviq> mzanetti, we wouldn't need the click hook at all then
[14:00] <mzanetti> huh?
[14:00] <mzanetti> Saviq: why not?
[14:00] <mzanetti> Saviq: aaa
[14:00] <Saviq> mzanetti, because we'll be monitoring ~/.local/share/applications already
[14:00] <mzanetti> you mean tue upstart file watcher
[14:00] <Saviq> yes
[14:00] <mzanetti> that actually sounds even better
[14:00] <mzanetti> Saviq: ok. /me doing that
[14:01] <mzanetti> thanks!
[14:01] <Saviq> tedg, can you point us at the upstart directory watcher thingy?
[14:01] <tedg> Saviq, One sec, OTP
[14:02] <mzanetti> Saviq: iafau its justa  job file with "start on (file FILE=~/.local/share/applications/*.desktop)"
[14:02] <mzanetti> and the dbus call in exec
[14:03] <Saviq> ah so it's a bridge
[14:04] <Saviq> mzanetti, yeah, sounds good, make it start on /usr/share/applications/*.desktop too
[14:04] <mzanetti> Saviq: yeah, sure
[14:04] <Saviq> mzanetti, and on unity8 startup, but that one probably internally in LauncherBackend
[14:04] <mzanetti> yep
[14:06] <Saviq> MacSlow, btw, please put some context in your branch names, is difficult to find them when they're just named after bugs
[14:09] <tedg> Cool, looks like you guys got it. Yeah, just using he file bridge.
[14:11] <tedg> Send the dbus message then cat all the files into /dev/null so the FS loads them into cache :-)
[14:12] <Saviq> dednick, is the panel not using the cache models?
[14:14] <dednick> Saviq: everything should be
[14:14] <MacSlow> Saviq, hehe... I put the bug-# in the name to lead right to it... anyway branches for unity8 and unity-notification with the name "fix-1348092" are the visual-updates for notifications.
[14:15] <Saviq> MacSlow, yeah, it's fine if I actually go to that page
[14:15] <Saviq> MacSlow, but when I try to use my browser history, that doesn't work any more ;)
[14:15] <Saviq> MacSlow, and then the branches are linked to bugs
[14:16] <dednick> Saviq: everything that gains a reference to a model should be getting it from the cached model, which is part of IndicatorBase (which both Page & Widget inherit from). So as sson as base goes OOS, then the cached model should be destroyed and references released.
[14:16] <Saviq> dednick, so how can they ever get deleted if the panel uses it?
[14:16] <Saviq> dednick, isn't it the same cache both Page and Widget use?
[14:17] <Saviq> *cached model, that is
[14:17] <MacSlow> Saviq, true... but seeing (just from looking at branch-names) what is a actual bug-fix vs a test/feature/proof-of-concept branch saves time skimming through a lot of them... imo
[14:17] <Saviq> MacSlow, I didn't say *do not* put bug numbers in there
[14:17] <Saviq> MacSlow, just add some context too
[14:17] <Saviq> MacSlow, and remember we have bugs that are features too ;)
[14:18] <MacSlow> Saviq, yeah... and odd concept ;)
[14:18] <dednick> Saviq: yes. if we lose an indicator (remove a file for example) the indicator manager will remove the entry from the indicators model. This should then remove both page & widget from the panel.
[14:18] <Saviq> dednick, ok, and that doesn't happen?
[14:18] <dednick> Saviq: as far as i know it does. trying to figure it out now.
[14:18] <Saviq> dednick, or e.g. when you disable the bluetooth indicator (or should that even cause the removal?)
[14:19] <dednick> Saviq: disabling not necessarily. that might just switch off the visibility.
[14:19] <dednick> Saviq: which we still need the connection to the model for.
[14:19] <Saviq> dednick, in that case IMO it's really a moot point to be trying to deleting them, when would an indicator ever disappear?
[14:19] <Saviq> in real life that is
[14:20] <dednick> Saviq: well, it's not the removals i was concerned about. was the profile changing.
[14:21] <Saviq> dednick, ah ok, so yeah, can't we reuse the cache for a different profile, or do we explicitly *not* want to do that
[14:21] <Saviq> dednick, aaand anyway, tedg, mterry, is the plan to actually switch profiles between greeter/touch in the short term, or just the touch profile going into a stripped down mode when greeter locked?
[14:22] <dednick> Saviq: we want to allow any number of profiles to exist, but don't really want the ones we're not using to continue running. (or this is what i thought)
[14:22] <Saviq> dednick, yeah, can we *switch* a cached model to a different profile, not destroy and create one with the different profile?
[14:24] <mterry> Saviq, last time I spoke to tedg, he suggested the easiest way was for the touch profile to enter a stripped mode itself rather than us switching.  But maybe that implementation preference has changed since then
[14:24] <Saviq> yeah that's kinda my question
[14:24] <dednick> Saviq: well, at the moment the cached model will fork. leave the other models as they want and create a new model.
[14:24] <mterry> Saviq, yeah I guess I'm saying I don't know  ;)
[14:24] <dednick> for the new profile
[14:25] <Saviq> mterry, that's I pung tedg on this, too :)
[14:25] <Saviq> why
[14:26] <tedg> Saviq, mterry, I think having the stripped profile in teh session makes sense, as the greeter profile.
[14:26] <tedg> The issue was before is that we were "cheating" in making them the same, just the data was stripped.
[14:26] <tedg> But I think we should have both in the session and have the stripping go on further down the path.
[14:26] <Saviq> dednick, so yeah, I would actually think switching the profile on a pre-existing model should be faster than destroying and creating a new one...
[14:26] <Saviq> dednick, and now we're getting to a "why do we need a cache again?" situation...
[14:26] <tedg> The actions will still be shared between them.
[14:26] <dednick> Saviq: does the same thing. needs to wipe the menu and redcreate.
[14:27] <Saviq> dednick, well, at least it doesn't recreate the object itself, but I agree negligible
[14:27] <dednick> Saviq: well, the cache is just because multiple things point at the same model. widget/menu, etc.
[14:28] <Saviq> dednick, just two - page and widget, right?
[14:28] <Saviq> dednick, so in theory we could pass just one object between them
[14:29] <dednick> Saviq: well, there is also another thing that sorts out the visible/invisible items
[14:29] <Saviq> dednick, but sure, the cache gives us some encapsulation
[14:29] <Saviq> dednick, ok, so for now just have a look please whether switching profiles actually gc's them as expected
[14:32] <dandrader> MacSlow, did you fix that Image.visible property expression I commented about?
[14:35] <MacSlow> dandrader, don't recall seeing that... looking again.
[14:38] <MacSlow> dednick, you turn
[14:41] <dandrader> MacSlow, it was a comment in the diff, easy to miss
[14:42] <MacSlow> dandrader, it is in ~macslow/unity8/fix-1348092, right?!
[14:43] <MacSlow> dandrader, ah... found it... was in the first revision of that branch
[14:46] <greyback_> Saviq: FYI I've stuff in silo16 - and unity8 is in there. Lemme know if I'm risking a conflict
[14:47] <Saviq> greyback_, you are risking it, but when d'you plan to land?
[14:47] <greyback_> Saviq: was hoping today
[14:47] <Saviq> greyback_, no worries then, I'll rebase
[14:48] <greyback_> ok thanks
[14:50] <anpok> on applicatin start, what is drawing the application name and rotating dots?
[14:51] <greyback_> anpok: unity8
[14:56] <mzanetti> vesar: hey, quick question:
[14:56] <mzanetti> vesar: we're about to land the app lifecycle stuff
[14:56] <mzanetti> vesar: which allows keeping screenshots in the spread if an app is killed because of low memeory
[14:57] <mzanetti> vesar: so that seems to work fine, but takes a few seconds to respawn the app when selected in the spread
[14:57] <mzanetti> I told you about this in our last weeks meeting
[14:58] <mzanetti> vesar: should we land it as is for now and wait until you come up with something to fix it? or have an idea already what we could/should do?
[14:58] <mzanetti> i.e. spinner on top or whatever
[14:58] <mzanetti> we can refine it later in any case
[15:01] <Saviq> greyback_, fyi, I've a lp:~mir-team/qtmir/gles-sync branch that I reuse for sync MPs
[15:01] <Saviq> greyback_, only problem if there's more than one sync in progress, but that should be rare
[15:01] <greyback_> Saviq: noted
[15:02] <Saviq> greyback_, good thing it just pulls trunk fine with bzr pull, no conflicts or anything
[15:02] <greyback_> Saviq: yep, my u8 changes were small enough
[15:04] <Saviq> greyback_, how's u8 related to what I wrote above? :D
[15:04] <Saviq> mzanetti, let me hit up vesar about this here
[15:04] <mzanetti> ack
[15:04] <mzanetti> Saviq: thanks
[15:05] <greyback_> Saviq: oh misread, sorry
[15:05] <greyback_> context switch fail
[15:05] <Saviq> @unity any design inquiries as I'll be going over to that part of the office?
[15:05] <Saviq> greyback_, kk, must be the underscore
[15:05] <mterry> none that they probably don't know about
[15:05] <Saviq> mterry, sure they know, maybe they need reminding? ;)
[15:06] <kgunn> Saviq: there was one about how to handle restarting app for vesa
[15:06] <Saviq> kgunn, yup, that's what mzanetti just asked
[15:06] <kgunn> oops :)
[15:07] <Saviq> @unity or design reviews maybe? I'm still here until tomorrow after lunch, so can impose myself on them :)
[15:07] <tsdgeos> Saviq: are we ok in the "see less" stuck on bottom decisions?
[15:09] <Cimi> I've some annoying headache... I'll afk for a bit...
[15:11] <Saviq> tsdgeos, will confirm
[15:11] <mzanetti> Saviq: right... and that pull up thingie in scopes
[15:11] <mzanetti> but I guess that's a more general discussion
[15:11] <Saviq> mzanetti, you mean the hint?
[15:11] <Saviq> mzanetti, what about it?
[15:11] <mzanetti> yeah... that it hides the activityindicator
[15:12] <mzanetti> and in general shouldn't be there (go away) I guess
[15:12] <mzanetti> we talked about that last week
[15:12] <Saviq> mzanetti, as it is it's the current desired design
[15:12] <Saviq> mzanetti, will need a larger wave of rethinking to change this
[15:13] <Saviq> mzanetti, I'll get the lockscreen a design review too then
[15:13] <mzanetti> yeah
[15:13] <mzanetti> Saviq: don't :D
[15:13] <Saviq> lol
[15:14] <Saviq> @unity: ah just remembered (or did I say that before?), please make sure to do newline after a brief commit message in case there's more to describe, this way we get concise changelogs but still verbose commit msgs
[15:14] <Saviq> s/newline/empty line/
[15:15] <dandrader> Saviq, that didn't work for qtmir
[15:15] <Saviq> dandrader, this only happened recently
[15:15] <Saviq> dandrader, like last week
[15:15] <dandrader> Saviq, the changelog added the brief line *and* the long description
[15:15] <Saviq> dandrader, yeah, one of the reasons why it happened last week ;)
[15:15] <Saviq> dandrader, because I complained
[15:15] <dandrader> :D
[15:22] <Saviq> greyback_, in case you'll be rebuilding unity8, please pull in all the top-acked branches into your silo, I'll help testing
[15:22] <greyback_> Saviq: I wasn't planning on a rebuild, but in case I do, ok
[15:22] <MacSlow> dandrader|lunch, fixed that visible-thing too
[15:24] <Saviq> greyback_, you still might need to, pending results from my -api review ;)
[15:25] <greyback_> Saviq: oh a power play, how naughty
[15:25] <Saviq> or at least your reactions to it by noew
[15:25] <Saviq> -e
[15:25] <Saviq> greyback_, I like to think that's not what happened, the review was in earlier ;)
[15:27] <greyback_> bah, missed that
[15:49] <greyback_> Saviq: "why not Binding?" - how do you propose it could work?
[15:49] <greyback_> syntactically I mean
[16:14] <mterry> Saviq, regarding the changelog endline thing...  shouldn't we just fix the tool to enforce a newline?
[16:21] <AlbertA2> kgunn: adb shell cat /usr/share/ubuntu-touch-session/usc-wrapper
[16:21] <kgunn> ta
[17:01] <Saviq> mterry, enforce it where?
[17:01] <Saviq> greyback_, callback: function boo() { }
[17:02] <Saviq> dandrader__, greyback_, you around?
[17:02] <Saviq> I got a phone in the edge-lock state
[17:02] <dandrader__> Saviq, yes
[17:02] <Saviq> and it's WEEEIRD
[17:02] <Saviq> mumble?
[17:02] <dandrader> ok
[17:03] <greyback_> Saviq: that syntax is valid?
[17:17] <Saviq> greyback_, why wouldn't it be? a function is just an object
[17:18] <Saviq> greyback_, another possible syntax:
[17:18] <Saviq> function blah() { }
[17:18] <Saviq> foo: blah
[17:18] <Saviq> greyback_, you wouldn't be able to assign it to a property if it wasn't an object
[17:19] <greyback_> Saviq: I guess, my JS-foo ain't too high. But AppMan is a singleton, so have to use Binding{} somehow
[17:20] <Saviq> greyback_, sure, Binding { target: ApplicationManager; property: "callback"; value: function foo() { } }
[17:21] <greyback_> not the most readable line IMO
[17:25] <Saviq> greyback_, not one line ;)
[17:25] <Saviq> greyback_, didn't want to span multiple lines
[17:39] <greyback_> Saviq: ok you can use my silo, just don't screw it up. I'm not ready for a rebuild, but add your crap to it
[17:44] <Saviq> greyback_, I thought you'd do that ;)
[17:44] <Saviq> greyback_, aanyway tomorrow
[17:44] <greyback_> sabotage
[18:47] <mterry> Saviq, enforce it in the tool that concatenates changelog entries (sorry, was out for a doctor's appt)
[18:50] <kgunn> greyback_: i'm +1 on the qtmir testing
[18:50] <kgunn> tested on n4, n7, n10
[18:56] <kgunn> greyback_: actually...i just noticed, clock app specifically on the n10 the clock does shift up just a tad, but all other apps look ok
[18:57] <kgunn> wonder if its just clock app on a mainstage layout isn't quite ready for primetime ?
[19:00] <greyback_> kgunn: not sure , will look into it tomorrow
[20:55] <dandrader> Saviq I think I found the variable that could disable mouse event emulation for good if not reset properly
[20:56] <dandrader> It's QQuickWindowPrivate::touchMouseId.
[21:04] <dandrader> mterry ping
[21:04] <mterry> dandrader, hello
[21:05] <dandrader> mterry when you are on the swipe-to-unlock lockscreen, should you be able to access the launcher and indicators or not?
[21:06] <mterry> dandrader, you should be able to if you have no passphrase.  You may be experiencing either bug 1358340 or bug 1357230
[21:07] <dandrader> mterry thanks. just asking because it's not obvious to me what's the expected behavior
[21:59] <kgunn> popey: you on?
[21:59] <popey> kgunn: yo
[22:00] <kgunn> :)
[22:00] <kgunn> popey: so trying to repro bug 1327547
[22:00] <popey> oooh, olde
[22:00] <kgunn> i killed powerd
[22:00] <kgunn> i verified unity8 is running
[22:00] <kgunn> how do i start an app ?(i assume some incantation with desktop file...which i don't do often)
[22:01] <kgunn> @olde ...yeah, house cleaning
[22:01] <popey> adb shell sudo -u phablet -i start application APP_ID=foo
[22:01] <popey> where foo is the app id, com.ubuntu.appname
[22:01] <popey> I think
[22:01] <kgunn> got it
[22:02] <popey> thats what my manky script does anyway
[22:03] <kgunn> hmmm, i just get a "failed to start"
[22:04] <popey> balls
[22:04] <popey> lemme try here
[22:04] <popey> ah hang on
[22:05] <popey> phablet@ubuntu-phablet:~$ start application APP_ID=com.ubuntu.calendar_calendar_0.4.402
[22:05] <popey> that worked
[22:05] <popey> so basically get the .desktop file name from ~/.local/share/applications and strip .desktop off it
[22:05] <popey> thats what my script does
[22:05] <kgunn> :-/
[22:05] <kgunn> i'm sure it's me somehow
[22:06] <popey> doing it as phablet user, right?
[22:07] <kgunn> yeah for sure, via phablet-shell...so logged in as user not via adb
[22:07] <popey> same here
[22:07] <kgunn> popey: if that matters
[22:08] <popey> kgunn: while you're here.. ☻
[22:08] <kgunn> oh boy
[22:08] <popey> I have been talking to someone about porting their game framework to Ubuntu touch
[22:08] <popey> which may have dependencies somewhere down the line on x which needs porting to mir
[22:08] <popey> do we have a list of things that are non-toolkits which need porting
[22:08] <popey> or is it "as and when they come up" and do we give them help?
[22:09] <popey> (i realise you guys are super busy)
[22:09] <kgunn> popey: prob is x got to be a monster...so yeah, we kinda gotta look at stuff in a one off fashion of a) do we wanna add some extension
[22:09] <kgunn> and b) then figure out where/when to fit that in
[22:09] <kgunn> but we're open for discussion
[22:09] <popey> thats what I figured
[22:09] <popey> I'll see how far he gets, the good news is all his stuff is open
[22:10] <popey> and runs on android, ios and others already
[22:10] <kgunn> oh yeah...in that case, we're more like android/ios
[22:11] <kgunn> i'm simplifying...but just saying, we're a little hesitant to add x extension if they're not really needed
[22:20] <kgunn> popey: no matter what i can't seem to start the app from the command line, is there some precondition i'm missing?
[22:22] <popey> kgunn: not that I'm aware of
[22:22] <popey> whats the full output of you running the command?
[22:23] <kgunn> popey: phablet@ubuntu-phablet:~/.local/share/applications$ start application APP_ID=com.ubuntu.calendar_calendar_0.4.393.desktop
[22:23] <kgunn> start: Job failed to start
[22:26] <popey> ah no
[22:26] <popey> omit .desktop
[22:26] <popey> start application APP_ID=com.ubuntu.calendar_calendar_0.4.393
[22:26] <kgunn> ta
[22:26] <popey> do that
[22:26] <kgunn> yep
[22:29] <kgunn> popey: ok to use phablet-screenshot for that portion ?
[23:27] <pdo_fn14> I think HUD doesn't work properly for another language, it's only designed for English.
[23:30] <pdo_fn14_> Sorry suddenly disconnected.
[23:33] <pdo_fn14_> Give a try With Trusty and Utopic still same problem who can't fulfilled menus in some query non-english language.
[23:35] <pdo_fn14_> Example, try to type "inf" when rhythmbox playing music and Using Indonesian as Primary Ubuntu Language, it's won't show "Info Program".
[23:36] <pdo_fn14_> Trying to search these Unity Bug in LP, but no result.